A product key, also known as a software key, serial key or activation key, is a specific software-based key for a computer program. It certifies that the copy of the program is original.
Product keys consist of a series of numbers and/or letters. This sequence is typically entered by the user during the installation of computer software, and is then passed to a verification function in the program. This function manipulates the key sequence according to a mathematical algorithm and attempts to match the results to a set of valid solutions.
Standard key generation, where product keys are generated mathematically, is not completely effective in stopping copyright infringement of software, as these keys can be distributed. In addition, with improved communication from the rise of the Internet, more sophisticated attacks on keys such as cracks (removing the need for a key) and product key generators have become common.
Because of this, software publishers use additional product activation methods to verify that keys are both valid and uncompromised. One method assigns a product key based on a unique feature of the purchaser's computer hardware, which cannot be as easily duplicated since it depends on the user's hardware. Another method involves requiring one-time or periodical validation of the product key with an internet server (for games with an online component, this is done whenever the user signs in). The server can deactivate unmodified client software presenting invalid or compromised keys. Modified clients may bypass these checks,[1] but the server can still deny those clients information or communication.
Windows 95 retail product keys take the form XXX-XXXXXXX.[2] To determine whether the key is valid, Windows 95 performs the following checks:
If all checks pass, the product key is valid. Consequently a product key of 000-0000000 would be considered valid under these conditions.
Windows 95 OEM keys take the form XXXXX-OEM-XXXXXXX-XXXXX.
Windows XP uses an installation ID, product ID, and a product key for activation.[3] [4]
The installation ID is a 50 digit decimal string that is divided into 5 groups of six digits each with 2 digits at the end, which takes the form of XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX. The installation ID is regenerated every time msoobe.exe is ran.
The right most digit in each group of the installation ID is a check digit.
Removing the check digits results in a 41-digit decimal encoded 136 bit multi precision integer, which is stored in little endian byte order as a byte array.
The lower 16 bytes of the Installation ID are encrypted, whereas the most significant byte is kept in plaintext. The cryptographic algorithm used to encrypt the Installation ID is a proprietary four-round Feistel cipher. Since the block of input bytes passed to a Feistel cipher is divided into two blocks of equal size, this class of ciphers is typically applied to input blocks consisting of an even number of bytes in this case the lower 16 of the 17 input bytes. The round function of the cipher is the SHA-1 message digest algorithm keyed with a four-byte sequence.
Let + denote the concatenation of two byte sequences, ^ the XOR operation, L and R the left and right eight-byte input half for one round, L' and R' the output halves of said round, and First-8 a function that returns the first eight bytes of an SHA-1 message digest.
Then one round of decryption looks as follows.
L' = R ^ First-8(SHA-1(L + Key))
R' = L
The result of the decryption is 16 bytes of plaintext, which are together with the 17th unencrypted byte which will be interpreted as four double words in little endian byte order followed by a single byte.
| H1 | Double word | 0 | |
| H2 | Double word | 4 | |
| P1 | Double word | 8 | |
| P2 | Double word | 12 | |
| P3 | Byte | 16 |
The Product ID consists of five groups of decimal digits, as in AAAAA-BBB-CCCCCCC-DDEEE.
The mapping between the Product ID in decimal representation and its binary encoding in the double words P1 and P2 and the byte P3 is summarized in the following table.
| AAAAA | 17 Bits | Bit 0 to bit 16 of P1 | Always 55034 (in Windows XP RC1) | |
| BBB | 10 Bits | Bit 17 to bit 26 of P1 | Most significant three digits of Raw Product Key | |
| CCCCCCC | 28 Bits | Bit 27 to bit 31 of P1 (lower 5 bits) and Bit 0 to bit 22 of P2 (upper 23 bits) | Least significant six digits of Raw Product Key and check digit | |
| DDEEE | 17 Bits | Bit 23 to bit 31 of P2 (lower 9 bits) and Bit 0 to bit 7 of P3 (upper 8 bits) | DD = Index of the public key used to verify the Product keyEEE = Random value |
The Product key takes the form as XXXXX-XXXXX-XXXXX-XXXXX-XXXXX. Each character is one of the following 24 letters and digits: B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
The 25 characters of the Product Key form a base-24 encoding of the binary representation of the Product Key. The Product Key is a multi-precision integer of roughly 115 bits, which is stored in little endian byte order in an array of 15 bytes. Of these 15 bytes the least significant four bytes contain the Raw Product Key in little endian byte order. The least significant bit is removed by shifting this 32-bit value to the left by one bit position. The eleven remaining bytes form a digital signature, allowing verification of the authenticity of the Product Key by means of a hard-coded public key.
To obtain the CCCCCCC component, a check digit is appended, and the check digit that is chosen such that the sum of all digits, including the check digit, is divisible by seven. For verifying a Product Key, more than one public key is available. If verification with the first public key fails, the second is tried, etc. The DD component of the Product ID specifies which of the public keys in this sequence was successfully used to verify the Product Key.
The hardware configuration linked to the Installation ID is represented by the two double words H1 and H2. For this purpose, the double words are divided into twelve bit-fields.
| H1 | 0 | 10 | Volume serial number string of system volume | |
| H1 | 10 | 10 | Network adapter MAC address string | |
| H1 | 20 | 7 | CD-ROM drive hardware identification string | |
| H1 | 27 | 5 | Graphics adapter hardware identification string | |
| H2 | 0 | 3 | Unused, set to 001 | |
| H2 | 3 | 6 | CPU serial number string | |
| H2 | 9 | 7 | Hard drive hardware identification string | |
| H2 | 16 | 5 | SCSI host adapter hardware identification string | |
| H2 | 21 | 4 | IDE controller hardware identification string | |
| H2 | 25 | 3 | Processor model string | |
| H2 | 28 | 3 | RAM size | |
| H2 | 31 | 1 | 1 = dockable, 0 = not dockable |
The hash result is obtained by feeding the hardware identification string into the MD5 message digest algorithm and picking the number of bits required for a bit-field from predetermined locations in the resulting message digest. Different predetermined locations are used for different bit-fields. In addition, a hash result of zero is avoided by calculating
Hash=(Hash%BitFieldMax)+1
The bit-field related to the amount of RAM available to the operating system is calculated differently from the other bit-fields as shown in the table.
| 0 | (bit-field is unused) | |
| 1 | Below 32 MB | |
| 2 | between 32 MB and 63 MB | |
| 3 | Between 64 MB and 127 MB | |
| 4 | Between 128 MB and 255 MB | |
| 5 | Between 256 MB and 511 MB | |
| 6 | Between 512 MB and 1023 MB | |
| 7 | Above 1023 MB |
wpa.dbl is the RC4-encrypted database that stores, expiration information, the confirmation ID of an activated installation, the bit-field values representing the current hardware configuration, and the bit-field values representing the hardware configuration at the time of product activation, etc. The current hardware configuration is automatically updated each time the hardware configuration is modified in order to reflect the changes, while the values representing the hardware configuration at the time of product activation is fixed. When judging whether re-activation is necessary, the bit-field values of the current hardware configuration is compared to the hardware configuration at the time of activation.
All bit-fields with the exception of the unused field and the 'dockable' field are compared. If more than three of these ten bit-fields have changed in the current hardware configuration since product activation, re-activation is required.
If bit 31 of H2 indicates that our computer supports a docking station, only seven of the ten bit-fields mentioned above are compared. The bit-fields corresponding to the SCSI host adapter, the IDE controller, and the graphics board are omitted. Of these remaining seven bit-fields, only up to three may change without requiring re-activation.
Some of the most effective product key protections are controversial due to inconvenience, strict enforcement, harsh penalties and, in some cases, false positives. Some product keys use uncompromising digital procedures to enforce the license agreement.
Product keys are somewhat inconvenient for end users. Not only do they need to be entered whenever a program is installed, but the user must also be sure not to lose them. Loss of a product key usually means the software is useless once uninstalled, unless, prior to uninstallation, a key recovery application is used (although not all programs support this).[5]
Product keys also present new ways for distribution to go wrong. If a product is shipped with missing or invalid keys, then the product itself is useless. For example, all copies of originally shipped to Australia without product keys.[6]
There are many cases of permanent bans enforced by companies detecting usage violations. It is common for an online system to immediately blacklist an account caught running cracks or, in some cases, cheats. This results in a permanent ban. Players who wish to continue use of the software must repurchase it. This has inevitably led to criticism over the motivations of enforcing permanent bans.
Particularly controversial is the situation which arises when multiple products' keys are bound together. If products have dependencies on other products (as is the case with expansion packs), it is common for companies to ban all bound products. For example, if a fake key is used with an expansion pack, the server may ban legitimate keys from the original game. Similarly, with Valve's Steam service, all products the user has purchased are bound into the one account. If this account is banned, the user will lose access to every product associated with the same account.[7]
This "multi-ban" is highly controversial, since it bans users from products which they have legitimately purchased and used.
Bans are enforced by servers immediately upon detection of cracks or cheats, usually without human intervention. Sometimes, legitimate users are wrongly deemed in violation of the license, and banned. In large cases of false positives, they are sometimes corrected (as happened in World of Warcraft.[8]) However, individual cases may not be given any attention.
A common cause of false positives (as with the World of Warcraft case above) is users of unsupported platforms. For example, users of Linux can run Windows applications through compatibility layers such as Wine and Cedega. This software combination sometimes triggers the game's server anti-cheating software, resulting in a ban due to Wine or Cedega being a Windows API compatibility layer for Linux, so it is considered third-party (cheating) software by the game's server.[9]