I have had the pleasure of working on a couple of smaller shrink-wrapped products, and I know many people interested in the shrink wrapped product business. One of the small challenges involved in selling people software is managing your licensing. Back in the 90s almost all consumer software had a CDKey, but it was a joke since all one had to do was dial in to your favorite BBS or call up a friend and ask them for their key. Piracy laws were there but if you were willing to do it, it was no issue.


In today's connected world there are some more complicated schemes. I thought Windows XP product protection was the ultimate protection: it was actually tied to your specific hardware.

So, with that in mind, I set out to try to create something similar in managed code. I wanted to support the following features:

• Ability to tie an installation to specific hardware
• Ability to automate the registration process
• Mitigate any risks to the security that could arise from reverse engineering the code

Step 1, tie an installation to a piece of hardware was easy enough. Using the System.Management namespace and some cryptic Windows object queries, you can obtain all kinds of hardware information. There are ways to PInvoke even more information, but this was good enough to start. Once some hardware information is obtained, a trap door hash algorithm is applied to obfuscate the specific data used. We'll call this part a hardware key.



Step 2, automate the process. Assume now that some kind of product key has been given to a client, and the hardware key has been generated by the software. An online system could easily be created to associate a hardware key to a product key, and for some that might be enough. However, the software should ideally be able to determine if it should allow itself to run. Even more ideally the software should be able to make this determination without connecting to an online system ever time it starts up. By introducing some more complexity this can be accomplished.

We could create RSA key data, or a complete digital certificate, that represents the company licensing the software for use. Due to the great properties of an RSA public/private key pair the company could keep an RSA key (safely) RSA private key data that could be used to sign a "license file". If the license file contains the hardware key, the RSA public parameters, and a signature created based on the hardware key the client could use this license file to determine if its OK to run or not. Consider this scenario:

1. New installation creates a hardware key
2. New installation sends its product key and hardware key to a web service hosted by the product company
3. The web service stores the product key and hardware key, in order to deny permission to other hardware trying to run with this key
4. The web service creates a private key signature of the hardware key + product key, and sends this information back to the client along with the RSA public key data
5. The client, whenever it attempts to run, can re-calculate the hardware key, and use the RSA data to verify the signature and allow itself to run

Step 3, code obfuscation is the best way to mitigate the risk of comprimising this strategy, however by using the digital signature piece knowledge of how the system works does not ruin the whole system, and that is the mark of good security. Contact me for code if you are interested. Maybe I should just post code? I suppose I will refactor the system to work within the .NET LicenseManager API, which I found after I got this working the first time.