Advice on Registration Approaches

[Igor de Oliveira Couto]

Dear Richard & all Rev folks,

Thank you for the pointers, and for the very interesting article at  
Ambrosia! -  
<http://www.AmbrosiaSW.com/cgi-bin/ubb/ 
newsdisplay.cgi?action=topics&number=
14&forum=*The+Ambrosia+Times+Newsletter&DaysPrune=25&article=000052&star 
tpoi
nt=>

> A lot of folks speak well of Armadillo, and I know that Element5 also  
> has a
> wrapper mechanism, but I've used neither.

After receiving your posting, I had a brief look at both. Armadillo  
(http://www.siliconrealms.com/armadillo.htm)  sounds interesting, but  
it is Windows-only...
Element5 (http://www.element5.com) seems to be merely an online  
software sales portal - I could not find any information relevant to  
registration/licensing technology...

> What method are you currently using?

Right now, NOTHING - that is why I TRULY need some guidance! I know  
that the registration process, like so many other factors, can heavily  
influence the success of a new software release, and I do not have the  
time/money to 'try out' several different technologies and strategies  
to see which one works best!

It seems that there are many different approaches out there, and I  
suspect there must be advantages and disadvantages in all.

First of all, there are strategies for validating/authenticating a  
registration number. Some of the approaches I observed are:

1) Some companies (like Adobe, Apple, Microsoft, etc.) use a  
mathematical algorithm built-into the application itself, that checks  
whether the registration code entered by the user is valid. I know that  
these can easily be reverse-engineered, requiring only a moderate level  
of technical knowledge, and a fair amount of patience. The internet  
abounds with serial numbers for applications that use this approach,  
and it seems that all these manufacturers can do against the hackers is  
to continually build 'checks' against the most commonly known numbers  
into their updates and new releases.

2) Some companies generate the registration number based on information  
provided by the user (Name/Company/etc.) - such as Apple Quicktime Pro  
software. This ensures that a certain registration number will ONLY  
work with a certain Name/Company/etc. registration info. This does not  
seem to be any 'safer' than the previous approach, as registration  
numbers for 'John Doe' and 'SuperHacker' are easily found everywhere.

3) In an attempt to improve the previous system, some companies have  
their application generate a 'random ID' when first launched. The user  
must provide this 'application ID' number when purchasing it online -  
and it is this ID number that is used (instead of the user's  
Name/Company/etc. information) to generate the final registration  
number. This ensures that ONLY that specific application will accept  
the generated serial number. To 'crack' such applications, hackers  
often instruct users on how to 'break' into the application  data and  
change the 'random ID' seed, after it's already been generated (so that  
a 'generic' registration number can then be used). Often, though, by  
using the usual reverse-engineering techniques, they work out the  
formula which generates the registration number from the seed, and  
produce 'serial number generators' for the application - so that they  
can generate the final registration number for any seed. Serial number  
generators are also quite plentiful online, proving that this approach,  
while more troublesome for the hackers, is still not a true deterrent.

4) Ambrosia's approach - which is supported by the Armadillo folks - is  
to issue registration numbers that contain information necessary for a  
mathematical 'date check'. These numbers contain within themselves a  
mathematically-defined 'expiry date' - usually 30 days of their date of  
issue - so the user must register the application within 30 days. After  
that period, if the user tries to use that number, it will no longer  
register - and the user must re-contact the software company,  
requesting a new registration number. These numbers are much more  
difficult for hackers to 'crack', as they require a good grasp of  
university-level mathematics for them to work out the generating  
formula. This approach is, however, more high-maintenance. They cause  
extra work for the user, and for the software company - as per the  
testimonial on the Ambrosia site. Is it worth it?

5) There are applications that simply require the user to establish an  
internet connection to the 'homebase' when first launched, to verify  
that the registration number entered is actually a 'legal' one,  
generated by the software maker. The application itself has no parsing  
or mathematical algorithm - it simply accepts any number entered, as  
long as the homebase says it's in the database...

6) Lastly, there are companies that seem to do quite well without using  
registration numbers at all... (ie, VIREX).

Then, there is the problem of how the application stores/uses the  
registration number, and  what (if any) methods are available for  
stopping an already fully-registered application being copied:

1) Most applications store the registration number or flag (which  
signals the application as being fully functional) into an external  
file - such as a Preference, or an invisible file. In most cases, these  
can simply be copied to another user's computer to make any copy of the  
application 'fully registered' (ie, OmniGroup apps)...

2) Some applications change internal resources in the application  
itself - not in an external file - which signal to the application upon  
opening that it is now registered. Applications such as these can  
usually simply be copied to another user's computer to work as fully  
registered apps (ie, the Adobe apps). There are also programs - such as  
ResCompare - that can COMPARE unregistered and registered versions of  
an application, and build an 'installer' (or 'hack') that when run,  
changes all the resources of the unregistered application to match  
those of registered ones. So even end users with no technical knowledge  
can actually produce 'hacks' for these apps.

All in all, any way I look at it, I cannot seem to find a reasonable  
solution. All attempts to protect our apps against illegal use seem to  
be costly, and ineffective... That is why I wanted to find out what  
people's experiences in this area were!

Is any of these methods more effective than another? Less costly?  
Better liked by the end users? Easier to manage? More suited to the  
Revolution development environment?

Are there any approaches I did not list?

I'll tell you what I think WOULD be good way to handle this, if at all  
possible: using PGP keys, and a unique machine-identifier, such as the  
ethernet address of the computer or the HD serial number. Here is how I  
would probably do it, if it were possible:

a) Embed a PGP public key into the distribution of my app.
b) When the user wants to purchase the application, the machine  
identifier (e'net address /hd serial num, etc.) is encoded with the  
public PGP key, and sent to our 'random number generator'. A random  
registration number is generated, and the user registration info (name,  
etc.) entered in our database.
c) A file containing the registration number and machine identifier is  
produced, signed with the private PGP key and sent to the user.
c) The app authenticates the registration file with the public PGP key,  
thereby certifying that it came from US.
d) Whenever the app is launched, the registration file is accessed. App  
verifies that registration has not been tampered with (using public PGP  
key) and app ensures that the user is still running the software in the  
same machine as when it was registered.

Disadvantage: if the user changes computers, then a new serial number  
would have to be re-issued.

Does anyone have any thoughts on this?

All comments and suggestions greatly appreciated!

Kind Regards,
--
Igor de Oliveira Couto
----------------------------------
igor at pixelmedia.com.au
----------------------------------