CodeMeter Embedded meets TPM

Why not let CodeMeter Embedded work with a TPM (Trusted Platform Module)? Some embedded or IoT devices already come with a TPM or similar secure element on board. Why not use it like a CodeMeter ASIC for secure key storage? The components are often mass-produced and inexpensive, and point-of-sale hardware often have them built right in.

Simple answer: Yes, CodeMeter Embedded does that. But no TPM will ever rival the sheer power of a CodeMeter ASIC. The CodeMeter hardware built into our dongles and ASICs is not only highly powerful, its storage structure and firmware have also been optimized to work perfectly with CodeMeter. TPMs and other secure elements were designed with a completely different purpose in mind: To offer one or more cost effective and convenient secure anchors for e.g. secure boot or other low-level system processes. Any CodeMeter chip will beat them hands-down with the size of the secure memory alone – not to mention the many other capabilities like the Code Moving feature.

There is one challenge: The embedded landscape is as diverse and heterogeneous as they come. There are untold numbers of systems, each unique in its performance, application, and, not least, operating costs. The highly secure memory of a CodeMeter ASIC is overkill for some applications. This is where CmActLicense comes into play. It stores the data in a structure that is compatible with the dongle model, but it does so in a special license file. To make this almost as secure as a physical dongle, it needs to be bound to certain properties of the system it is on. Without a firm anchoring to the system, the file could be copied and would work on other systems as well, circumventing the entire licensing system. CmActLicense achieves this with custom binding: The license is bound to a custom selection of the embedded system’s properties, like its CPU ID, MAC, GPU ID, IMEI or similar unique identifier. The more specific attributes are used, the more tightly the license is bound to the system. One needs to know the properties of the target hardware in its most minute details, so the binding system needs to be fine-tuned by each developer using it. This is where integrating a TPM can come in handy: In the best and simplest case, the TPM’s endorsement key will already suffice as a unique trait for binding the CmActLicense. It is the best of both worlds: The CmActLicense provides the secure storage structure, and the TPM (or similar secure element) provides the secure anchor by guaranteeing a unique, cryptographically proven identity.

A TPM can also be used to put in place a binding setup that works on more than one system without having to be adjusted for each specific hardware in the mix. To do so, the process would not simply verify the identity of the system, but initiate a specialized cryptographic process, called platform attestation. This checks the authenticity of the key and makes sure that the CodeMeter Embedded process in the secure software indeed communicates directly with the TPM and has not exposed itself to a man-in-the-middle attack. This binding setup can also replace other platform-specific binding to the hardware in question, as the same cryptographic process serves to verify the identity of the hardware system.

This combination has CmActLicense working as a secure place to store keys and certificates. The resulting ‘soft safe’ is locked with a key that is kept in the TPM – i.e. secure hardware. CmActLicenses working with TPMs are a good and versatile option if no dongle or ASIC can be used, but hardware-based key storage needs to be guaranteed.

 

KEYnote 37 – Edition Spring 2019