Ok, I know, I know. I owe you guys a proper update after being “absent” from blogging for quite some time. So, here is my take on the recently released Princeton Memory Vulnerability that seems to be gathering so much attention with the press and creating a sort of panic in the encryption community.
For those who want to read the paper for themselves, you can find it here. For those who aren’t patient enough, here is a brief overview of the paper.
We all know, of course, that the DRAM loses its contents when the power is of. However, the question as of how long it would take for the DRAM to “forget” was never much paid attention to. This is probably because (and I quote) “[m]ost experts assume that a computer’s memory is erased almost immediately when it loses power, or that
whatever data remains is difficult to retrieve without specialized equipment.” And the Princeton paper released earlier this month showed that these assumption are incorrect.
Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount successful attacks on popular disk encryption systems using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay.
Moreover, the paper presented a “suite of attacks that exploit DRAM remanence effects to recover cryptographic keys held in memory.” They showed these vulnerability by defeating file encryptions systems like Microsoft’s BitLocker(Windows Vista), Apple’s FileVault (Mac OS X) and TrueCrypt (open-source disk encryption product for Windows, Mac OS, and Linux platforms).
…[C]onfirmed that decay rates vary dramatically with temperature… obtained surface temperatures of approximately -50 *C with a simple cooling technique: discharging inverted cans of “canned air” duster spray directly onto the chips. At these temperatures, …fewer than 1% of bits decayed even after 10 minutes without power. To test the limits of this effect, …DRAM modules [submerged] in liquid nitrogen (ca. -196 *C)…[has] only 0.17% [decay] after 60 minutes out of the computer.
It seems that the semicon physics community has long been aware of the remanence effect in DRAM, in a 1978 experiment it was even found that there can be no data loss for a full week without refresh when cooled with liquid nitrogen.
Over at the FDE mailing list, members of the encryption community have been voicing out their suggestion regarding this vulnerability:
Garrett Groff says:
The attack exploits hardware, so I suspect we’ll need a hardware solution for this problem.
and suggested ways to mitigate the attack:
* Use a drive like Momentus… and hope that the anti-tampering mechanisms within the Momentus drive make hardware-based attacks (like the RAM attack) infeasible and unreliable.
* Don’t use standby mode. Instead, use hibernate (though hibernation might still be vulnerable depending on the FDE solution) or shut off the computer.
* Physically make RAM difficult to remove from the machine (crude, but effective?).
* Set BIOS boot sequence such that the machine boots to the HDD first; password protect BIOS. (I know, I know. Not fool-proof, but the extra time it takes to reset the BIOS & boot to a CD or USB stick might make the contents of RAM unreliable. Having said that, this is only mitigating if attacker uses your own machine to stage the attack. Bets are off if he removes the RAM & puts them in his own machine. But hey, it’s a good thing to do regardless, right??)
Bryan Glancey on the other hand suggested:
* Split encryption Keys (or s-box tables) into separate pieces
* Dynamically relocate Keys regularly in memory – to make exact location difficult to determine
* Overwrite memory several times when unloading Key
* Encrypt key in memory with another key
Andreas Khun argued that:
…in the end all the possible fixes that have been listed are only software fixes for today’s inherently insecure, archaic and simply out dated PC architecture. Only a migration to a trusted PC architecture as proposed by the Trusted Computing Group and technologies like the forth coming Intel TXT and Danbury architectures will help solve today’s known problems with untrusted platforms.
Secure encryption solutions like Seagate’s native hard drive encryption, where the key is never exposed outside of the hard drive enclosure area, and turning on the TPM are the next step to propel us forward into the new century of trusted computing.
The software encryption hack is but one occurrence of all the hack possibilities as long as the world doesn’t fess up to the fact that only software in combination with appropriate new but already existing hardware is employed. To continue trying to do it all in software is just a foolish proposition.
Steve Sprague believes that:
FDE is just a simple one. Customers need to bulk encryption in the drive hardware it is a superior solution to any software and always will be. A single chip solution for Encryption Key management and access control is key.
Here are my take on the issue:
1. I believe that we need a more secure PC architecture. For the encryption community, this issue is a major draw back because as cryptographers and cryptographic engineers race to strengthen encryptions, we find that a flaw in physical security of the data can undo all these in a matter of minutes. When it comes to more “secure RAM” we may find that a faster decay may compromise reliability. Nevertheless, I agree with Garrett, for a hardware problem, we should look for a hardware solution.
2. Data scrambling, dynamic re-allocation and memory encryption can also help but may affect performance and requires error checking and decryption / unscrambling of the key that would increase the time complexity of encryption algorithms. And we must also put in mind that if we are to encrypt keys it would also need a key/password which in turn needs to be put somewhere. And that somewhere may very well be the memory itself, making it only harder but not impossible to crack.
3. Theoretically, Symmetric Key Encryptions are more secured that Public-Key Encryption IF (AND ONLY IF) the key is guaranteed secret and is never. Public-Key guarantees this in the form of the assumed computational hardness, however the attack discussed here compromises the key and shows the ease of recreating an AES and RSA private keys within minutes. The best solution to this problem would be one-time keys. However, we will be faced with the Key Distribution Problem. It seems to me that the best solution to this problem may well be the migration from Public-Key to Symmetric Key Encryption. So, I say that this is one more reason to switch to Quantum Cryptography.
4. Some hard drives supports encryption and authentication even when in sleep or hibernate mode. Mine does, anyway. This means that upon ressumption from sleep mode or from hibernate mode, it will immediately prompt for a hard drive password. This is a good place to start. (I haven’t checked whether or not it stores the Key in the DRAM longer than necessary, though.)
5. Also, you may want to password protect the bios to boot to the HDD first this buys you time for the OS and the Bios to overwrite the DRAM. (Of course, the attacker can simply take the DRAM out and insert it in another system.)
6. Don’t just screen lock, unless you trust your door.
What we should remember is that no matter how strong your lock is, if you leave the key lying around, you might as well leave the door wide open.
I still believe that QC is the best way to go. Once, implemented fully and properly as it is in theory, can guarantee an unbreakable security.