PROTECTION
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 com-
pletely 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
12
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 cryp-
tographic 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.