Know-how protection
How to prevent software theft
Software is becoming increasingly important in mechanical and plant engineering. This raises the question for both manufacturers and users: how can we ensure that there is no undesirable manipulation?
My first encounter with software protection and licensing was in 1994, when the 'Yellow Point CD' was released shortly before Cebit. This 'unlock CD' developed by the company Yellow-Point - a kind of offline store in the pre-Internet era - contained encrypted software products from well-known manufacturers such as Microsoft, Lotus and Computer Associates. To purchase the software, the customer could call the Yellow-Point hotline and pay for an unlock key for the desired software. This was a great marketing success. But technically it was a total fiasco: after just a few days, hacks were being passed on via floppy disks and mailboxes. But how did this happen? There was a bug in the implementation, so that you only had to try a few keys (256 according to the Chaos Computer Club/CCC) to get the desired software. The original software was manipulated and misused, meaning that the effort required by the attackers was extremely low.
The 'ultimate maximum penalty' for a faulty implementation is a key generator, also known as KeyGen. A manufacturer - let's call him Herbert - has produced software that he wants to sell. Two inexperienced users - Uwe and Ute - want to buy the software. An unauthorized third party, the evil Boris, has finally written a key generator. This means that he can generate a suitable license for Uwe and Ute that works with Herbert's original software. Uwe and Ute don't even realize that they are using a pirated copy. The result: Boris gets all the money and Herbert goes away empty-handed.
What did Herbert do wrong? He made a mistake in the implementation of the cryptography. Unfortunately, such mistakes are not uncommon. "I encrypt my license information with a hash algorithm" is a popular statement that makes security experts' hair stand on end. Encryption involves encoding a text in such a way that it can only be read with the appropriate key. With a hash function, the text is chopped up so that it can never be read again. You actually have the following two options:
- I encrypt my license information and decrypt it again in my software. Only my software knows the key.
- I provide my license with a hash value. Normally, a hash algorithm does not use a key. This means that anyone can have generated the hash value. Therefore, you add a secret key - also called a salt value - to the original data and then calculate the hash value. In other words: Only your own software knows the salt value and only it can then check the hash value.
The conceptual error here, however, lies in the fact that the 'secret' (i.e. the key or the salt value) required to create the license is also embedded in the software in the same form. The evil Boris only has to find this secret and he can create his KeyGen.
The key question
This can be remedied by using asymmetric cryptography. While symmetric encryption uses the same key for encryption and decryption, asymmetric encryption uses a key pair consisting of a private key and a public key. Mathematically, the public key can be derived from the private key; however, there is no way to obtain the private key from knowledge of the public key. The private key must be kept secret and only known to the owner. Anyone may know the public key.
Two examples of asymmetric methods are RSA (Rivest Shamir Adleman) and ECC (Elliptic Curve Cryptography). ECC is the more modern and flexible method. In order to achieve a level of security comparable to RSA, significantly shorter keys can be selected. While the generation of an RSA key requires complex mathematics with prime numbers, any number can be used as a private key with ECC. Another advantage of ECC is the clear separation between asymmetric encryption and signature.
The use case of a signature is the integrity and authenticity of data. This means that the data is unchanged and it can be ensured who created the data. For this purpose, the data is signed with the sender's private key. Any recipient can verify the authenticity of the data using the sender's public key.
In the licensing use case, the manufacturer Herbert embeds his public key in his software. He now creates individual licenses for his users Uwe and Ute and signs them with his private key. Herbert's software uses the embedded public key to check whether the license was really created by Herbert and whether it is unchanged.
This simple method prevents a KeyGen. The evil Boris is now forced to modify Herbert's software as well. This gives Uwe and Ute the opportunity to recognize a pirated copy, and Herbert has further options to prevent a pirated copy or make it much more difficult.
Certificates for the user
By having Herbert sign not only his licenses, but also his software, Uwe and Ute can use Herbert's public key to check whether the software really came from Herbert and is unchanged. Herbert simply sends the public key along with his software. But what if the evil Boris signs the software with his own key and encloses his own public key? This is where certificates come into play.
A certificate confirms the owner of a public key. The owner can be a person, an organization or an IT system. It contains attributes that describe the purpose of the certificate and a signature of the issuer. Herbert has a certificate issued for his public key by a certification authority such as VeriSign. The certification authority verifies Herbert's identity before creating his certificate. Now that Herbert has his certificate, he attaches it to his software instead of his public key. This allows Uwe and Ute to check the authenticity of his public key. The public key of the certification authority is used to check the certificate. But how do Uwe and Ute obtain it? And more importantly, how do Uwe and Ute know that this public key is genuine? The answer lies in the root certificates.
A root certificate verifies the authenticity of your own public key and is already available to Uwe and Ute, as root certificates are already integrated into the operating system and are also updated when the operating system is updated. Such updates are necessary if a root certificate has expired, a new one is added or a certificate has to be revoked. In other words, regular updates of the operating system are essential to keep the list of trusted root certificates up to date.
One example of such a certificate mechanism is Authenticode. Herbert provides his software with a digital signature and the operating system automatically warns Uwe and Ute if the signature is invalid. Unfortunately, it does not warn them if the signature has been removed or replaced by another signature. Uwe and Ute have to check this manually themselves.
Herbert could now come up with the idea of using such certificates as licenses. However, in this respect, he has made the calculation without the malicious user Anton. Unlike Uwe and Ute, who want to buy the software, the malicious Anton intends to use a pirated copy. He doesn't care at all whether the software issues a warning that the signature is incorrect when it is started. He would also never think of manually checking the signature himself, and he would not hesitate to manipulate his computer in order to use the pirated copy. So certificates alone are not enough to realize secure licensing.
Certificates as licenses
The solution to this is asymmetric encryption. With asymmetric encryption, any person can encrypt a text, but only a dedicated recipient can decrypt the text again. The recipient's public key is used for encryption. The recipient uses their private key for decryption.
This method is perfect for software protection with the binding of a license to a specific computer. Herbert implements a mechanism in his software that generates a fingerprint of the computer. In a simple case, this can be the serial number of the hard disk. He uses this fingerprint to generate a private key. With ECC, this fingerprint can easily be used as a private key. This is another reason to prefer this method to RSA.
Uwe now starts Herbert's software. This generates the key pair and sends the public key to Herbert as part of an online activation. Herbert uses it to encrypt the license for Uwe and sends it back. Only Herbert's software on Uwe's computer can now decrypt and use the license. For everyone else, the license is just 'gibberish'. If Ute performs the same action, she receives another encrypted license that can only be decrypted on her computer.
The best of both worlds
The malicious Anton cannot use Herbert's software with either Uwe's or Ute's license file. But the evil Boris - our hacker - could in this case write a KeyGen and generate a license. Therefore, a mixture of signatures/certificates and encryption is the final solution for good software protection - i.e. a certificate-based solution with encryption, as implemented by Wibu-Systems in CodeMeter, for example.
On the one hand, each license file is encrypted exactly for the respective computer. A fingerprint is used as the private key, which is made up of many different hardware properties of Uwe and Ute's computer. These properties are included in the fingerprint with different weightings. The exact composition of this fingerprint is a trade secret of Wibu-Systems. A patented process - known as SmartBind - is used to add a tolerance so that the hardware of Uwe and Ute can change within certain limits and the private key is still retained.
Secondly, the license file is signed by the manufacturer Herbert with a private key. He automatically adds a certificate that he has received from Wibu-Systems. At runtime - i.e. when his software checks the license - CodeMeter Runtime can use this certificate to check the validity of the license. In addition, Herbert can use the certificate to authorize his users to pass on the license or lend it out for a limited period.
Ultimately, software manufacturers like Herbert are always faced with the question of whether they should implement licensing themselves or purchase an appropriate solution. The more extensive the requirements become and the more security you want to achieve against pirated copies, the more you should opt for the latter.
Author:
Rüdiger Kügler is a security expert at Wibu-Systems.

















