TPM2+PIN Encryption Schemes: Evaluating and Enhancing Security

TL;DR: Analyzing vulnerabilities in TPM2+PIN schemes and walking through an implementation for systemd-cryptenroll, ensuring a security profile that is no less robust than traditional password-based schemes.

Why TPM-based encryption?

Encrypted disks are usually protected with passwords or passphrases. Assuming a truly random password of sufficient length is used and stretched by the encryption software, using a memory-hard KDF like Argon2, chances of anyone successfully performing a brute-force attack are virtually hopeless under most circumstances. Unfortunately, humans are poor at generating randomness, and because passwords created by humans are never as clever as they seem, most passwords end up being weak.¹

A TPM protects encryption keys by sealing them against PCRs and an optional pre-boot PIN. The TPM measures the machine’s state and configuration (hardware, firmware, bootloader etc.), and will refuse to release the key if any changes are detected. For instance, an encrypted drive cannot be unlocked on another machine or via a disk image without the randomly generated recovery key, which is resistant to brute-force attacks. Given the known vulnerabilities of PCR-only authentication, a pre-boot PIN is strongly recommended, if not necessary.^{2 3 4}

As the name suggests, a pre-boot PIN (can be alphanumeric) requires user authentication before the boot process begins. This ensures that the TPM withholds sealed data unless the correct PIN is provided, making the previously mentioned exploits ineffective. Given that TPMs incorporate anti-hammering protections against brute-force and dictionary attacks, PINs or passwords that would usually be considered weak become strong. In combination with SecureBoot, a TPM prevents execution of unauthorized and unverified code in the bootchain.

Sounds good. What’s the problem?

No security measure is infallible. As mentioned above, vulnerabilities can compromise its security and relying solely on a TPM for trust might be a bad idea.

Trust, vulnerabilities and different types of TPMs

Various manufacturers like STM, Infineon, Intel, and AMD, produce different types of TPMs.⁵ The most common ones are Discrete (dTPM) and Firmware (fTPM). Because most of these implementations are proprietary, there’s always the risk of potential backdoors or sloppy implmementations.⁶

Whether dTPMs or fTPMs are more secure is debated. The entire silicon layout of a dTPM it designed around anti-tampering. They are covered with active meshes and equipped with optical sensors, glitching detectors, voltage monitors and noise generators to defend against various physical attacks. In 2010, Christopher Tarnovsky successfully attacked⁷ discrete TPMs (ver. 1.2). That said, such attacks are costly and not easy at all, rather falling into the category of nation-state level attacks. dTPMs have the disadvantage of communicating with the CPU over a bus, which allows sniffing attacks. Although in the case of a properly configured setup, this is irrelevant, since a pre-boot PIN mitigates this issue.⁸

In contrast, the FaulTPM attack compromised AMD’s fTPM using off-the-shelf voltage-glichting hardware attached to motherboard power rails.⁹ No silicon probing or anything of that sort was required.

For systemd-cryptenroll, this attack is fatal because the actual random secret used to encrypt the LUKS-keyslot is sealed directly. With no brute forcing required, these configurations are likely less costly to attack than a purely password based configuration.

Microsoft’s Bitlocker takes a different approach by sealing an encrypted version of the VMK (Volume Master Key) instead. Here, SHA-256(PIN) serves as the TPM’s authValue, while the VMK is encrypted using a key derived from 2^20 iterations of SHA-256(PIN + SALT). While this approach is more robust than that of systemd-cryptenroll, it has two significant shortcomings:

1. Bitlocker limits PINs to 20 characters and doesn’t utilize a memory-hard KDF for stretching. A 20 character limit is sufficient for truly random alphanumerical passwords, but is rather poor for passphrases.
2. As already mentioned, TPMs are not infallible. Using SHA-256(PIN) as the authValue while simultaneously using 2^20 x SHA-256(PIN + SALT) to encrypt the VMK significantly weakens security. If a backdoor or flaw in the TPM were to leak authValue, the KDF would be effectively bypassed, leaving only a single iteration of SHA-256 for protection. This would make a brute-force attack possible, unless the user had chosen a truly random and complex password that pushes BitLocker’s 20-character limit.

Fixing the issue

The main issue remains that TPM based encryption has not consistently improved security, sometimes even compromising it compared to the conventional password-based approach. The goal should be to ensure that TPM2+PIN mode is at least as secure as a password-based scheme in any worst-case scenario.

This can be achieved by making the TPM a second factor rather than a potential single point of failure:

Should the TPM be compromised in any way, an attacker still needs to derive Slice1 using Argon2id and combine it with the comromised secret, ensuring this mode is no less secure than a purely password-based scheme in a worst case scenario.

Argon2 parameters are fully customizable, combining the advantages of TPM and password-based security. While cryptsetup restricts pbkdf-memory to 4GiB and pbkdf-threads to 4, systemd-cryptenroll sets no limits in regards to KDF parameters, other than the constraints of the hardware it’s running on:

--tpm2-argon2id-memory=
--tpm2-argon2id-iterations=
--tpm2-argon2id-parallelism=
--tpm2-argon2id-iter-time=

This implementation has been merged into systemd and is available in v262-rc1.