How are software license keys generated

Question

License keys are the defacto-standard as an anti-piracy measure  To be honest  this strikes me as  in Security Through Obscurity  although I really have no idea how license keys are generated  What is a good  secure  example of license key generation  What cryptographic primitive  if any  are they using  Is it a message digest  If so  what data would they be hashing  What methods do developers employ to make it difficult for crackers to build their own key generators  How are key generators made

User · Answer

I realize that this answer is about 10 years late to the party.

A good software license key/serial number generator consists of more than just a string of random characters or a value from some curve generator. Using a limited alphanumeric alphabet, data can be embedded into a short string (e.g. XXXX-XXXX-XXXX-XXXX) that includes all kinds of useful information such as:

Date created or the date the license expires
Product ID, product classification, major and minor version numbers
Custom bits like a hardware hash
Per-user hash checksum bits (e.g. the user enters their email address along with the license key and both pieces of information are used to calculate/verify the hash).

The license key data is then encrypted and then encoded using the limited alphanumeric alphabet. For online validation, the license server holds the secrets for decrypting the information. For offline validation, the decryption secret(s) are included with the software itself along with the decryption/validation code. Obviously, offline validation means the software isn't secure against someone making a keygen.

Probably the hardest part about creating a license key is figuring out how to cram as much data as possible into as few bytes as possible. Remember that users will be entering in their license keys by hand, so every bit counts and users don't want to type extremely long, complex strings in. 16 to 25 character license keys are the most common and balance how much data can be placed into a key vs. user tolerance for entering the key to unlock the software. Slicing up bytes into chunks of bits allows for more information to be included but does increase code complexity of both the generator and validator.

Encryption is a complex topic. In general, standard encryption algorithms like AES have block sizes that don't align with the goal of keeping license key lengths short. Therefore, most developers making their own license keys end up writing their own encryption algorithms (an activity which is frequently discouraged) or don't encrypt keys at all, which guarantees that someone will write a keygen. Suffice it to say that good encryption is hard to do right and a decent understanding of how Feistel networks and existing ciphers work are prerequisites.

Verifying a key is a matter of decoding and decrypting the string, verifying the hash/checksum, checking the product ID and major and minor version numbers in the data, verifying that the license hasn't expired, and doing whatever other checks need to be performed.

Writing a keygen is a matter of knowing what a license key consists of and then producing the same output that the original key generator produces. If the algorithm for license key verification is included in and used by the software, then it is just a matter of creating software that does the reverse of the verification process.

To see what the entire process looks like, here is a blog post I recently wrote that goes over choosing the license key length, the data layout, the encryption algorithm, and the final encoding scheme:

https://cubicspot.blogspot.com/2020/03/adventuring-deeply-into-software-serial.html

A practical, real-world implementation of the key generator and key verifier from the blog post can be seen here:

https://github.com/cubiclesoft/php-misc/blob/master/support/serial_number.php

Documentation for the above class:

https://github.com/cubiclesoft/php-misc/blob/master/docs/serial_number.md

A production-ready open source license server that generates and manages license keys using the above serial number code can be found here:

https://github.com/cubiclesoft/php-license-server

The above license server supports both online and offline validation modes. A software product might start its existence with online only validation. When the software product is ready to retire and no longer supported, it can easily move to offline validation where all existing keys continue to work once the user upgrades to the very last version of the software that switches over to offline validation.

A live demo of how the above license server can be integrated into a website to sell software licenses plus an installable demo application can be found here (both the website and demo app are open source too):

https://license-server-demo.cubiclesoft.com/

Full disclosure: I'm the author of both the license server and the demo site software.

User · Answer

