Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
No offence intended, but let's not discuss that licensing schemes can be cracked (I know that) and that recourse to the law is usually a better deterrent (maybe in your country, but no in all).
Not my choice - I have been told to implement licensing, just good enough to keep casual hackers away.
What might make this slightly different is that the PCs which will run the software won't always have internet access privileges.
When someone buys the product, I can build licensing info into it & deliver an install CD. But, what happens if they want to buy more licenses? I don't want to have to go on site to update the licensing data, but they may not be able to access my server, nor I theirs.
I was thinking of having licenses in external (encrypted) files, each containing a number of licenses and an expiration date. If the user buys more licenses, then I can email out an additional file & their security cleared IT guys can burn it to CD or USB stick and then copy it to the applications data directory.
Does that seem ok? Can you think of something better? Can you see problems? I don't have too much time to implement this.
That would be fine if the license contains a lot of info. Typically they don't so they can be encrypted complete with some protections in 30-50 chars or so. These can then be emailed out, cut&pasted, or even typed.
As for protection schemes, PKV or Partial Key Verification is popular. There are a number of questions here on SO about it, and a Google search will provide a number of different language implementations.
I use asymmetric cryptography with elliptic curves. To generate a new license key, hash user name (or email, possibly with some app ID appended), sign the hash with your private key and encode with base-32 to get a nice key like HQYRV-OZFNZ-M3L7B-WA644-CXLG4-D7IRD-QZ6FY-GJGTO-MEXEG.
To validate the license, hash the user name as above and verify signature of the hash with your public key.
This has numerous advantages: the key is relatively short (thanks to using EC instead of RSA/DSA), the key is “random” in that a different one is generated every time for the same user name, and, crucially, there’s no keygen code in the application and a cracker cannot write a keygen without getting hold of your private key.
I have a library for doing this on GitHub: https://github.com/vslavik/ellipticlicense (it’s a fork of now-dead Objective-C project, I added portable C API and made some other improvements).
If you don't particularly care about cracking attempts how about this:
Pre-generate a certain number of completely random keys (I don't, know... say 10,000 for the sake of this example). Hash each of those keys with SHA-1.
In your program, include an array that contains the SHA-1 hashes, e.g:
static unsigned char *keys[20] =
{
// key 8WVJ-TH6R-R7TH-DXM2
{ 0xb2, 0x3c, 0xc2, 0xb3, 0xea, 0xa5, 0x69, 0xf6, 0xa6, 0x95, 0x8a, 0x75, 0xee, 0x76, 0x88, 0xa5, 0x71, 0xd9, 0x4a, 0x9e },
// many more keys follow...
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
}
When the user buys a new license (or pack of licenses) give them the appropriate number of keys, scratch the keys from the list, and that's that.
When a user enters a key in the app, hash it and iterate the list. If you find the hash, you're good to go. If you don't, the key is wrong/unauthorized.
Advantages:
- Keys can be of any length and complexity.
- If someone can reverse SHA-1 they have better things to do than break your app.
- Simple to implement.
- Simple to manage.
- If you ever run out of keys, issue an app update and add new keys at the end of the table.
- No online access needed.
Disadvantages:
- The people who want to freeload can easily hexedit your binary to set their own SHA-1 values in the table, and they can then "license" the software to themselves.
- You don't know if your paid users use the same key in 20 machines.
- Simple.
The scheme can be enhanced in many different ways. But it's a starting point for you.
