Registration Key

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 an algorithm or mathematical formula and attempts to match the results to a set of valid solutions. If they match, the program is activated, permitting its use or unlocking features. With knowledge about the algorithm used, such as that obtained via reverse engineering of the program, it is possible to create programs called keygens that generate these keys for a particular program.

Effectiveness

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, duplicated, missing or otherwise compromised keys. Modified clients may bypass these checks, but the server can still deny those clients information or communication.

Examples

Windows 95 retail key

Windows 95 retail product keys take the form XXX-XXXXXXX. To determine whether the key is valid, Windows 95 performs the following checks:

* The first 3 characters must not be equal to 333, 444, 555, 666, 777, 888 or 999.
* The last 7 characters must all be numbers from 0-8.
* The sum of the last 7 numbers must be divisible by 7 with no remainder.
* The fourth character is unchecked.

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 key

Windows 95 OEM keys take the form XXXXX-OEM-XXXXXXX-XXXXX.

* The first 3 characters must be a number between 0-366.
* The next 2 characters must be a number between 04-93.
* The next 3 characters must be OEM.
* The sum of the next 7 numbers must be divisible by 7 with no remainder.
* The rest of the characters are unchecked.

Windows XP retail key

Windows XP uses an installation ID, product ID, and a product key for activation.

Installation ID

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.

= Check digits

=
The right most digit in each group of the installation ID is a check digit.
* Each check digit is calculated by adding the other five digits in its group.
* Then adding the digits in that group in the even positions a second time.
* Then dividing the sum of them by 7.
* The remainder is the value of the check digit in its group.

= Decoding

=
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.

= Decryption

=
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 and H2 specify the hardware configuration that the Installation ID is linked to. P1 and P2 as well as the remaining byte P3 contain the Product ID associated with the Installation ID.

Product ID

The Product ID consists of five groups of decimal digits, as in AAAAA-BBB-CCCCCCC-DDEEE.

= Decoding

=
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.

Product key

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.

= Hardware information bit-fields

=
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.

If docking is possible, the activation mechanism will be more tolerant with respect to future hardware modifications. If the hardware component corresponding to one of the remaining ten bit-fields is present, the respective bit-field contains a non-zero value describing the component. A value of zero marks the hardware component as not present. All hardware components are identified by a hardware identification string obtained from the registry. Hashing this string provides the value for the corresponding bit-field.

= Hashing

=
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$. Where BitFieldMax is the maximal value that may be stored in the bit-field in question, e.g. 1023 for a 10-bit bit-field, and 'x % y' denotes the remainder of the division of x by y. This results in values between 1 and BitFieldMax. The obtained value is then stored in the respective bit-field.

= RAM bit-field

=
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.

Note that the amount of RAM is retrieved by calling the GlobalMemoryStatus() function, which reports a few hundred kilobytes less than the amount of RAM physically installed. So, 128 MB of RAM would typically be classified as "between 64 MB and 127 MB".

Hardware modifications

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.

= Non-dockable computers

=
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.

= Dockable computers

=
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.

Controversy

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.

Inconvenience

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).

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 '' Splinter Cell: Pandora Tomorrow'' originally shipped to Australia without product keys.

Enforcement and penalties

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.

This "multi-ban" is highly controversial, since it bans users from products which they have legitimately purchased and used.

False positives

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''.Blizzard Unbans Linux World of Warcraft Players
''Softpedia'') 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.

See also

* Biometric passport
* Cryptographic hash function
* Intel Upgrade Service
* Keygen
* License manager
* Product activation
* Serial number
* Software license server
* Volume license key

References

{{reflist

Copyright infringement