Re: protecting time-limited demos
Re: protecting time-limited demos
- Subject: Re: protecting time-limited demos
- From: David Fayram <email@hidden>
- Date: Thu, 17 Apr 2003 13:35:54 -0700
Well, many people do it different ways, on the technical edge. I had to
consider the same problem and I came up with the following idea. The only
restrictions on this idea is that it is relatively computationally expensvie,
it requires network connectivity, and it is kind of a pain in the neck when
you move from machine to machine.
However, it's reasonably secure and uses cryptographically secure algorithms
from libcrypto that are pretty well known. The basis of this system is public-
key cryptography.
The axis point of the system is a license, which is a proplist containing your
machine's "Customer Serial number" field (a machine-specific ID), your name and
the duration of the license. These do not need to be encrypted, but they do
need to be digitally signed by you, the vendor. Basically when someone
activates the program it verifies the signature on your license. An invalid
license signature or a past license expiration date or an mismatch on the
machine's ID means that the program should not run. A match on all these
parameters will mean the program is okay to run. It's perfectly acceptable
to distribute the RSA/ElGamal public key as part of the app bundle.
The infrastructure to make sure this all work is pretty obvious, but I'll
outline it. Basically your app has a "Register" menu item that opens a webpage
with the computer information filled in. You fill out the user information,
give the credit-card info, and if it works, you email them a signed license and
a script to install it. Particularly slick designs can handle this all
internally and auto-install the license in the application bundle. By getting
specific user information, you can administrate requests for machine-transfer
licenses ("I bought a new computer, but the app won't run! Can I transfer the
license?") automatically by giving a license ID, so long as you fix the number
per license so it's not abusable and handle it all on your server.
The major problems with this system is that:
1) If you're not used to crypto coding it can be a bit tricky.
2) If the user changes machines, they need to get a machine license change.
3) It requires an active licensing service to be running on the network.
If you could find a way to undeniably mark an application with a unique id in
such a way that it cannot be changed, then you could sign application ID's, but
I can't really think of a way of doing this. Basically we need some kind of
unforgable name, rooted in the base of the hardware. The only real way to
circumvent a measure like the machine ID is a customized darwin kernel. This is
an acceptable level of difficulty.
Now, this hinges on my understanding of the Customer ID that utilities report
from your machine. I understand it's a CPU-specific ID. It may not be. It's
also my understanding it cannot be changed without extreme effort. If these two
stipulations do not hold, then this system won't work very well.
I think something like this has already been created. It's called LicenseKit
iirc, and you can search it out if you feel inclined. Good luck.
Quoting Ron Phillips <email@hidden>:
>
Thanks, Jason. Got them and have read through them. What's missing is
>
the mechanics behind it.
>
>
Regards,
>
Ron
>
On Thursday, April 17, 2003, at 11:56 AM, Jason Deraleau wrote:
>
>
>> How does one protect a time-limited demo? I've seen discussions here
>
>> about protecting licensed software but not demos. I am far from a
>
>> licensing guru (hence the problem) but I see various schemes:
>
>>
>
>> 1) Somehow the time (or usage count) is hidden on the hard drive (?)
>
>> - best I can guess. This solution is protected better than the
>
>> Presidential football codes.
>
>>
>
>> 2) The demo customer gets a free trial license after install. How
>
>> does that work?
>
>>
>
>> I'm not looking for a solution "on the cheap." I'm willing to
>
>> purchase, within reason, whatever solution or expertise that will
>
>> solve this problem. I've looked at some postings here about
>
>> modifying a file size in the bundle to keep up with launch counts.
>
>> But all you need to do to defeat this is re-install the app. (I
>
>> visualize keeping the .sit file on the desktop and re-installing
>
>> after the demo lapses.)
>
>>
>
>> If this is not the forum for this, could some kind soul point me to
>
>> the place that is. I've been to the end of the internet and have
>
>> found nothing.
>
>>
>
>> Thanks in advance,
>
>> Ron
>
>> email@hidden
>
>>
>
>
>
> O'Reilly's MacDevCenter has a set of three articles by Sanford
>
> Selznick [http://www.oreillynet.com/pub/au/1034] about "The Do's and
>
> Don'ts of Shareware." You'll probably get some good work out of
>
> fprefect's article
>
> [http://www.ambrosiasw.com/cgi-bin/ubb/
>
> newsdisplay.cgi?action=topics&number=14&article=000052] on piracy that
>
> discusses theory of expiring registration keys.
>
>
>
> Have fun!
>
>
>
>
>
> --
>
> Jason Deraleau (email@hidden)
>
> Homepage: http://www.lifehertz.com
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
>
>
--
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.