1

I've been asked to improve the security of my company's iot device, and encrypt a storage partition. It's a general purpose arm based device, and currently can boot from a variety of sources (USB, network, sd card, etc).

The company wants to add a TPM chip to perform the partition encryption.

Am I right in thinking that a system lacking secure boot, that can boot whatever OS the user wants via network boot for example, could never be secure? I imagine the network booted OS could ask the TPM chip to decrypt the encrypted partition, showing that there's little actual security on this system.

Finally, if there's a uboot variant that uses a TPM chip to implement secure boot such as sboot, is that actually secure? I can't help but think that a system that allows any bootloader to run, would allow any security mechanism to be reverse engineered given enough time.

7
  • AFAIK secure boot is still secure as long as the first bootloader is secure - even if you can load alternative bootloaders, the TPM won't release its keys Commented Apr 8, 2022 at 11:41
  • No the TPM 2.0 chip (using a 2.0 enabled driver) wouldn't release the keys, but I imagine I could still decrypt the encrypted partition? If the key is randomised on each device, the key isn't hugely important.
    – Alex
    Commented Apr 8, 2022 at 12:39
  • 1
    How would you decrypt the partition without the encryption key??? Commented Apr 8, 2022 at 12:45
  • @Alex What you're saying doesn't make a whole lot of sense. You need the key in order to decrypt the data.
    – user163495
    Commented Apr 8, 2022 at 15:55
  • The key, which is stored in the TPM and isn't supposedly retrievable, is used by the TPM to decrypt the partition. I assume that if there's no method of securing the system communicating with the TPM, then a TPM can be instructed to do whatever is asked of it, including decrypting a partition. Looking into this further, the TPM chip should be setup to measure the boot process, to verify the system that it's communicating with hasn't been modified.
    – Alex
    Commented Apr 8, 2022 at 22:02

1 Answer 1

2

It's possible to do this pretty securely. The usual approach - used by Bitlocker and other TPM-capable volume encryption schemes - is to "seal" the volume encryption key using Platform Configuration Registers (PCRs). The encryption key (or a value used to derive it) is stored in (possibly generated in) the TPM with a policy that it can only be released if certain PCRs have their expected values. While the set of PCRs available varies somewhat, the general notion is the same in all cases: the PCRs contain a rolling hash of data that has been used by the system up to a given point in time. The first data fed into the PCRs is done during the "Core Root of Trust Measurement" or CRTM execution. The CRTM is generally non-writable code that "extends" some critical code - usually the device's low-level firmware (BIOS/UEFI on PCs and similar devices) - into one PCR, and that code's configuration data into another PCR. That code (low-level firmware) will then extend the next stage of code, such as a bootloader or minimal decryption utility, etc. into yet another PCR, and so on until you get to the main operating code. Code that has been extended into a PCR in this way is said to be "measured" by that PCR; any change to the code will result in a different value in the PCR.

Volume encryption enters this story when you generate the encryption key and store it in the TPM with a TPM policy that essentially says "the key shall only be available if the following set of PCRs have their current values". Generally, you want this to be either every PCR for the code up to the point where the decryption code would take over, or at least every PCR for the code up to the point where the measured code will itself validate cryptographic signatures on further sections, up to the decryption code. The key is thus available if - and only if - the boot process has not been tampered with. An attacker modifying the firmware, or bootloader, or decryption tool (or analogues in e.g. an embedded device without a full OS) - whether directly, or by booting from a different boot device / program - will mean the PCRs don't have the same value and render the decryption key unavailable.

Note that this process does not prevent booting an alternative system, nor does it inherently verify that the system is signed with a trusted key (although the measured code may perform such a verification, the PCRs don't know or care). Those functions are the providence of Secure Boot. Instead, this process simply ensures that the key is only released if the boot sequence, up to a certain point, is the same as it was when the key was sealed.


There are attacks against TPM-based volume encryption. First of all, you obviously need to prevent malicious code from executing once you're past the point where the decryption process unseals the key. On PCs and phones, this is the domain of the OS' security features; on an embedded device, maybe you just don't allow any method to run arbitrary code after that point is reached in the boot process. You also need to protect against direct memory access (DMA) by external systems (via e.g. Thunderbolt or PCI Express connectors, or debug interfaces on the board), either preventing DMA entirely or restricting it from reading the addresses where the decryption key lives (and from writing to any address, as that could be used to load arbitrary code that fetches and reveals the decryption key). These concerns are common across all volume encryption schemes and can't be directly prevented via Secure Boot or similar (though without Secure Boot, it might be possible to modify some non-encrypted data to take control of the system after the key is unsealed, bypassing the OS security controls).

There are also some cases where Secure Boot in connection with TPM-based encryption can directly provide more security for the encryption. For example, a "cold boot" attack is where you let the system boot normally, such that the volume encryption key is unsealed and stored in RAM to enable decrypting (and encrypting on writes) the encrypted volume. The device is then shut down and - before the RAM loses its charge - restarted with firmware that does not wipe the RAM on startup. The PCRs won't be the same, but that doesn't matter; the malicious firmware can read the plaintext key out of the RAM where it was preserved from the normal boot. This attack is a lot easier on devices that have discrete RAM, as that can be made extremely cold (using e.g. cryogenically cold liquids) to extend the powered-off lifetime of data in RAM into the minutes, and allow it to be pulled from one device and installed into another (which, if possible, totally sidesteps Secure Boot). An SoC is trickier to attack in this way, but not inherently impossible, as there's usually a way to glitch the board into restarting/loading code without wiping RAM even if that's not officially supported. However, using Secure Boot might prevent the malicious firmware from running, spoiling the cold boot attack even if the attacker can get the device to start booting without wiping or losing the decryption key from RAM.

1
  • AFAIK, the TPM can't make measurements itself; rather, the firmware and/or bootloader, etc. provide them to it. So, if Secure Boot is disabled, isn't it possible that a malicious bootloader give a measurement of the valid firmware to the TPM? Without Secure Boot, how can the TPM trust that the measurements haven't been tampered with and that they are indeed genuine? Commented Jun 12, 2023 at 23:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .