Here's a passage from Wikipedia on BitLocker

Once a BitLocker-protected machine is running, its keys are stored in memory where they may be susceptible to attack by a process that is able to access physical memory, for example, through a 1394 DMA channel. Any cryptographic material in memory is at risk from this attack, which therefore, is not specific to BitLocker.

It is my understanding that Trusted Platform Modules (TPMs), which BitLocker is allegedly using are made to specifically protect against such attacks:

... a key would still be vulnerable while a software application that has obtained it from the TPM is using it to perform encryption/decryption operations, as has been illustrated in the case of a cold boot attack. This problem is eliminated if key(s) used in the TPM are not accessible on a bus or to external programs and all encryption/decryption is done in the TPM

TPM diagram implies that key storage and encryption/decryption engine should be part of module. So, why is there no full disk encryption product, which uses this feature? E.g.: why is there no FDE software, not vulnerable to cold boot attacks?


TPM diagram implies that key storage and encryption/decryption engine should be part of module. So, why is there no full disk encryption product, which uses this feature? E.g.: why is there no FDE software, not vulnerable to cold boot attacks?

If you want your key not to be present outside the TPM, your TPM would have to do all the encryption. That's not feasible because the TPM lacks the following:

  1. symmetric encryption

    The TPM itself can't perform a symmetric encryption like AES on external provided data.

  2. performance

    Even if it would be capable of the encryption, the chip's performance wouldn't meet requirements for a FDE. A TPM is designed to be very very lowcost. Performance is no design goal.

  3. bandwith

    A TPM in a PC system is connected via LPC Bus which can transfer 6.67 MB/s at most. (no full duplex either)

So the TPM is not designed to perform FDE.

The solution is to let the HDD itself do the encryption. If you want to go that way, you should look into the TCG's data storage working group. Their solution is based on Self Encrypting Drives (SED) which store their keys in the TPM. Therefor the key should never be visible in the system's RAM and only for a short time on the system's bus.

So there is a solution for FDE, but it requires special hardware (= the SEDs).

  • Would that still not leave the system vulnerable to sniffing along the bus, whether PCI or USB (if external)? The decryption key needs to travel along that path to the drive, and the data always will travel back - and be in PC memory - in the clear. – deitch Feb 17 '16 at 14:06
  • @deitch yes, but that's a different attack. If you want to defend against someone who is able to sniff your PCIe bus - good luck with that. – Scolytus Feb 17 '16 at 17:23
  • got it. In other words, if I want to defend against attacking the unencrypted data (not the key), then I need to protect the physical bus. – deitch Feb 17 '16 at 17:54
  • But, then, what is the value of having the drives' keys never be visible in RAM? After all, the unencrypted data will be there. – deitch Feb 17 '16 at 17:55
  • Oh, yeah (sorry for multiple comments). I have seen lots of SEDs; do you know of any that natively store their keys in TPM? – deitch Feb 17 '16 at 17:55

From the Wikipedia article on TPM, the TPM specification details "a secure cryptoprocessor that can store cryptographic keys that protect information" - in other words, a generalized piece of hardware that performs cryptographic operations for the user.

TPM is generalized to be accessible from within the OS and subsequent software, and thus is inherently limited in security due to it's design - programs must run from somewhere, and thus must be loaded into RAM. Several other programs use the TPM module for authentication purposes (e.g. some corporate security networks) or to prevent unauthorized computers from accessing a particular network.

This is not limited to BitLocker, and other solutions using the TPM must also be careful to mitigate the risks of cold-boot/RAM-copy attacks.

In theory, it would be possible to have a hard disk which is self-encrypting in a similar way to a self-enclosed TPM module. This poses a very severe limitation, however: the end user can't know the decryption key (otherwise, a virus or other piece of software could also determine it), - thus it would be impossible to recover the data if required, as you have no way of obtaining the key to decrypt it.

This paper illustrating cold-boot attacks on almost all full-disk encryption schemes may be of use:

In its default “basic mode,” BitLocker protects the disk’s master key solely with the Trusted Platform Module (TPM) found on many modern PCs. This configuration [...] is particularly vulnerable to our attack, because the disk encryption keys can be extracted with our attacks even if the computer is powered off for a long time. When the machine boots, the keys will be loaded into RAM automatically (before the login screen) without the entry of any secrets.

It appears that Microsoft is aware [...] and recommends configuring BitLocker in “advanced mode,” where it protects the disk key using the TPM along with a password or a key on a removable USB device. However, even with these measures, BitLocker is vulnerable if an attacker gets to the system while the screen is locked or the computer is asleep (though not if it is hibernating or powered off).

protected by Breakthrough Jun 27 '13 at 12:59

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.