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

Kevin Coulombe stonkie at gmail.com
Mon May 23 08:26:57 UTC 2011


Hi RPM, Danny and Steve,

I hadn't considered using a random https query header's timestamp... Is the
timestamp part of the encrypted message or is it part of the routing
information (like the destination IP, etc.)? Is this solution actually safe?

For the SSL certificate store, I still have to look into it, but I think I
can override the use of the certificate store and provide my own
certificate. This also fixes the issue with the certificate being time
based. We can bundle the latest client certificate and an hardcoded demo
version expiration date before we send the CD (each CD would be good until
the end of the month for example). Using a continuous integration server
makes this pretty easy to script. We might need to provide our own time
server and control its certificate expiration policy, in which case an
actual license server might be more convenient. I still have to look into
how certificate expiration works for that decision.

I'll look into autokey as Danny proposed. It seems to have been designed
exactly for what we're doing.

-- The rest is more of a defense for DRM...
As a developer, I don't like the idea of DRM either. I think I should have
complete control over what runs on my computer. But we don't have a better
option, so in this case, I think it is justified. A single lost sale loses
my customer more money than the implementation of the whole DRM protection.
Of course, we can't protect against an even moderately good cracker with a
decompiler, but if we make it difficult enough, we can cut our losses.

Once the application has been bought, we send a USB dongle to the customer
and we don't need to query for time anymore. This makes things pretty
straight foward for legitimate users since there are no serial numbers to
type in or anything.

Physical paper contrats and no-notice audits are fine to prevent the client
buying one license and using it on multiple computers, but it is of no use
concerning clients giving away (or selling) a copy of the application to
unknown third parties. Plus it may scare off some customers working on
sensitive "restrited access" stuff.

As for the idea of using a limited version, we considered it too, but we
don't want customers to only use the limited version and never pay for a
license. What features to limit and which to give is a difficult question to
answer in our specific case. A different application might use this approach
effectively though.


Kevin


On Thu, May 19, 2011 at 11:06 AM, Kevin Coulombe <stonkie at gmail.com> 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 simplest "solution" for secure time with limited resolution would
> be to do an HTTPS get to say https://www.isc.org/. Parse the Date
> header returned. You can presumably trust that ISC keeps its web
> server clock synced closely to UTC. Use more than one source if you
> are paranoid.
>
> If you're trying to protect yourself against a potentially"evil"
> prospective customer running your software without a license, though,
> this won't work if they are determined and moderately skilled. There
> exist HTTP proxies that can act as a man-in-the-middle for HTTPS,
> because the client controls the list of certificates that are trusted
> (after all, they control the machine where the software is installed).
> DRM of this sort is basically impossible - witness all the cracks of
> DRM on video games, iTunes, Blu-Ray and other anti-piracy measures.
> They all fall eventually, and only inconvenience legitimate customers.
>
> DRM = fail. You are far better off protecting yourself with a paper
> contract that gives you no-notice physical audit rights.
>
> --
> RPM
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 21 May 2011 18:18:45 -0400
> From: Danny Mayer <mayer at ntp.org>
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] SSL time request
> Message-ID: <4DD83A45.4040403 at ntp.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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.
>
> Danny
>
>
>
> ------------------------------
>
> Message: 7
> Date: 21 May 2011 19:20:21 GMT
> From: Steve Kostecke <kostecke at ntp.org>
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] SSL time request
> Message-ID: <slrnitg43l.h7s.kostecke at stasis.kostecke.net>
>
> On 2011-05-19, Kevin Coulombe <stonkie at gmail.com> wrote:
>
> > 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.
>
> Have you considered a limited functionality version of your application?
>
> --
> Steve Kostecke <kostecke at ntp.org>
> NTP Public Services Project - http://support.ntp.org/
>



More information about the questions mailing list