Create and validate secure "License Keys" for your proprietary code and embed up to 16-bits of "configuration data" into the key. This code is flexible and may be used in many different licensing schemes.
Everyone is familiar with getting license keys to activate software. These keys are normally based on various encryption schemes, and serve to validate that a particular user is authorized to install or run the software. The code presented here provides an easy way to integrate this functionality into your own programs.
The keys generated by the sample application are MD5 hashes of a "Licensee" name, a "Serial Number, and a "secret" program name string that is embedded into the code. We then convert the hexadecimal 32-character string to Base32 to shorten the resulting key down to 26 characters. This is easier for end-users to type and looks better and more professional as well.
The code is pretty straight-forward for the most part, and can be easily translated into other languages such as C, C++, C#, Java, etc. and is presented in as "generic" of a Visual Basic form as possible to permit easy integration into applications. It can even be used in VBA applications such as Microsoft Access if desired.
Please note that all code in this article is licensed under the LGPL, so it can be incorporated into your programs with no royalties and doesn't modify the licensing terms of your proprietary code in any way. We do ask that if you make any changes to the key generation code itself that you release the code under the same terms as you received it.
Additionally, this code provides some useful string functions to encode/decode binary values encoded in a string to Base32 and to bitwise left and right shift these values by an arbitrary number of bits.
Using the Code
Simply include the KeyCodes.bas, StrFuncs.bas, and MD5_Crypt.bas files into your project. You can prompt for whatever information you consider to be relevant to your licensing scheme, and it should end up in two string values and one
LONG integer value indicating the capabilities you wish to embed into the key code.
It is expected that users of this code will modify the key generation to meet their needs. The keycodes.bas file routines are easily modified to provide different key values and can form an easy base to build your own key code routines. One change that comes to mind is to shorten the
Base32 string from 26-characters to 25-characters and then grouping the "digits" in groups of five to provide nicer-looking keys.
Here's the main code that generates the key based on text boxes:
Private Const MyProductName = "KeyCodeDemoV1"
. . .
If Not (UserNameT = "") Or Not (ProdNameT = "") Then
RawKey = GenKeyString(UserNameT, ProdNameT & MyProductName, FeatID)
BinKey = HexStrToBinStr(RawKey)
KeyCode = FormatKeyCode(Base32Enc(BinKey), 4)
KeyCode = "Please Enter Licensee and/or Serial Number"
. . .
The keys generated by this code are relatively secure, as they are based around an MD5 hash of the data used to generate the key. You can improve security by generating a GUID during the installation, and concatenating it with the "user name" field, and then generating the keys via an online submission process. This is left as an exercise to the reader.
Key tampering is highly discouraged by the code's design. Each key is generated from an MD5 hash of the licensee, serial, and your "secret". Once this hash is created, we XOR the "permissions" bits with the last two characters of the key, then drop the first two characters of the key, run another MD5 hash of the truncated key with permissions, and then use the first and last bytes of the second MD5 hash as the first two characters of the final binary key value. These bytes verify the integrity of the permissions bits.
It is also possible to use an algorithm on the final keys to "scramble" them. Just ensure to "unscramble" them prior to attempts to verify the key with what it should be.
- Create a key...
- Entering a key to check...
- A successful check...
- A check that failed due to an attempt to modify key "permission" byte...
- Initial article - 5/23/2007