Protecting the encryption key: it is not just the encryption key

I've followed the coverage on Slashdot, Hack-a-day and other sites: it's great that my effort is being exposed to such a broad audience, but it seems that there is a misunderstanding about the details of my research.

I supposedly suggested to protect only the encryption key by "removing" it from RAM and keeping in the CPU cache. However, this is not the case, as I've previously stated in the entry "Protecting the encryption key":

Thus: these round keys need to be kept inside the CPU cache as well (at least for AES, which is used quite often).

Maybe the misunderstanding about what all should be "protected" arose because of the demo code in my first blog entry; it only shows how to "move" 256 bits to the CPU cache and how to than "freeze" the CPU cache. That assembly code was only meant to demonstrate the core concept, not more.

Anyhow, I would like to take this opportunity and to explain a bit more thoroughly what all needs to be kept in the CPU cache in order to achieve "perfect" protection against cold-boot-attacks.

Obviously, the "encryption key" needs to be protected (duh). Secondly, the "key schedule" (I previously called these "round keys") need to be protected; the "key schedule" is derived directly from the "encryption key" and could be seen as being an "expanded" version of the "encryption key". Thirdly, one should aim to protect the "Initialization Vector" (IV). Whether the IV in fact needs to be really kept secret depends on how the IV is determined/generated. The "Encrypted Salt-Sector Initialization Vector" (ESSIV) is one example of an IV that should definitively be protected: the ESSIV is a hash of the "encryption key" and is the default IV used by dm-crypt on Linux. Forthly, any buffers containing the contents of decrypted sectors should be protected in order to prevent known plain-text attacks for ciphers that are vulnerable to this attack (however, protecting these memory buffers is especially tricky). Lastly, any data values calculated during the encryption/decryption should be "securely" stored in the CPU cache in order to prevent key analysis.

I hinted in the "Protecting the encryption key" entry that designing an elegant implementation is somewhat troublesome on Linux. I would like to explain why: some key relevant data is kept in data structures maintained by dm-crypt(.c), but other data items are calculated and managed by the crypto API. The proof-of-concept implementation therefore requires changes in multiple parts of the Linux kernel, this makes it a bit more challenging - unless one is willing to resort to ugly hacks (which I am not).