license key expiring date...

I am releasing an application and I have a private/public key setup to
generate a license. I also would like to give licenses out for
specific number of days. I have that also working, but realized that I
am not supporting the case when system time can be changed. How can
one code for system time change ?

My general algo is as follows:

1. Use a private key to generate a license code which has the number
of days built in.
2. Send the expiry date, license code and public key to the customer.
3. App code checks if current date is less than expiry date, and
verifies the license code using the public key.

But step 3 is not protected by somebody changing system date. How does
one go about protecting oneself from this issue ?

Thanks

gd

golfdude

On 2 Nov, 08:39, golfdude <padysr...@gmail.com> wrote:
> I am releasing an application and I have a private/public key setup to
> generate a license. I also would like to give licenses out for
> specific number of days. I have that also working, but realized that I
> am not supporting the case when system time can be changed. How can
> one code for system time change ?
>
> My general algo is as follows:
>
> 1. Use a private key to generate a license code which has the number
> of days built in.
> 2. Send the expiry date, license code and public key to the customer.
> 3. App code checks if current date is less than expiry date, and
> verifies the license code using the public key.
>
> But step 3 is not protected by somebody changing system date. How does
> one go about protecting oneself from this issue ?
>
> Thanks
>
> gd

Internet time...

Another way (for frequently used or auto-started programs) is to
record last date-time it was active and then compare current date-time
to that last value...

GArlington

Thanks, Garlington.

Internet time is not an option ( else i can sync up with my server
itself ).

I have been thinking of the 2nd option but that is also not full proof
as somebody can read and change that value. But this is much better
than nothing.


gd

golfdude

golfdude wrote:
> Thanks, Garlington.
>
> Internet time is not an option ( else i can sync up with my server
> itself ).
>
> I have been thinking of the 2nd option but that is also not full proof
> as somebody can read and change that value. But this is much better
> than nothing.

Is your program so utterly valuable that someone will mess up their whole
system just to run it?

Is the expected number of people willing to mess up their whole system just so
they can run your utterly valuable program so large that it justifies the cost
of defending against a change in system clock?

What evidence do you have for "yes" answers to the above?

Do you provide no added value beyond the program itself such that there's no
incentive to obtain a valid license?

If not, why not?

--
Lew

Lew

golfdude wrote:
> Thanks, Garlington.
>
> Internet time is not an option ( else i can sync up with my server
> itself ).
>
> I have been thinking of the 2nd option but that is also not full proof
> as somebody can read and change that value. But this is much better
> than nothing.

(Background: golfdude wants his program to stop working
after an expiration date, even if the system operator sets
the clock back. The "2nd option" calls for the program to
record a time stamp whenever it runs, and to compare it to
the current system time to detect clock diddling. If
golfdude had remembered to INCLUDE SOME CONTEXT with his
reply, this summary would not have been necessary.)

golfdude, you can increase the difficulty by recording
the time stamp in an encrypted form. However, it is more or
less a given that a sufficiently determined cracker will be
able to defeat any protection scheme you come up with[*], if
he chooses to devote sufficient effort to the attack. You
can make his cracking task difficult, but not impossible.
[*] Actually, there *is* a perfect protection scheme,
one hundred percent immune to all cracking attempts: Don't
write the program, and no unlicensed person will be able
to run it.

--
Eric Sosman
lid

Eric Sosman

Eric Sosman wrote:
> golfdude, you can increase the difficulty by recording
> the time stamp in an encrypted form. However, it is more or
> less a given that a sufficiently determined cracker will be
> able to defeat any protection scheme you come up with[*], if
> he chooses to devote sufficient effort to the attack. You
> can make his cracking task difficult, but not impossible.
>
>[*] Actually, there *is* a perfect protection scheme,
> one hundred percent immune to all cracking attempts: Don't
> write the program, and no unlicensed person will be able
> to run it.
>
Even that isn't foolproof. If it is truly that useful, someone else will
eventually write it, and publish it without worrying overly much about
the small percentage of pirates, and *they* will make the money instead.

Daniel Pitts

Hi Lew,

Absolutely valid questions. ( I have asked myself that a lot ). The
issue is that I have one sales guy ( with a lot of contacts ) who
wants a full proof algorithm. Working in a country where piracy is
rampant, he is worried. My software is definitely another "run-of-the-
mill" software only - but its value seems to be high more because of
the lack of computer knowledge among his users. But there are also a
lot of hackers in this part of the world. I definitely feel this is a
waste of time - but unfortunately I have to keep the sales guy happy.
So I am not telling him this system time hack for now.

Eric - if they figure it out, i will try with an encrypted timestamp
as the last resort.


Thanks

gd

golfdude

On Mon, 2 Nov 2009 00:39:11 -0800 (PST), golfdude
<> wrote, quoted or indirectly quoted someone who
said :

>
>I am releasing an application and I have a private/public key setup to
>generate a license. I also would like to give licenses out for
>specific number of days. I have that also working, but realized that I
>am not supporting the case when system time can be changed. How can
>one code for system time change ?

If you have Internet access, you can find out the real time. See
source code for setclock.

see http://mindprod.com/applet/setclock.html

Most likely you should not worry about it. Fiddling the clock will
screw up so many things, very few people could be bothered.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Without deviation from the norm, progress is not possible.
~ Frank Zappa (born: 1940-12-21 died: 1993-12-04 at age: 52)

Roedy Green

On Mon, 2 Nov 2009 00:39:11 -0800 (PST), golfdude
<> wrote, quoted or indirectly quoted someone who
said :

>I am releasing an application and I have a private/public key setup to
>generate a license.

for more general help on the problem see
http://mindprod.com/jgloss/obfuscator.html
http://mindprod.com/jgloss/installer.html
http://mindprod.com/jgloss/registrationkey.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

Without deviation from the norm, progress is not possible.
~ Frank Zappa (born: 1940-12-21 died: 1993-12-04 at age: 52)

Roedy Green