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
- 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
How it Works
Design
Build
Deploy