All of the CD only copy protection algorithms inconvience honest users while providing no protection against piracy whatsoever   The  pirate  only need to have access to one legitimate cd and its access code  he can then make n copies and distribute them   It does not matter how cryptographically secure you make the code  you need to supply this with the CD in plain text or an legitimate user cannot activite the software   Most secure schemes involve either the user providing the software supplier with some details of the machine which will run the software  cpu serial numbers  mac addresses  Ip address etc    or  require online access to register the software on the suppliers website and in return receive an activitation token  The first option requires a lot of manual administration and is only worth it for very high value software  the  second option can be spoofed and is absolutly infuriating if you have limited network access or you are stuck behind a firewall   On the whole its much easier to establish a trust relationship with your customers

User · Answer

CD-Keys aren t much of a security for any non-networked stuff  so technically they don t need to be securely generated  If you re on  net  you can almost go with Guid NewGuid     Their main use nowadays is for the Multiplayer component  where a server can verify the CD Key  For that  it s unimportant how securely it was generated as it boils down to  Lookup whatever is passed in and check if someone else is already using it    That being said  you may want to use an algorhithm to achieve two goals    Have a checksum of some sort  That allows your Installer to display  Key doesn t seem valid  message  solely to detect typos  Adding such a check in the installer actually means that writing a Key Generator is trivial as the hacker has all the code he needs  Not having the check and solely relying on server-side validation disables that check  at the risk of annoying your legal customers who don t understand why the server doesn t accept their CD Key as they aren t aware of the typo  Work with a limited subset of characters  Trying to type in a CD Key and guessing  Is this an 8 or a B  a 1 or an I  a Q or an O or a 0   - by using a subset of non-ambigous chars digits you eliminate that confusion    That being said  you still want a large distribution and some randomness to avoid a pirate simply guessing a valid key  that s valid in your database but still in a box on a store shelf  and screwing over a legitimate customer who happens to buy that box

User · Answer

When I originally wrote this answer it was under an assumption that the question was regarding  offline  validation of licence keys   Most of the other answers address online verification  which is significantly easier to handle  most of the logic can be done server side    With offline verification the most difficult thing is ensuring that you can generate a huge number of unique licence keys  and still maintain a strong algorithm that isnt easily compromised  such as a simple check digit   I m not very well versed in mathematics  but it struck me that one way to do this is to use a mathematical function that plots a graph  The plotted line can have  if you use a fine enough frequency  thousands of unique points  so you can generate keys by picking random points on that graph and encoding the values in some way    As an example  we ll plot this graph  pick four points and encode into a string as  0 -500 100 -300 200 -100 100 600   We ll encrypt the string with a known and fixed key  horribly weak  but it serves a purpose   then convert the resulting bytes through Base32 to generate the final key  The application can then reverse this process  base32 to real number  decrypt  decode the points  and then check each of those points is on our secret graph   Its a fairly small amount of code which would allow for a huge number of unique and valid keys to be generated  It is however very much security by obscurity  Anyone taking the time to disassemble the code would be able to find the graphing function and encryption keys  then mock up a key generator  but its probably quite useful for slowing down casual piracy

User · Answer

There are also DRM behaviors that incorporate multiple steps to the process   One of the most well known examples is one of Adobe s methods for verifying an installation of their Creative Suite   The traditional CD Key method discussed here is used  then Adobe s support line is called   The CD key is given to the Adobe representative and they give back an activation number to be used by the user   However  despite being broken up into steps  this falls prey to the same methods of cracking used for the normal process   The process used to create an activation key that is checked against the original CD key was quickly discovered  and generators that incorporate both of the keys were made   However  this method still exists as a way for users with no internet connection to verify the product   Going forward  it s easy to see how these methods would be eliminated as internet access becomes ubiquitous

User · Answer

If you aren t particularly concerned with the length of the key  a pretty tried and true method is the use of public and private key encryption   Essentially have some kind of nonce and a fixed signature   For example  0001-123456789  Where 0001 is your nonce and 123456789 is your fixed signature   Then encrypt this using your private key to get your CD key which is something like  ABCDEF9876543210  Then distribute the public key with your application  The public key can be used to decrypt the CD key  ABCDEF9876543210   which you then verify the fixed signature portion of   This then prevents someone from guessing what the CD key is for the nonce 0002 because they don t have the private key   The only major down side is that your CD keys will be quite long when using private   public keys 1024-bit in size  You also need to choose a nonce long enough so you aren t encrypting a trivial amount of information   The up side is that this method will work without  activation  and you can use things like an email address or licensee name as the nonce

