[ntp:questions] questions Digest, Vol 79, Issue 37

Kevin Coulombe stonkie at gmail.com
Mon May 23 08:55:15 UTC 2011


Hi,

Indeed, making it 100% secure is impossible. As long as the user control the
hardware, there is always a way to crack it. We need to simply make it
"difficult enough".

>From the dicussion here, I think SSL is safe if we provide the client
certificate. The only missing lego block is where to get the time from (as
was pointed out, within a few hours is good enough). After reading your
comments, it does seem like overkill to consider NTP for this. I would have
prefered to query a server other than our own to have better uptime
(Google's for example).

Do you guys know a reliable known server that handles the time protocol
through SSL?


Kevin


Message: 1
> Date: Sat, 21 May 2011 18:04:41 -0700
> From: Chris Albertson <albertson.chris at gmail.com>
> To: mayer at ntp.org
> Cc: questions at lists.ntp.org
> Subject: Re: [ntp:questions] SSL time request
> Message-ID: <BANLkTin4tDBgnycFQ1+9XAraAw+FeEtYSA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sat, May 21, 2011 at 3:18 PM, Danny Mayer <mayer at ntp.org> wrote:
> > On 5/19/2011 12:06 PM, Kevin Coulombe wrote:
> >> Hi,
> >>
> >> I'm looking into producing a 15 days demonstration version of an
> application
> >> for a client. I'm considering the use of an internet clock to validate
> this
> >> demo's duration, but a simple http request would be too easy to hack.
> >>
> >> Is there any way to request time in a secure manner such as an SSL
> >> connection. What I need is to validate that we are actually
> communicating
> >> with the "real" time server and that the message isn't tampered with.
> >>
> >
> > The proper way to do this with NTP is to use the autokey protocol which
> > will authenticate the servers. Note that the basic way that NTP works is
> > to use 3 or more NTP servers which allows it to select only consistent
> > truechimers and that are close enough to each other timewise that it can
> > choose one of them to synch to. It is actually quite hard to tamper with
> > an NTP packet and have it not be noticed, mainly because it does not
> > rely on a single NTP server. Add autokey for each of the servers and
> > just about nothing can be tampered with.
> >
> > Note that SSL is *not* secure when it comes to time since the SSL
> > certificate is in turn dependent on time. The autokey protocol deals
> > with that issue.
>
> Let me add one more thing.  It should be obvious.  You need to do the
> NTP protocol from within your program.  Letting NTP sync the system
> time then using that is to easy to work around.
>
> But a simpler method is to use SSL to "tunnel" to your server and use
> something very simple like the "time" protocol.  NTP will give time to
> the milisecond level but the time protocol is faster and good enough
> for a second or so, more than you need.
>
> None of this will work if the person trying to break it knows about
> software, he'd just binary patch your software with an unconditional
> jump.
>
> --
> =====
> Chris Albertson
> Redondo Beach, California
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 22 May 2011 00:07:05 -0400
> From: Danny Mayer <mayer at ntp.org>
> To: Chris Albertson <albertson.chris at gmail.com>
> Cc: questions at lists.ntp.org
> Subject: Re: [ntp:questions] SSL time request
> Message-ID: <4DD88BE9.5060005 at ntp.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 5/21/2011 9:04 PM, Chris Albertson wrote:
> > On Sat, May 21, 2011 at 3:18 PM, Danny Mayer <mayer at ntp.org> wrote:
> >> On 5/19/2011 12:06 PM, Kevin Coulombe wrote:
> >>> Hi,
> >>>
> >>> I'm looking into producing a 15 days demonstration version of an
> application
> >>> for a client. I'm considering the use of an internet clock to validate
> this
> >>> demo's duration, but a simple http request would be too easy to hack.
> >>>
> >>> Is there any way to request time in a secure manner such as an SSL
> >>> connection. What I need is to validate that we are actually
> communicating
> >>> with the "real" time server and that the message isn't tampered with.
> >>>
> >>
> >> The proper way to do this with NTP is to use the autokey protocol which
> >> will authenticate the servers. Note that the basic way that NTP works is
> >> to use 3 or more NTP servers which allows it to select only consistent
> >> truechimers and that are close enough to each other timewise that it can
> >> choose one of them to synch to. It is actually quite hard to tamper with
> >> an NTP packet and have it not be noticed, mainly because it does not
> >> rely on a single NTP server. Add autokey for each of the servers and
> >> just about nothing can be tampered with.
> >>
> >> Note that SSL is *not* secure when it comes to time since the SSL
> >> certificate is in turn dependent on time. The autokey protocol deals
> >> with that issue.
> >
> > Let me add one more thing.  It should be obvious.  You need to do the
> > NTP protocol from within your program.  Letting NTP sync the system
> > time then using that is to easy to work around.
> >
> That does not make a lot of sense. Putting an NTP server into your own
> code would be an extremely difficult thing to do. If you cannot rely on
> NTP setting and disciplining your system clock and using the system time
> then you have much bigger problems that accurate time.
>
> > But a simpler method is to use SSL to "tunnel" to your server and use
> > something very simple like the "time" protocol.  NTP will give time to
> > the milisecond level but the time protocol is faster and good enough
> > for a second or so, more than you need.
> >
>
> As I said before SSL depends on accurate time in the first place so you
> cannot use it for verifying time. In addition what you would need to do
> requires TCP and adds a lot of variable delay which you not be able to
> measure. The only thing you can do with a time protocol is to set the
> clock. It cannot discipline the clock and ignore bad time.
>
> > None of this will work if the person trying to break it knows about
> > software, he'd just binary patch your software with an unconditional
> > jump.
> >
>
> Having access to the source code is unlikely unless it is publicly
> available which is rather unlikely and if the attacker can get in to
> patch the software then you have bigger problems than the software or
> time. This all sounds like a solution looking for a problem.
>
> Danny
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 21 May 2011 21:37:21 -0700
> From: Chris Albertson <albertson.chris at gmail.com>
> To: mayer at ntp.org
> Cc: questions at lists.ntp.org
> Subject: Re: [ntp:questions] SSL time request
> Message-ID: <BANLkTincoq1wXiaqMr5Svfwix67WyWtzEQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sat, May 21, 2011 at 9:07 PM, Danny Mayer <mayer at ntp.org> wrote:
>
> > That does not make a lot of sense. Putting an NTP server into your own
> > code would be an extremely difficult thing to do.
>
> No, not that hard given that NTP source code is available.  Just way
> to much work.  And not needed.
>
> The problem to be solved here is NOT setting a clock.  The demo
> software needs to stop working after 90 days.  He is looking for a
> secure way to know that a certain number of days has past.  Looking at
> the local clock is not going to work because the user could simply
> re-set it to 90 days in the past.   Using NTP to set the clock is no
> help either because the program could not know if the local clock is
> being set by NTP.
>
> What the OP is looking for is a way for a program to know the time and
> date to within a few hours in a secure way that can not be spoofed.
> I still think he could ask his own server using SSL.
> >>
> >
> > As I said before SSL depends on accurate time in the first place so you
> > cannot use it for verifying time.
>
> He really does not need to verify time.  He only needs to know the date.
> He does not want to discipline the clock.  He only needs to know that
> 90 days have gone by.  Accuracy requirement is "about an hour" more of
> less.  "Time" is good enough for that.
> >
> >
> > Having access to the source code is unlikely unless it is publicly
> > available which is rather unlikely and if the attacker can get in to
> > patch the software
>
> He does not have to "get in" to the computer.  In this case he owns
> the computer and already has full access.  He would not need source
> code.  If I were doing this hack I'd use a machine level debugger and
> single step the program to find the conditional branch that needed to
> be patched.   In this case the "hacker" owns the computer and wants to
> modify the program so it will not expire after 90 days.  I claim this
> is easy to do.  Not by most people.    I doubt there is any way to
> make this 100% secure, not if your user knows what a machine level
> debugger is.
> --
> =====
> Chris Albertson
> Redondo Beach, California
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 22 May 2011 09:43:25 +0100
> From: David Woolley <david at ex.djwhome.demon.invalid>
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] SSL time request
> Message-ID: <iraibg$foh$1 at dont-email.me>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Danny Mayer wrote:
>
> >
> > Note that SSL is *not* secure when it comes to time since the SSL
> > certificate is in turn dependent on time. The autokey protocol deals
> > with that issue.
>
> In this context, I would use a self signed certificate with as near an
> indefinite expiry date as possible. I'd check, in the code, for dates
> outside that range.
>



More information about the questions mailing list