Protecting the Integrity of Software

A common use case of software certificates is code signing: the developer of a software application signs the code with a private key. A certificate is produced by a trusted certification body and links the public key with the identity of the software developer. This allows the end user to verify which developer made the software he or she is using and whether it has been tampered with. This common mechanism was originally developed to protect end users from the all too frequent threat of viruses. It is not, however, enough to give the software developers themselves a means of avoiding piracy or tampering. This is where AxProtector and ExProtector enter the fray.

Windows uses a built-in code signing mechanism (Authenticode) to notify users when they are using software from an unknown source, that is, software that is not signed, whose certificate cannot be traced back to a trusted root certificate, or whose signature is incorrect. However, the users are only giving a simple warning message, and they can even opt out of these messages. Little reason for the makers or users of pirated software to stop their wrongdoings.

Windows - AxProtector

AxProtector encrypts the entire executable file (.exe) and appends a fingerprint with a dedicated signature. The public key is also hidden within the application.

Trust no one, but yourself – that is the thinking behind this approach, which has the protected application check itself upon launching. If its signature does not match the application in the RAM, the application will close and notify the user. With AxProtector, the application trusts itself alone, but that is not the only step that goes beyond the standard protections built into Windows. The protected application checks itself in the active RAM, and not simply the files stored on the hard drive. This means that any changes introduced by hackers after launching are also identified.

Applications and Libraries

One could wonder whether a hidden fingerprint (checksum) might not be enough and deliver the same results as such a check of a built-in signature. This might be true of applications that consist of single .exe files. The main advantage of the system is particularly evident when the application in question consists of an .exe file and several libraries (.dll).

In such cases, AxProtector signs the .exe itself and all related .dll libraries. When a protected library is loaded, the .exe verifies the integrity of the .dll, and is in turn verified by the .dll. As the developer, you can decide whether the .dll can be accessed only by a specific (your own) application. And it is up to you to say which .dlls need to have a valid signature to be accessed.

This opens up new possibilities for other use cases and for other threat scenarios:

• A hacker might create a changed copy of one of your .dlls. He or she might replace the .dll that tests your application’s copy protection with a .dll that always reports a positive response. AxProtector prevents such sleight-of-hand swapping, making the hacker’s work considerably harder. Relocating copy protection to an external library in this manner is, however, never a recommended option.
• A hacker might use a library with your intellectual property for his or her own application. The integrity check instructs the .dll that it is not being used for the application you have authorized, and it simply stops working.

Why use signatures? Answering this question recalls the chicken-and-egg problem: For the .exe to check the .dll, it would have to know its checksum, which needs to be stored in the .exe file. But for the .dll to check the .exe in turn, it would also need to include the .exe’s checksum, which would change the .dll and void the original checksum in the .exe file.

Using signatures means that the public key alone needs to be built into all modules (.exe and all .dll files). A private key is used to sign each individual module, and the signature is appended to each module. Every piece can therefore check every other piece, and individual pieces in the puzzle can even be updated without affecting the other pieces.

ExProtector – Embedded Devices

AxProtector produces protected applications or libraries that decrypt themselves. ExProtector takes this one step further and protects applications, libraries, or even entire operating systems on an embedded device. To launch or execute any protected element, a specific module – the ExEngine – is first integrated in the executing piece. If the entire operating system image (e.g. a VIP in VxWorks) is encrypted, the ExEngine is integrated in the bootloader itself. If only individual applications or libraries (e.g. RTPs or DKMs in VxWorks) are encrypted, the ExEngine operates from within the operating system.

When setting up the protection, you can determine whether the protected software is encrypted, signed, or signed and encrypted. Encryption offers protection against reverse engineering; signatures guarantee the software’s integrity.

As in the case of AxProtector, the encryption uses a key from the license when AES-encrypting the files. The signature uses a private key to sign the fingerprint in the application. Both the AES key and the signature key are stored securely in a master dongle (the Firm Security Box – FSB). Both keys are safe against unauthorized access or illicit use.

Managing Permissions

Simple set-ups include single or very few master dongles, each containing the same private key. The related public key is integrated in the ExEngine when developing the software for the embedded device.

ExProtector also helps with managing permissions. For this purpose, each master dongle is given its own private key for the code signature. Certificates are produced by a central actor to define the permissions for each master dongle, which can distinguish between different application levels or types and batches of devices.

The number of application levels is fixed already when integrating the ExEngine in the embedded device. In a simple scenario, this would distinguish between operating systems, applications, and settings. Device types and batches can also be defined individually.

This system allows the producer of embedded devices to create certificates with which the end users can update applications on their devices themselves, while updating the operating system as a whole remains the preserve of the original developer. The user can only load operating system images that the original developer has signed. The system also allows the differentiated and sophisticated handling of the permissions even at the original developer himself: for instance, Production alone could have the right to sign software for production devices, whereas developers could only sign trial devices. CodeMeter offers you a signing tool for the simple creation and administration of the certificates you need.

Conclusions

Whether for embedded devices or PCs with run-of-the-mill operating systems, AxProtector and ExProtector protect your software reliably with encryption against reverse engineering and with signed code against later tampering. Used on standard operating systems, AxProtector is the living embodiment of the principle “Trust no one, but yourself,” and offers unparalleled protection. On embedded devices, ExProtector offers the additional option of using certificates to manage permissions and define once and for all “who can update what and where.” 

 

KEYnote 28 – Edition Fall 2014