27
$\begingroup$

If understand correctly from this post and the Wikipedia page for BitLocker and TPM, by default, BitLocker uses symmetric cryptography like AES. However, TPM is capable of performing RSA encryption. Given that the RSA key is stored in the TPM, why does BitLocker not use asymmetric encryption (i.e., RSA)? By using such an encryption technique, we might be able to defend against the cold boot attack or sniffing on the LPC bus.

$\endgroup$

migrated from security.stackexchange.com Apr 23 at 22:23

This question came from our site for information security professionals.

  • 17
    $\begingroup$ How would using asymmetric encryption even help? Unless you never intend to write any data to the disk, you would need to have both sides of the key in memory in order to use the disk anyway. (I suppose there are special cases where you'd want a disk anyone can read but with strong authentication of its content -- but even there encrypting each block separately with an asymmetric primitive would not be the solution of choice). $\endgroup$ – Henning Makholm Apr 21 at 9:30
  • 1
    $\begingroup$ BTW, you might be interested to know that there are ways to mitigate cold boot attacks against FDE, such as TRESOR or using a new CPU with TME (Total Memory Encryption). Neither of those require a TPM. $\endgroup$ – forest Apr 23 at 8:40
  • $\begingroup$ @forest, there is an attack on TRESOR, TRESOR Hunt $\endgroup$ – kelalaka Apr 23 at 10:08
  • 1
    $\begingroup$ @kelalaka I've always found that paper a bit silly. It's a DMA attack, which naturally needs to be mitigated separately (with a properly-configured IOMMU). It isn't specific to TRESOR at all. It's no more an "attack on TRESOR" than using JTAG to debug the CPU and extract the keys is an "attack on TRESOR". Same with attaching a logic probe to the DRAM modules and triggering an NMI and reading the registers as they are pushed to the stack. Or a browser 0day combined with a kernel exploit to read the keys. Anyway, just boot with intel_iommu=on and you should be safe from that particular attack. $\endgroup$ – forest Apr 23 at 10:13
52
$\begingroup$

Asymmetric encryption is vastly inferior to symmetric encryption. That is, in all respects, except one -- being asymmetric. When that property is needed, there's no way around it, obviously.

Asymmetric encryption is much slower. It is much more susceptible to showing recognizable patterns of some kind given non-random input. You need much larger key sizes to provide an adequate level of protection, and the system is much more vulnerable in general with current and future technology (reasonably-sized quantum computers will basically mean instant death for RSA, but AES is pretty much "yeah, so what" in that respect).

That's the reason why asymmetric encryption is almost never used to encrypt bulk data.

Nothing prevents you from encrypting a terabyte of data with RSA using 2048 bit chunks, much like you encrypt a terabyte with AES in 128 bit chunks. Only just, it doesn't make sense to do that because it is several thousand times slower, and at the same time is much more insecure.

$\endgroup$
  • 19
    $\begingroup$ @kelalaka For communication. $\endgroup$ – wizzwizz4 Apr 21 at 20:09
  • 2
    $\begingroup$ There is something preventing you from safely encrypting bulk data with RSA, though -- RSA is vulnerable to a number of different attacks involving plaintexts with known, unusual values (for example, small values of m). $\endgroup$ – duskwuff Apr 23 at 3:22
  • 3
    $\begingroup$ @kelalaka Asymmetric cryptography is almost exclusively used to exchange key information for symmetric cryptography. As Damon says, you still use symmetric algorithms for encrypting bulk data. $\endgroup$ – Luaan Apr 23 at 4:57
  • 2
    $\begingroup$ RSA is not more susceptible to showing recognizable patterns given a non-random input, unless you are very specifically using the horribly insecure textbook RSA. If you use RSA with proper padding (such as OAEP), it provides IND-CCA2 security. The real reason it would be a bad idea to encrypt something using just RSA is because it would be stupid slow and because the message would expand during encryption. $\endgroup$ – forest Apr 23 at 7:05
  • 6
    $\begingroup$ This answer is clearly wrong with regards to the susceptible to showing recognizable patterns based on the input, and it misses out on the fact that RSA encryption would expand the ciphertext and can therefore not be used for block encryption (even for textbook RSA, as the modulus size needs to be bigger than the block size). $\endgroup$ – Maarten Bodewes Apr 23 at 10:22
14
$\begingroup$

The cold boot attack can be performed on any encryption scheme as long as the keys reside in memory. For full-disk encryption (FDE) with symmetric algorithms like AES, you will need to take the key out from the TPM, where you will be susceptible to a cold boot attack.

Though the TPM is capable of RSA encryption and decryption, for FDE RSA has problems, in short the speed:

  1. RSA must use the OAEP scheme to be secure which reduces the message size.
  2. To speed up public key encryption the public key is selected as 3, 5, ... However, the decryption to access one block will be much slower even if you use CRT to gain 4x speed.
  3. Even though the TPM can perform RSA encryption on the chip, it will be much slower for Full Disk Encryption (FDE).

Therefore, TPM-based FDEs use TPM for key storage.

$\endgroup$
  • $\begingroup$ This is the correct answer, and the only one which does not perpetuate the myth that a TPM device itself performs disk encryption or that it somehow mitigates cold boot attacks. $\endgroup$ – forest Apr 23 at 7:19
9
$\begingroup$

TPMs do not perform the actual encryption used for full disk encryption. All they do is encrypt the key while the system is powered off or in a suspended state. The key is decrypted and passed once to the operating system over the LPC bus, which then keeps it in memory while encryption is performed. The reason a TPM would be a poor choice for securely accelerating full disk encryption is threefold:

  1. The TPM communicates over the extremely slow LPC bus (4 bit width at 33 MHz).

  2. The TPM hardware is generally very slow, being designed for security, not speed.

  3. TPMs are not general-purpose encryption coprocessors that take arbitrary keys.

If you really wanted to use it to perform the actual encryption in a way that would mitigate cold boot attacks, you would need to pass the plaintext (or ciphertext) from the disk to the TPM over the LPC bus to encrypt (or decrypt) it, then pass the ciphertext (or plaintext) back over the LPC bus to the computer. This process would be an extremely slow way to avoid cold boot attacks, and would likely be easy to bypass given the ability to tamper with signals on the LPC bus (the TPM would be a decryption oracle!).

Although you could in theory use RSA for bulk encryption, provided you used proper padding like PKCS#1v1.5 or OAEP, it would expand the message (ciphertext would be larger than plaintext), and it would be extremely slow and inefficient. Despite what some other answers have claimed, it would not be insecure when a proper padding scheme is used, but it would be a silly and inefficient use of RSA.

$\endgroup$
  • 1
    $\begingroup$ I'd say that the frequent use of RSA with a static private key (for decryption) would probably be more susceptible to side channel attacks than AES. It would of course be dependent on the implementation specifics, but I'd rather put my cards on AES... $\endgroup$ – Maarten Bodewes Apr 23 at 10:33
  • $\begingroup$ @MaartenBodewes Yes, with one of my half work, I could easily extract keys from OpenSSL. The library implementation, as you noted, really determines the attacks success ratio. $\endgroup$ – kelalaka Apr 23 at 12:04
  • $\begingroup$ Not merely inefficient, but it would be difficult to make it resemble the block characteristics of the underlying device. Any ciphertext expansion, which is a necessary feature of any RSA-shoehorned encryption, would violate OS and application assumptions about atomic or linear writes, requiring another layer in the middle. Avoiding this requires qualitatively changing the premises, from sector-by-sector disk encryption (which is essentially transparent) to what is essentially a file system in its own right. $\endgroup$ – Squeamish Ossifrage Apr 23 at 18:49
  • $\begingroup$ @SqueamishOssifrage Indeed. It could not be used as a drop-in replacement for a block cipher. Although the implementation would not be elegant in the slightest, it would be possible and could be made secure. $\endgroup$ – forest Apr 23 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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