I'm working on an app I'd like to sell some day -- sooner rather than later! I'd like to develop a reasonably simple serial number scheme to protect it.
- A simple number/letter combination not more than 25-30 alphanumeric characters long (think Microsoft product keys)
- Does not require the user to enter any personal information (like an email address) as part of the verification
I've been thinking about this a (very little) bit, and I think public key cryptography is a good place to start. I could generate a string that identifies the license (like SKU + plain ole' integral serial number), hash it, encrypt it, and encode the serial number + identifier into a 25 digit (or so) alphanumeric key. The app would then decode the key into a serial number and "signature", generate an identifier hash, decrypt the "signature" using a corresponding public key and compare it against the generated identifier hash.
Essentially, the product key carries two pieces of data: the serial number the user claims to own plus a signature of sorts the program can use to verify that claim. I don't know if 25 alphanumeric characters (which encode 5 bits each for a realistic total of 120 bits) is enough for all this. But, it doesn't have to be cryptographically secure, just enough that the codes aren't easily guessable. I'm OK with short key lengths and short hashes.
As far as implementation goes, the app is written in Objective-C for Mac OS X, but given how easy it is to inject code into Cocoa apps, I'll probably write the verification code in straight C.
I would not use any strong cryptography, since you have to decrypt it in program anyways, making keygens or at least cracks easy to do.
I would do the following - take a, say, 25 digit number. Now add some rules, such as: - number must be divisible by 31 - it must start and end with the last letter ...
Always generate keys using these rules. Use 20 rules or more (more the better). When deploying the app, use smaller number of rules, e.g. 10 to check if key is valid. These rules will then be disassemled and used to create keygen.
On every update enable one of the rules you didn't use before. If rules are selected correctly, you will disable most of keys generated by keygens.
I like @bh213's method, however it isn't going to prevent the key-gens from being fixed as you update your serial number rules.
On a more personal preference note, I prefer the key generator based on a rule set method because if hackers have to patch a binary, you stand to get a bad review on your software because of a bad hacker patch and the ensuing battle between you and hackers.
My preference is based on a universal software truth: Software can and will be hacked if it is popular enough, there is no scheme, no ingenious method that will prevent this from happening. This battle is between the developer who has limited resources and limited time and a hacker group with unlimited time on their hands.
Your key generation scheme is really only to keep the honest customers honest - its easier to get a check cut from Accounts Payable than it is to get Security to sign off on a key generator.
As Redbeard 0x0A is correct, CD-Keys are to keep honest customers honest. It just needs to be slightly less difficult to buy your product than to find a keygen.
If you are selling your product online, then the best way to do it is to give them a file containing the serial. This way the serial can be however long you want and your paying customers don't have to waste time entering a serial.
A serial scheme can be very simple:
- Have a large serial space (25 alpha numeric is about 1044, but just use a serial file and do 80 char x 16 rows for a key space of 102311)
- Select a few rules to reduce valid serial number space to 100 times what you think you will sell in your wildest dreams
If your product has an online component (like how games have multiplayer online), you could further reduce valid serial numbers using a cryptographically strong random number generator (to select a subset of the rule based keys, product uses rule to check serial, server uses final true serial list). When your product requests service from your server, the server can check the serial.
All rules whether custom developed or encryption based can be found out and cracked. Think about who you're building your application for. Many of my products are for businesses so they're either going to buy it or they won't. They're typically not going to run a hacked version on their networks. People looking for a keygen aren't likely to purchase your product regardless. You just want to make sure you don't annoy your customer to the point where they're no longer wanting to buy your app.
That being said, I've written a library for this sort of thing to use in my applications based on AES encryption. I'm selling it for $25, and it uses a passphrase and a salt to make your serial number unique. If you're interested you can find it here: http://simpleserials.com
There is a Blog Post on sigpipe.macromates.com explaining how you use private/public key crypto for checking a serial number. It can verify that the user and Serialnumber match. (Signing/Verify). I would probably add some salt, just to be sure.
As this post is from 2004, you should consider the recommended keylength at keylength.com.
来源：https://stackoverflow.com/questions/559163/whats-a-good-approach-for-developing-a-simple-serial-number-generator-verifier