Cold-boot attacks: The 'frozen cache' approach

* Developing a countermeasure for cold-boot attacks

Part one of this pair of columns described "cold boot attacks" and their security implications, in particular for software-implemented full-disk encryption. Security expert Jurgen Pabel continues with part two.

Part one of this pair of columns described "cold boot attacks" and their security implications, in particular for software-implemented full-disk encryption. Security expert Jürgen Pabel continues with part two.

In what follows, "I" refers to Jürgen.

* * *

Since computer memory can no longer be seen as inaccessible to adversaries, where instead should encryption keys be placed when the computer system is powered on? Peter Stuge gave me an idea during a presentation about an open-source BIOS called “coreboot”: coreboot employs a little known CPU configuration, which makes the CPU cache appear as normal RAM to the CPU. This concept is called “Cache-as-RAM” and serves as the basis for my research towards a mitigation against cold-boot attacks.

The security benefit of using CPU cache as memory is that it is not vulnerable to cold-boot attacks because the CPU cache is always reset by the CPU during the initialization phase. Moving all cryptographic material from RAM to the CPU cache would therefore render cold-boot attacks ineffective against software-implemented full-disk encryption.

However, there is one major drawback to using the CPU cache as secure memory: it severely degrades the system performance. Just how much so? Well, during the first test, response-time was nonexistent and I thought that I had crashed my computer. It took me a few seconds to realize that it did not crash, but instead it was just absurdly slow to react to any input.

Solving the performance issue is thus a crucial aspect of the proof-of-concept implementation on which I am currently working. One way to minimize the performance impact is to activate the Cache-as-RAM mode only when it is required for security: for example, only while the screen is locked. Thus, users would not suffer any performance penalty while working but maintain security whenever the computer system is unused and might therefore also be exposed to unauthorized physical access.

The concept of my research is easy – maybe even trivial – but the devil is in the details. It is not enough to just move the encryption key into the CPU cache because other cryptographically relevant data would remain unprotected in RAM. For example, it is important that all operating system buffers that contain decrypted disk sectors are also moved into the CPU cache in order to prevent known-plaintext attacks on the encryption key. 

I decided to write a blog about my research, and since every blog needs a catchy name, I settled on “Frozen Cache” because the contents of the CPU cache are static in Cache-as-RAM mode. I hope you will read it if you would like more technical details about my research (e.g., kernel concepts, assembly-language code, etc).

If you would like to contact me, you are welcome to send me an e-mail, although I encourage you to post your questions and comments on the blog so that others can benefit from them as well. Let’s get a good discussion going!

* * *

Jürgen Pabel, MSIA, CISSP is a consultant with Akkaya Consulting Gmbh. He runs a technical blog that often includes security topics. He last wrote for this column in 2008

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT