How are software license keys generated?

by

For old-school CD keys, it was just a matter of making up an algorithm for which CD keys (which could be any string) are easy to generate and easy to verify, but the ratio of valid-CD-keys to invalid-CD-keys is so small that randomly guessing CD keys is unlikely to get you a valid one.

INCORRECT WAY TO DO IT:

Starcraft and Half-life both used the same checksum, where the 13th digit verified the first 12. Thus, you could enter anything for the first 12 digits, and guess the 13th (there’s only 10 possibilities), leading to the infamous 1234-56789-1234

The algorithm for verifying is public, and looks something like this:

x = 3;
for(int i = 0; i < 12; i++)
{
    x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;

CORRECT WAY TO DO IT

Windows XP takes quite a bit of information, encrypts it, and puts the letter/number encoding on a sticker. This allowed MS to both verify your key and obtain the product-type (Home, Professional, etc.) at the same time. Additionally, it requires online activation.
The full algorithm is rather complex, but outlined nicely in this (completely legal!) paper, published in Germany.

Of course, no matter what you do, unless you are offering an online service (like World of Warcraft), any type of copy protection is just a stall: unfortunately, if it’s any game worth value, someone will break (or at least circumvent) the CD-key algorithm, and all other copyright protections.

REAL CORRECT WAY TO DO IT:

For online-services, life is a bit simpler, since even with the binary file you need to authenticate with their servers to make any use of it (eg. have a WoW account). The CD-key algorithm for World of Warcraft – used, for instance, when buying playtime cards – probably looks something like this:

  1. Generate a very large cryptographically-secure random number.
  2. Store it in our database and print it on the card.

    Then, when someone enters a playtime-card number, check if it’s in the database, and if it is, associate that number with the current user so it can never be used again.

For online services, there is no reason not to use the above scheme; using anything else can lead to problems.

More Related Contents:

  1. Fundamental difference between Hashing and Encryption algorithms
  2. Is “double hashing” a password less secure than just hashing it once?
  3. Non-random salt for password hashes
  4. Where do you store your salt strings?
  5. Why is using a Non-Random IV with CBC Mode a vulnerability?
  6. How to properly do private key management
  7. What is the most secure seed for random number generation?
  8. Where is the PEM file format specified?
  9. RSA signature size?
  10. How can I hash passwords in postgresql?
  11. What is the clash rate for md5? [closed]
  12. What is token-based authentication?
  13. Prevent PDF file from downloading and printing
  14. Are HTTPS headers encrypted?
  15. How secure is a HTTP POST?
  16. Stopping users voting multiple times on a website
  17. What’s the right OAuth 2.0 flow for a mobile app
  18. Moving old passwords to new hashing algorithm?
  19. Best way for a ‘forgot password’ implementation? [closed]
  20. IIS7, web.config to allow only static file handler in directory /uploads of website
  21. Should JWT be stored in localStorage or cookie? [duplicate]
  22. Is it worth encrypting email addresses in the database?
  23. How to do stateless (session-less) & cookie-less authentication?
  24. Too much data for RSA block fail. What is PKCS#7?
  25. Is it possible to reverse a SHA-1 hash?
  26. Secure Google Cloud Functions http trigger with auth
  27. What is the appropriate way to manage API secrets within a Google Apps script?
  28. Keygen tag in HTML5
  29. Remember me Cookie best practice?
  30. buffer overflow example from Art of Exploitation book

Leave a Comment