User · Answer

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  lt  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         Generate a very large cryptographically-secure random number      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

User · Answer

The key system must have several properties    very few keys must be valid valid keys must not be derivable even given everything the user has  a valid key on one system is not a valid key on another  others   One solution that should give you these would be to use a public key signing scheme  Start with a  system hash   say grab the macs on any NICs  sorted  and the CPU-ID info  plus some other stuff  concatenate it all together and take an MD5 of the result  you really don t want to be handling personally identifiable information if you don t have to   append the CD s serial number and refuse to boot unless some registry key  or some datafile  has a valid signature for the blob  The user activates the program by shipping the blob to you and you ship back the signature   Potential issues include that you are offering to sign practically anything so you need to assume someone will run a chosen plain text and or chosen ciphertext attacks  That can be mitigated by checking the serial number provided and refusing to handle request from invalid ones as well as refusing to handle more than a given number of queries from a given s n in an interval  say 2 per year   I should point out a few things  First  a skilled and determined attacker will be able to bypass any and all security in the parts that they have unrestricted access to  i e  everything on the CD   the best you can do on that account is make it harder to get illegitimate access than it is to get legitimate access  Second  I m no expert so there could be serious flaws in this proposed scheme

User · Answer

You can use and implement Secure Licensing API from very easily in your Software Projects using it  you need to download the desktop application for creating secure license from https   www systemsoulsoftwares com    Creates unique UID for client software based on System Hardware CPU Motherboard Hard-drive   UID acts as Private Key for that unique system  Allows to send Encrypted license string very easily to client system  It verifies license string and works on only that particular system This method allows software developers or company to store more information about software developer distributor services features client It gives control for locking and unlocked the client software features  saving time of developers for making more version for same software with changing features It take cares about trial version too for any number of days It secures the License timeline by Checking DateTime online during registration It unlocks all hardware information to developers It has all pre-build and custom function that developer can access at every process of licensing for making more complex secure code

User · Answer

I ve not got any experience with what people actually do to generate CD keys  but  assuming you re not wanting to go down the road of online activation  here are a few ways one could make a key    Require that the number be divisible by  say  17   Trivial to guess  if you have access to many keys  but the majority of potential strings will be invalid   Similar would be requiring that the checksum of the key match a known value  Require that the first half of the key  when concatenated with a known value  hashes down to the second half of the key   Better  but the program still contains all the information needed to generate keys as well as to validate them  Generate keys by encrypting  with a private key  a known value   nonce   This can be verified by decrypting using the corresponding public key and verifying the known value   The program now has enough information to verify the key without being able to generate keys    These are still all open to attack  the program is still there and can be patched to bypass the check   Cleverer might be to encrypt part of the program using the known value from my third method  rather than storing the value in the program   That way you d have to find a copy of the key before you could decrypt the program  but it s still vulnerable to being copied once decrypted and to having one person take their legit copy and use it to enable everyone else to access the software

User · Answer

Check tis article on Partial Key Verification which covers the following requirements    License keys must be easy enough to type in  We must be able to blacklist  revoke  a license key in the case of chargebacks or purchases with stolen credit cards  No    phoning home    to test keys   Although this practice is becoming more and more prevalent  I still do not appreciate it as a user  so will not ask my users to put up with it  It should not be possible for a cracker to disassemble our released application and produce a working    keygen    from it  This means that our application will not fully test a key for verification  Only some of the key is to be tested  Further  each release of the application should test a different portion of the key  so that a phony key based on an earlier release will not work on a later release of our software  Important  it should not be possible for a legitimate user to accidentally type in an invalid key that will appear to work but fail on a future version due to a typographical error

[security] How are software license keys generated?

Examples related to security

Examples related to cryptography

Examples related to license-key