Cryptography in license verification routines
In the last post I touched upon the possible uses of cryptography in the license verification routine of shareware applications. In this post I will discuss the common use cases and give some recommendations.
A license is a sequence of characters that an application might either accept or reject. Usually a license consists of several fields such as user name, expiration date, license type, hardware id, application version etc. All those fields need to be protected from modification after a license has been issued (integrity). Also only the author of a license verification scheme should be able to produce a valid license (authentication).
These problems are what digital signing was invented to solve. But often shareware authors don’t see license verification as a problem in the realm of cryptography. Instead of using cryptography many prefer inventing their own verification algorithms that might involve solving equations, bit manipulation, randomness and other kinds of obscurity.
By not relying on proven cryptography the shareware authors weaken their copy protection schemes, allowing the creation of “clean” keygens. Meaning keygens that don’t require any application patching. When attackers don’t need to patch the application executable, they don’t have to overcome the anti-patching portion of a good copy protection scheme.
The discussion below assumes that the attacker doesn’t modify the application executable.
Symmetric-key ciphers
The idea of symmetric ciphers is simple. There is a message and there is a key. Using the key the message can be encrypted into a cipher. Then anyone possessing the key can decrypt the cipher back into the message. The key can’t be deduced from the message and the cipher, attempting to do so would mean attacking the cryptographic algorithm heads on, which is infeasible.
The Advanced Encryption Standard (AES) is probably the most popular algorithm of this kind, but others (like the IDEA from the last post) are also widely used.
A shareware author might use a symmetric cipher in the following way. The application contains both a message and the cipher as two hardcoded buffers.
The key is embedded as a field in a valid license. When validating a license the application attempts to encrypt the hardcoded message with the key extracted from the provided license. If the result is identical to the hardcoded cipher, then the license is valid.
This scheme assumes that the attacker doesn’t possess any valid licenses. Provided with a valid license the attacker could extract the key from that license and create a keygen.
This scheme improves security, but it’s a sub-optimal use of cryptography.
Asymmetric-key ciphers
Asymmetric ciphers use two keys instead of one. The public key is used for encryption and the private key for decryption. The public key can be deduced from the private key, but not the other way around.
By using asymmetric ciphers (such as RSA) a proper digital signature can be implemented.
A private key should always be private, and as such it can’t be hardcoded into an application. Doing so would break the security. Using the normal terminology of an asymmetric cipher, the procedure looks like this:
- The application author creates a license by filling in all the required fields. He then decrypts the hash of the fields by using a private key. The result is appended to the license as a separate signature field.
- The application calculates the hash of the license fields (except the signature field). It then uses the hardcoded public key to encrypt the signature appended to the license. The license is judged valid if the result of the encryption is equal to the computed hash.
Without knowing the private key, a “clean” keygen is impossible, no matter how many valid licenses are available to the keygen writer.
This table summarizes where each piece of the cryptographic scheme reside.
| Scope | Symmetric | Asymmetric |
|---|---|---|
| Author | key | private key |
| License | key | message (signature) cipher (hash calculated by application) |
| Application | message, cipher | public key |
The attacker always has access to the application, but that alone is not enough to defeat any of the two schemes. If there is no cryptography the attacker only needs the application. When there is a symmetric-key algorithm the attacker needs both the application and a valid license. When an asymmetric-key algorithm is used the attacker needs to find other ways to defeat the protection.
Conclusion
Cryptography is a helpful, indeed required, addition to any copy protection scheme that relies on license validation. But as it is always the case with cryptography–misusing it is easy.
Asymmetric ciphers have the clear advantage over symmetric ciphers because they make the possession of valid licenses by the attacker irrelevant.
One needs to remember though that even correctly used cryptography is useless if patching the application is easy. The best cryptography can do is to force the attacker to patch the executable, and engage with other parts of the protection scheme.
The only way to prevent all hacking is to hide the application code itself. Using demo versions with reduced functionality is one way. Keeping part of the application in the cloud is another. Creating a better incentive to buy the application also helps.