Advantage of TPM for disk encryption?
I'm currently studying TPM (Trusted Platform Module) functionality and use cases. I found a guide how to set up full disk encryption via LUKS (Linux Unified Key Setup) and Cryptsetup, using a TPM for key storage. Specifically, the encryption key for the disk will be stored securely and shielded in the non-volatile memory (NV-RAM) of the TPM. Access to the NV-RAM is protected by a passphrase.
When the system is powered on, the user must supply the correct passphrase in order to "unlock" the TPM and get access to the stored encryption key. The encryption key is then used to access/decrypt the disk. This means that without the correct passphrase, an attacker can not "unlock" the TPM to access the stored encryption key, and therefore the attacker can not access/decrypt the disk. Also, the TPM prevents "brute-force" attacks by limiting the number of unlock attempts that are allowed within a certain amount of time.
But: What is the real advantage of this TPM-based approach, compared to using a KDF (key-derivation function), such as PBKDF2 or, even better, Argon2? With the KDF function we can derive a pseudo-random key from the user-supplied passphrase and a high-entropy salt value. This means that the "correct" encryption key can only be computed when the proper passphrase is known. Also, "brute-force" attacks are prevented by making the KDF (e.g. Argon2) require a lot of CPU time and/or use a whole lot of RAM – if you do know the correct passphrase this is not a problem, since you only need to compute the KDF once, but brute-forcing becomes impractical...
Essentially, both approaches make sure that access to (decryption of) the disk will only be possible when the correct passphrase is known. Furthermore, both approaches effectively prevent brute-force attacks. Why would you favor the TPM-based method then?
When the system is powered on, the user must supply the correct passphrase in order to "unlock" the TPM and get access to the stored encryption key. The encryption key is then used to access/decrypt the disk. This means that without the correct passphrase, an attacker can not "unlock" the TPM to access the stored encryption key, and therefore the attacker can not access/decrypt the disk. Also, the TPM prevents "brute-force" attacks by limiting the number of unlock attempts that are allowed within a certain amount of time.
But: What is the real advantage of this TPM-based approach, compared to using a KDF (key-derivation function), such as PBKDF2 or, even better, Argon2? With the KDF function we can derive a pseudo-random key from the user-supplied passphrase and a high-entropy salt value. This means that the "correct" encryption key can only be computed when the proper passphrase is known. Also, "brute-force" attacks are prevented by making the KDF (e.g. Argon2) require a lot of CPU time and/or use a whole lot of RAM – if you do know the correct passphrase this is not a problem, since you only need to compute the KDF once, but brute-forcing becomes impractical...
Essentially, both approaches make sure that access to (decryption of) the disk will only be possible when the correct passphrase is known. Furthermore, both approaches effectively prevent brute-force attacks. Why would you favor the TPM-based method then?
Last edited on
None, it offers no advantage.
Cryptographic hardware modules are useful when they can be physically decoupled from they thing they unlock, or when they require the presence of a decouplable physical key. For example, if your phone has a security module that unlocks with your fingertip (and only your fingertip), or if you can only boot your computer by connecting a USB dongle that has to be plugged in the entire time because it's performing all encryption operations and the encryption key never leaves its internal memory. This adds security because an attacker can't just brute-force your password. They also need to steal your security device.
The fact that the decryption key never leaves the device is also important, because it frustrates forensics attempts to exfiltrate the key for hot memory. If you take the device with you you also take the key with you.
If the device is just plugged in all the time and unlocking the computer involves copying the key from the device's memory to the host's memory then you may as well just keep the key encrypted on disk. The device adds no security.
Cryptographic hardware modules are useful when they can be physically decoupled from they thing they unlock, or when they require the presence of a decouplable physical key. For example, if your phone has a security module that unlocks with your fingertip (and only your fingertip), or if you can only boot your computer by connecting a USB dongle that has to be plugged in the entire time because it's performing all encryption operations and the encryption key never leaves its internal memory. This adds security because an attacker can't just brute-force your password. They also need to steal your security device.
The fact that the decryption key never leaves the device is also important, because it frustrates forensics attempts to exfiltrate the key for hot memory. If you take the device with you you also take the key with you.
If the device is just plugged in all the time and unlocking the computer involves copying the key from the device's memory to the host's memory then you may as well just keep the key encrypted on disk. The device adds no security.
Last edited on
| If the device is just plugged in all the time and unlocking the computer involves copying the key from the device's memory to the host's memory then you may as well just keep the key encrypted on disk. The device adds no security. |
Well, the TPM is soldered on the mainboard, or even built into the CPU. So, yeah, we can say that it is "plugged in all the time" – though it will not allow access to certain objects (e.g. keys), unless proper authorization was provided. In theory, all crypto operations could be done inside the TPM, so that the key never needs to leave the TPM. But, for the use case of disk encryption, this would be way too slow, I suppose. That's probably why they read the encryption key from the TPM's NV-RAM into the "normal" RAM, once it has been unlocked.
The only situation I can see where storing the key in the TPM provides a real advantage is when the attacker steals your hard-disk, but not the whole machine with the TPM. In that case, the attacker really has no way to get the encryption key from the TPM. Still, the attacker could do a "brute-force" attack on the encryption key. But, if we assume that the encryption key in the TPM is ~256 bit in size and was generated totally random (not derived from a passphrase), chances for successfully brute-forcing the key is practically zero.
On the other hand, if we simply used a KDF to derive the key from the user's passphrase, then the chance for successfully brute-forcing the passphrase/key should also be pretty close to zero – provided that the used KDF is sufficiently slow (e.g. Argon2 with proper settings).
Last edited on
| Well, the TPM is soldered on the mainboard, or even built into the CPU. |
| If the component that the TPM is hard-wired onto dies you'll lose your data. |
Not necessarily. I think there are ways around it:
1. The TPM may export the key. In this case, the "sensitive" data of the key will be encrypted and integrity-protected when it leaves the TPM – in such a way that it can only ever be re-imported into another secure TPM. This can be used as a "backup".
2. LUKS/Cryptsetup can set up multiple key slots, each of which can be used to "unlock" the disk. One may be a key that is stored in the TPM, for every day use. A secondary "backup" key may be added, which you print on a sheet of paper and put into your safe.
Of course this requires preparation. No backup, no mercy 😅
Last edited on
You may be interested in this:
https://news.ycombinator.com/item?id=37435450
TPM implementation itself isn't necessarily secure -- it's general purpose hardware. The integrator is required to define the threat model and design their product around it. As a result I think OEMs are just sticking the TPM chip into their mainboards and trusting that the software implementation (in other words -- the UEFI and OS) will be secure enough... But as we all know, there are probably ways around that.
https://news.ycombinator.com/item?id=37435450
TPM implementation itself isn't necessarily secure -- it's general purpose hardware. The integrator is required to define the threat model and design their product around it. As a result I think OEMs are just sticking the TPM chip into their mainboards and trusting that the software implementation (in other words -- the UEFI and OS) will be secure enough... But as we all know, there are probably ways around that.
Last edited on
Topic archived. No new replies allowed.