This past week I’ve been reading the specifications for Trusted Platform Modules (TPM) published by the Trusted Computing Group of companies. It seems to me they’ve done a lot of things right, but a TPM is not a complete security solution on its own.
If you’re not familiar with the technology, a hardware TPM is either a discrete chip or separate logic inside an SOC which implements cryptographic ciphers and provides strong protection of cryptographic secrets. With a TPM you can create and use keys without ever exposing them in memory where a hacker might read them. The specification also defines some smart features for recording system state in a tamper-resistant way. For example, you could use these features to implement remote attestation where software version numbers, configuration, or other state data could be recorded in the TPM and sent to a remote server for validation. Some BIOSes or UEFIs also use this feature for attestation of the system as it boots.
Cryptographic keys and ciphers are naturally important to IoT. Every IoT device will need to connect to a server at some point and it will need to identify itself and establish trust. Obviously, you’ll want to prevent unauthorized entities from reading the messages between your device and your server and from sending fake messages of their own. You want to be sure the cryptographic secrets you use to protect your data stay secret. The limitations with TPMs is that while they might prevent an attacker from extracting those secret keys, they don’t, in themselves, prevent an attacker from using those secret keys.
By way of illustration, consider what would happen if you lured me away from my laptop after I’ve logged in. Nothing would prevent you from reading my email or sending email that appears to come from me. Even though I’m using disk encryption on my laptop, there would be nothing preventing you from reading or deleting my files. After the initial authorization phase (the login) my laptop doesn’t continually check that the person at the keyboard is still me. Without ever learning my password, you could impersonate me and mess with my data.
This is similar to the limitations of TPMs. They may make it very difficult to extract cryptographic secrets, but if hackers can insert their own code on your device, they can use the secrets in the TPM to send fake messages and access secret data. Even if your system uses TPM attestation features to enforce a trusted boot, once the boot is complete the TPM is like my unlocked laptop: open for anyone to use. We know that hackers are clever at finding ways to run code on your devices. They can exploit weaknesses in the OS, in the protocol stacks or in your program itself. They’re certainly not above locating a few traces on a PCB to attach a debugger. Once attackers get code on your device, they own your secrets even if they can’t read them.
This is the reason we promote a “defense in depth” strategy at Irdeto. Strong encryption-key security needs to be combined with protections against reverse engineering: things like code transformations, ongoing integrity attestation, and continuous tamper detection. Because unfortunately, security is not as simple as buying a single chip.