Cold Boot Attacks: The Frozen Cache Approach

by M. E. Kabay, PhD, CISSP-ISSMP Associate Professor of Information Assurance School of Business & Management Norwich University, Northfield VT Part one of this pair of columns described cold boot attacks and their security implications, in particular for software-implemented full disk encryption solutions. Security expert Jrgen Pabel continues with part two. In what follows, I refers to Jrgen. *** 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 < http://coreboot.org >: 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 < http://www.coreboot.org/images/6/6c/LBCar.pdf > 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 solutions. 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-asRAM 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 < http://en.wikipedia.org/wiki/Known_plaintext >. I decided to write a blog about my research, and since every blog needs a catchy name, I settled on Frozen Cache< http://frozencache.blogspot.com/ > 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 < mailto:jpabel@akkaya.de >, although I encourage you to post your questions and comments on

the blog so that others can benefit from them as well. Lets get a good discussion going! *** Jrgen Pabel, MSIA, CISSP is a consultant with Akkaya Consulting Gmbh < http://www.akkaya.de/ >. He runs a technical blog < http://blog.akkaya.de/blojsom/blog/jpabel/ > that often includes security topics. He last wrote for this column in 2008.< http://www.networkworld.com/newsletters/sec/2008/0218sec2.html > M. E. Kabay, PhD, CISSP-ISSMP < mailto:mekabay@gmail.com > specializes in security and operations management consulting services. CV online.< http://www.mekabay.com/cv/ > Copyright 2009 Jrgen Pabel & M. E. Kabay. All rights reserved. Permission is hereby granted to Network World to distribute this article at will, to post it without limit on any Web site, and to republish it in any way they see fit.