Trusted Platform Modules: 8 Surprises for IoT Security

By Ari Singer, CTO, TrustiPhi

Part 1 of a two-part TPM Surprise Series

Built into billions of devices, a Trusted Platform Module (TPM) is usually a specialized chip on an endpoint’s motherboard that stores cryptographic keys on behalf of its host system for authentication and protection of the endpoint. Each TPM chip contains one or more unique key pairs, certified by the vendor, called endorsement keys (EKs), for validating the TPM’s authenticity. A TPM can also store platform “measurements” that identify software and firmware running on the platform. To stop the TPM from protecting the system, a hacker would have to interfere with it physically. In addition to their popularity on the PC and network side, TPMs will be architected into billions of Internet of Things devices.

Surprise 1: TPMs are passive, not active devices. They do not control anything on the host system they are embedded on.

A widespread misconception is that a trusted platform module somehow controls the system it’s a part of, but a TPM is 100 percent passive with respect to the rest of the system.

The trusted platform module is a self-contained component that has its own storage and processing capabilities, which it uses for protected operations on internal resources such as keys and measurements. These resources, however, are data that are given to the TPM, or that it is asked to generate.

Typically, boot code uses the TPM to store measurements of software running on the system, and applications use the TPM to protect the application’s keys and report measurements. These activities are all externally driven, not initiated by the TPM.

Surprise 2: A TPM is only useful when other things in the device take advantage of it.

The TPM is part of a broader security ecosystem that includes everything from the BIOS to motherboards to account passwords. To obtain value from the TPM, system designers must create systems that rely on the TPM’s internal resources. In traditional TPM implementations, software is “measured” before it is run in order to identify rogue software. The measurements are stored in the TPM, giving it second-hand awareness of “bad” software. The TPM will protect keys it holds, refusing access to rogue software that does not meet the expected measurements. For example, for solutions like Microsoft Bitlocker, an attacker booting to the wrong OS could not decrypt data on the hard drive. Similarly, a TPM might not allow a key to be used to authenticate a device to a bank, preventing an attacker from unauthorized account access.

With proper integration, a TPM can support the security of billions of future IoT devices that would otherwise be difficult to protect. By creating system dependencies on a TPM for devices like automotive electronic control units (ECU), system designers can make it much more difficult to swap out a system component without detection.

Surprise 3: A TPM doesn’t help much — if at all — with the heralded secure boot.

Secure boot is a hot topic. Upon startup, a device should run only the authorized code, not rogue software planted by a malicious actor. However, TPMs don’t provide secure boot. This occurs before the TPM comes into play. When a system powers on, early boot code (such as a UEFI BIOS) must decide which software will run next and which measurements are sent to the TPM. After the secure boot decisions are made, then the TPM can be used. The currently-running software can use the TPM to authenticate or decrypt the next piece of software before it loads, but this does not protect a system if an attacker can get at the early boot code.

The TPM can support a well-designed boot process (including “measured boot” or “trusted boot,” which we will discuss later), but the TPM has no impact on a secure boot.

Surprise 4: TPM has not been particularly successful considering how long it’s been available.

TPM has withstood significant scrutiny and is well established in the security community. Given TPM’s favorable reputation, its longevity (more than 20 years and counting) and the fact that TPMs have shipped in volume in PCs since 2005, it’s surprising how few people really know how to work with them. As a result — especially in the IoT realm — TPMs are not being tapped to their full potential. TPMs became a ubiquitous checkoff item on RFPs for PC-related projects and appear in billions of devices today, but most devices use TPMs minimally, or not at all.

The good news: TPM 2.0 is more flexible than the original TPM specification, allowing the newest TPMs to be applied to many embedded applications, including industrial sensors and smart home devices. Example: There is a TPM 2.0 profile for using TPM on limited-functionality ECUs for automotive applications. Now, designers and developers can more easily select granular TPM functions, whether for vehicles or a valve controller at a water utility.

Surprise 5: Leveraging TPMs is exceedingly difficult. They were not designed to be user-friendly… and they’re not.

It took the top companies in the PC industry — Compaq, HP, IBM, Intel, Microsoft and others — years to build the ecosystem needed to make implementation of TPMs for PCs feasible. These companies carved out the TPM space, driving updates to hardware, firmware and software and defining new protocols. The expectation (or at least hope) was that with this infrastructure, TPM would become an effective enabler, acting like an interstate highway for security. That is, they would provide a smooth, straight, easy way to get to the destination. Unfortunately, TPM turned out to be so complicated that even with this rich ecosystem, almost nobody built solutions to leverage it.

Surprise 6: TPMs aren’t cheap.

Keep in mind, TPMs are hardware. Then, remember they’re not just hardware. Implementing a TPM solution also entails software, the device’s physical design, re-architecture of the system and modifications to integrate with the broader infrastructure. Adding a TPM could increase the cost of a device by fifty cents or more. For many embedded applications, that added cost is a dealbreaker. For devices already being re-architected or that have high security requirements, like those used to operate and secure industrial sites or critical infrastructure, the incremental cost is more likely to be justifiable.

Surprise 7: If a TPM is only used as a secure repository for encryption keys, money is probably being wasted.

Despite having a range of capabilities, TPMs are often used solely to protect symmetric or asymmetric keys, but simpler hardware or software-based designs can often do that job just as well as a TPM. If your platform already has a TPM, by all means, use it for key protection, but if you have a TPM, why not take advantage of the TPM’s more powerful features such as measurement-based access control and remote attestation?

Surprise 8: To retrofit an existing system, a hardware TPM is a non-starter.

Forget about it. Here’s why: the TPM must be architected into the overall system from the beginning. It’s not a last-minute add-on to plug in once a device has been produced. It’s hardware, and the platform must physically accommodate it. Moreover, the TPM must be fully integrated into the boot process and security functions of the platform.

Firmware or software-based TPMs offer alternatives. They are typically less secure than hardware-based TPM, but they can more easily be integrated into your design.

Takeaway

Making a TPM a requirement for your system will not magically cure your security problems and the integration and implementation is (much) easier said than done, but don’t take that as a negative verdict. The TPM has already shown tremendous utility in system security, particularly for PCs — and it has great potential for the IoT market. Taking full advantage of TPM means going into depth. In Part Two of this series, we’ll drill into more TPM surprises, specifically their role in the Internet of Things and when they might be right for you.

Ari Singer, CTO at TrustiPhi and long-time security architect, is a former chair of both the Trusted Computing Group’s TPM work group and the TPM Software Stack (TSS) working group. He was a key contributor to the TPM 1.2 and 2.0 specifications, and has led teams that developed multiple TSS and TPM firmware implementations and TPM-enabled applications. With 16 years in trusted computing, Singer was an influencer in other security standards including EESS, IETF, IEEE 802.15.3 and IEEE 802.15.4. He was also chair of the IEEE P1363 working group.