Software Eats the TPM

A recent report outlining the threats to the automobile industry once again raised the issue of just how vulnerable embedded devices are. While the article focused on automobiles, the threats laid out apply to any connected device. Popular network-centric approaches, such as segmentation and firewalls, may provide adequate protection for IT assets; however, they are woefully inadequate for embedded devices. Smart customers concerned about security are finally beginning to acknowledge and take steps towards addressing this issue.

Security vendors use a term—“Defense in Depth”—to articulate a principle that protecting a system requires layers of security; thereby, increasing the degree of difficulty for an attacker. Embedded systems have long lagged in implementing this approach. To be fair, the problem was not as severe it is now, and of course, device makers tend to do the absolute minimum required.  Today, the bar for absolute minimum has been raised given the increasing frequency and varied nature of attacks on embedded systems.

Understanding a Root of Trust

A critical component of defense in depth is the “root of trust” (RoT). According to Arm, this is defined as the “foundational security component of a connected device. While precise definitions can vary considerably, a RoT can be described as a set of implicitly trusted functions that the rest of the system or device can use to ensure security; it is the foundation on which a device maker can build their ‘tower of trust’”  The concept of a root of trust is fairly well understood, but less so are the challenges of implementing one. Implementing a root of trust isn’t an independent action. It requires thinking of the entire system from device boot-up to how the root of trust will be used during daily operation.

A Trusted Platform Module—or TPM—chip is one of the most popular forms of trusted hardware. While the TPM itself isn’t a root of trust, it is integral to functioning as a system for authenticating devices, performing boot measurements, and securely storing data. It also functions as a unique global ID for its device. It has become synonymous with being a RoT. There are, however, several challenges with implementing hardware TPM’s:

  • It requires implementing a separate piece of hardware, making it subject to the vagaries of the supply chain.
  • TPMs have to be provisioned, a separate process that only the TPM manufacturer can perform. 
  • TPMs are optimized for cost rather than performance, meaning that the hardware is not a high performance component. Certain operations, such as signing and verification, can take longer (source: fTPM: A Firmware-based TPM 2.0 Implementation – Microsoft Research).

Finally, implementing TPMs for resource and space constrained embedded systems may be difficult, if not impossible.

Firmware FTM

Firmware TPMs implemented on Arm-based silicon takes advantage of Arm TrustZone to implement a firmware version of the hardware TPM while remaining fully compliant with the TPM 2.0 specification. TrustZone is an on-chip, hardware enforced, domain separation capability that enables carving off memory into secure regions, and functions that can only be called when the device is in a secure state. The advantages of the firmware TPM (fTPM) are: 
  • Unique device ID – persistent and cannot be cloned 
  • Secure key and certificate storage
  • Performance and boot measurements for boot integrity checks

Sequitur’s EmPOWER™ fTPM Provisioning and Management Service

Similar to a discrete TPM, a firmware fTPM needs to be verified that it is authentic and has quality code. Sequitur EmPOWER™ Root of Trust Provisioning Service creates a known, safe image independent of device maker, manufacturer, and cloud provider. The key characteristics of the service include:

  • Similar to a discrete TPM, a firmware fTPM needs to be verified that it is authentic and has quality code. Sequitur EmPOWER™ Root of Trust Provisioning Service creates a known, safe image independent of device maker, manufacturer, and cloud provider. The key characteristics of the service include:
    • TCP 2.0 Compliant Firmware TPM
    • Secure, HW isolated implementation
  • Enables 3rd party attestation required for Azure
  • Simplifies RoT provisioning, eliminates hardware
  • fTPM is updatable, secure update process
  • Streamlined provisioning process with unit volume control
The service will initially support the NVIDIA Jetson™ Orin and be recognized and attested to Microsoft Azure.

How it Works

The service provides a systematic process for provisioning the root of trust. This requires close cooperation with the ODM, as the ODM must supply their bespoke components to complete the provisioning process. This can be envisioned in three steps:
In the design phase, the ODM takes advantage of Microsoft’s Device Development Kit (DDK) for Azure Edge AI and implements the NVIDIA Jetpack™, which provides the tools and firmware for Jetson™ Orin. In addition, Sequitur’s Root-of-Trust (RoT) Provisioning Kit provides the components needed for the fTPM and provisioning, including the trusted OS (CoreTEE™, firmware TPM, ATF, etc). The device vendor then selects other components needed for the device (for example, Linux Kernel). A device maker using these components then develops a product based on Jetson™ Orin hardware.
In the build phase, the ODM, using the Sequitur Labs RoT Provisioning Service, provides a set of components, including EUFI and BCT, to Sequitur’s EmPOWER™ site. Sequitur creates a signed, encrypted boot image and supporting device-specific key files (called blobs) back to the device maker. These images are then used in manufacturing to provide a unique boot image and provisioned fTPM onto each device, uniquely.
Now, the device is ready to register securely with Azure Edge AI cloud services.
EmPOWER fTPM Service schematic
Root-of-Trust Provisioning Overview


Using an fTPM, instead of a discrete hardware TPM, delivers many benefits to device makers and their customers. Aside from the obvious cost and supply chain benefits of not having to implement hardware, the ability to easily update the fTPM in case of security failures, significantly improves device resilience. Note that the fTPM is fully compliant with the TPM 2.0 specification, so customers have the same assurance as that of a hardware TPM. Finally, the Sequitur service seamlessly integrates into a device maker’s build process.

Comments are closed.