Tom, I don't quite get it. I thought that the cold boot attack was on memory. Someone steals a computer that happens to be in standby, freezes the memory, and move it to another system to analyze. Or someone freezes the memory of a desktop, steals the memory, and analyzes later. How does FDE or Temperature change detection of the motherboard come into play?
Thank you. Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hollebeek Sent: Thursday, November 06, 2008 12:32 PM To: fde@www.xml-dev.com Subject: [FDE] BitArmor cold boot defense I promised you guys an technical explanation of the BitArmor cold boot defense, to show that it wasn't just marketing and snake oil. I apologize for it taking a while, but I've been quite busy. Here it is. As you'll see, this isn't just a marketing attack. It's practical security technology that's a level above anything else that exists. For compliance oriented FDE, maybe you don't need it, but if your laptops need to be secure against organized crime or nation state class threats, this is essential. ------------------------------------------------ Princeton's cold boot attack allows data to be recovered from encrypted laptops, as long as the laptop is stolen while the power is on. Even when sleeping, the disk encryption keys are still held in memory. I'll admit my laptop is usually sleeping when it's on the airport X-ray belt. Publicly available tools allow the contents of memory to be dumped to a USB device, so no technical sophistication is needed to carry out the attack. Simply insert a USB within a few hours after stealing the laptop, boot to it, and you have the key. A variety of solutions have been proposed, but all require changes to user behavior, additional hardware, and so on. BitArmor's solution is the only all software FDE solution that prevents cold boot attacks completely, regardless of what you are doing, and without requiring the user to do anything differently. BitArmor's unique solution is built from three parts. The first is an innovative trick that prevents the attacker from stealing the key without first transferring the memory to another computer. The second trick prevents the attacker from freezing the memory before moving it. These two steps mean there will be some bit flips in memory, though the error rate might be as low as a few parts per million, and searching for the correct key after recovering a key with (potentially) a few errors is trivial. The last part of the solution is to make the in-memory form of the encryption key depend on millions of bits in a cryptographically strong way. This way, as little as a few parts per million of errors is enough to completely obliterate all information about what the disk encryption key is. Of course, this has to be carefully designed in order to be feasible. Note that simply securely hashing a million bit buffer, as suggested in the Princeton paper, isn't computationally feasible. I'll describe the hashing scheme later. BitArmor's solution involves carefully crafted machine instructions, running at high interrupt, holding all keys and key related material in MMX registers so it is never in memory at any point. Due to careful design, the disk I/O overhead is under 10% and that's only for I/O limited operations. The effect on most uses of the computer is unnoticeable. So what are the two tricks that guarantee the user can't obtain a perfect copy of memory? The first trick is to store the encrypted disk key at the offset 0x7c00 in physical memory. BitArmor's FDE device driver loads very early in the boot process, and can claim this memory and use it. The advantage of using this location is that BIOS boot loaders, by convention, load the boot sector into physical memory at this location. So by having the encrypted disk key at that location, any attempt to boot to alternative media will destroy the encrypted disk key. The second trick is to monitor the temperature sensors on the laptop. All laptop motherboards have at least one onboard temperature sensor, and most have a range of sensors, including one in the region where the memory chips are. These sensors are integrated into the board and very difficult to tamper with. If a suspicious temperature drop is noted, the FDE device driver erases the encrypted keys and halts the machine. This prevents some exotic attack vectors (for example, immersing the motherboard in liquid nitrogen). So how do you securely hash a million bits efficiently enough that you can have the code run on every disk I/O operation? There are essentially two requirements. Make sure that brute forcing all possible bit errors is more time consuming than brute forcing the key, and making sure you expect to have that many errors. Let W be the number of bits that are securely hashed, and f be the required minimum number of flips. We need (W choose f) to be large, more than 2^80 or even 2^128. There are a variety of good choices here; W=256 and f~15 is reasonable. But with only 256 bits, if the attacker can get the error rate below 5%, the key can be found. The trick here is "flip amplification". If we XOR together 10 256-bit values, the expected number of flips goes up by about 10 (a bit less, do to "flip fratricide": the same bit could flip twice). Furthermore, XORing a large, contiguous buffer into an MMX register is really, really fast. So the security can be "dialed up" to meet the requirements of your threat model; like we said, millions of bits is quite feasible. Simply choose a buffer size large enough so that the expected flips is comfortably larger than the minimum flip requirement you derived from your threat model. Taken together, these elements create a seamless, software only FDE encryption that renders laptops immune to the Princeton cold boot attacks. (FIPS certification is in progress and should be complete by summer 2008) Tim Hollebeek BitArmor Systems _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
