Encryption Product Keys : Public and Private key encryption

Question

I need to generate and validate product keys and have been thinking about using a public/private key system.

I generate our product keys based on

• a client name (which could be a variable length string)
• a 6 digit serial number.

It would be good if the product key would be of a manageable length (16 characters or so)

I need to encrypt them at the base and then distrubute the decryption/validation system. As our system is written in managed code (.NET) we dont want to distribute the encryption system, only the decryption. I need a public private key seems a good way to do this, encrypt with the one key that i keep and distribute the other key needed for decrpytion/verification.

What is an appropriate mechanism to do this with the above requirements?

NOTE: It's not to stop piracy; it's to reduce the likelyhood of novice users installing components they dont need/unauthorised to use.

Answer 1

.NET supports public key encryption in various ways, such as http://msdn.microsoft.com/en-us/library/ms867080.aspx. Having said this, all you'd gain is some confidence that someone with full access to the released code would not have the ability to issue their own product keys. None of this stops them from patching the client to accept anything as a valid key. That's where obfuscation fits in.

Answer 2

Don't even try to get fancy with anti-piracy. It's not worth it. I've cracked countless applications (hush) and .NET ones are by FAR the easiest. But in reality, they're all relatively easy with enough experience. If you don't believe me, check out isohunt some time.

tl;dr: It's a losing battle. Don't fight it. If you really want to win, sue infringments - but even that makes you lose.

Answer 3

I did something very similar. But in my case it was a simple telephone authorisation code. User would phone a number, give their company name and the operation they were performing, get a code, type it into the application and then be able to proceed.

What I did was serialise a piece of data into binary. The data included the hashed company name, operation code/expiration date, and had space to spare for future requirements. I then scattered the bits around the array to confuse it. Then I mapped each 5 bits of the binary array onto a 32 character auth-code alphabet (0-9,a-z,excluding I/O/Q/S for readability over telephone).

This resulted in a nice auth-code which was 16 characters, displayed as 4x4 blocks (####-####-####-####). It could be easily read out over the telephone, as the user only had to listen to four characters at a time, or even sent via SMS.

As with your problem, it wasn't intended to stop the code crackers at Bletchley Park, but was enough to stop the average office worker from doing something without following company procedure. And, given that scope, has been very effective.