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.
$\begingroup$
$\endgroup$
4
3 Answers
$\begingroup$
$\endgroup$
12
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.
-
19
-
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$– user50302Commented Apr 23, 2019 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$– LuaanCommented Apr 23, 2019 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$– forestCommented Apr 23, 2019 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 ♦Commented Apr 23, 2019 at 10:22
$\begingroup$
$\endgroup$
1
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:
- RSA must use the OAEP scheme to be secure which reduces the message size.
- 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.
- 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.
answered Apr 21, 2019 at 12:00
-
$\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$– forestCommented Apr 23, 2019 at 7:19
$\begingroup$
$\endgroup$
4
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:
The TPM communicates over the extremely slow LPC bus (4 bit width at 33 MHz).
The TPM hardware is generally very slow, being designed for security, not speed.
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.
-
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 ♦Commented Apr 23, 2019 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$– kelalakaCommented Apr 23, 2019 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$ Commented Apr 23, 2019 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$– forestCommented Apr 23, 2019 at 18:52
intel_iommu=onand you should be safe from that particular attack. $\endgroup$