If the computer is turned on when it physically falls in hands of the attacker, you might be at risk even with whole disc encryption enabled and the screen locked requiring your (non compromised) password. This is especially true for portable machines like laptops and net-books. There are many possible attacks, we will look into a specific one called cold boot attack in this post.
Something about memory
Chances are that your main memory is DRAM technology based, which includes popular ones such as SDRAM, DDRx and even the VRAM in most cases. As it is widely considered to be volatile type of memory, we are under the impression that it loses the stored contents after power is cut off. Sadly the contents are not lost instantaneously, but they decay/degrade gradually due to the way DRAM stores data.
 |
| Figure 0 : A DRAM Cell |
Capacitors are not perfect. They lose charge over time as leakage current. Thus, each DRAM cell has to be `refreshed' frequently enough to retain content. Even though manufacturers usually recommend the DRAM be refreshed at least every 64ms (to ensure that there is no data corruption), well built DRAMs have a retention period that is significantly greater than the suggested refresh period. It goes without saying that some bits do corrupt, but the rate at which they do is pretty low when you put 64ms in perspective. This is true even after turning the power off entirely.
How does this concern me?
Well, the significantly long retention period of main memory is a security hole. If a computer is physically compromised when it is powered on, the attacker can read most of the contents stored on your main memory. The main memory includes wealth of information : any user names and passwords that are `cached' by applications, encryption keys for hard drive/volume encryption as well as SSL private keys for active connections, and (maybe partial) contents of any file that is or was open in recent past (as after closing the file, most operating systems do not clear the corresponding memory pages used as block cache, for obvious performance reasons), including portions of deleted files at times as well. This is assuming the machine is locked in some sense, and the unlocking password is not known to the attacker.
At room temperature, the DRAM holds on to the stored bits if the power down/up cycle completes in 64ms. Errors are introduced as powered-off period increases. The period during which no or very few bits corrupt can be significantly increased if the DRAM modules are cooled to near or beyond 0 degree C. Such `cold' modules can then be inserted into another compatible machine and their contents dumped for detailed analysis. I believe that the reason for extended retention is because as the capacitors usually have Aluminum oxide as dielectric whose leakage current reduces as temperature reduces.
A very good paper from Princeton University discussing how to detect keys in the dumps is here. They claim to have broken almost every hard drive encryption solution there is :(. They also provide software to dump memory contents on a portable drive.
This technique is important for forensics/law enforcement as well. During a bust of a computer crime suspect, memory dumps of the machines are extremely important to support the case. This technique allows the law enforcers to get the system state or a snapshot as it was at the time of the bust even without the suspects' co-operation.
Note that the technique is ineffective against other types of memory, for example bistable latched SRAM. So in case you are wondering if you could get something out of the hard drive caches or something from the buffers of a compromised router, you are out of luck!
Does it really work? Can I see it working on my machine?
Sure!
I've created a simple RAM browser (kernel) named `RAMBO' (download source) which, as the name says, can be used to browse the RAM contents after a simulated theft and cold reboot. You can choose to be super-realistic, pulling out the cord of your desktop or pulling out the battery of your laptop and putting it back in a jiffy. If you are worried about pulling the cord while windows/*NIX runs, you can choose to load a file to certain RAM location, reboot and check if the contents are readable after reboot. The program is to be loaded from a multiboot compliant bootloader such as GRUB. It does not touch any other piece of hardware than the processor, memory and keyboard, so rest assured that you will not have a corrupt disc or fried electronics. In case you do not have such a loader installed already, you can install the loader on a floppy or a USB stick and copy the program to it so that you can load it when you boot from USB/floppy. The README provides more info on how to use it.
Real nice stuff to read. Let me use it and see the rest.
ReplyDeleteAmazing ! will try ...
ReplyDeleteOk...here goes a realistic scenario...
ReplyDeleteConsider that i am trying to hack into a highly secure MainFrame or even an ATM machine in which i have inbuilt encrypted Opcodes. We know that such Mainframes usually are also multi-core systems with data also encrypted ; In such a case if, they form their own key-encryption and decryption procedures, with say some kind of key-transformation, then WILL COLD Attack in Boot-time still work ? Actually the problem may be easily much more complicated by differential caches in a shared memory system, which again maybe a distributed memory system. Thus to sum up the bottlenecks for Cold Boot Attacks, can it overcome :
1. Multi-Core Processor systems with Encrypted Instructions and Data.
2. Different Cache sizes for a Shared memory system in a Multi-core architecture.
3. Distributed Shared memory systems.
4. A self-proclaimed oracle rule for Encryption and Decryption with 'r' key-reversals (for example). I am not much into Info. Sec. and hence do not know about this stuff.
Do let me know ur feedback on the same.
@Chandler :
ReplyDelete| Consider that i am trying to hack into a highly
| secure MainFrame or even an ATM machine in which i
| have inbuilt encrypted Opcodes. We know that such
| Mainframes usually are also multi-core systems with
| data also encrypted ; In such a case if, they form
| their own key-encryption and decryption procedures,
| with say some kind of key-transformation, then WILL
| COLD Attack in Boot-time still work ?
Hmm. Let's see. This attack concentrates on the ability of capacitive DRAM to hold data after brief power cut, encrypted or not. It mainly makes sense against portable devices such as laptops, smartphones and iPad etc.
Anyway - let us assume that you have physical access to the system while it is powered on, and are allowed to tinker with it for reasonably long period. As the system was working when you lay your hands on it, the decrypted data and instructions must be accessible to the processor. It does ont matter how many processors with how many cores.
If the processor is a specialized processor which stores the key used to decrypt the instructions as they come from DRAM, you can pull it out, hotwire and find out the key - tricky but can be done as you have control over the system.
If the processors are the usual, general purpose microprocessors, then the keys may well be present in some attached external security device, maybe a smart card or even as simple as a USB device. Whatever the case, as the system was working when you got to it, the processor had access to the key, as otherwise the system would not have been working. Assuming that the external device does not perform actual decryption, the processor must have the key that was retrieved at some point of time. The places where the processor can access the fetched key from are the registers and the DRAM itself. Note that you can not store anything exclusively in caches only (It will be interesting if someone can test this on a non-write-through cache). Generally the encryption key is not stored in regs, which means the processor reads the encryption key in plain text from some DRAM location. If the processor can access, so can you when you perform this attack, period.
This attack may or may not work if the decryption is done by dedicated hardware which does not talk to DRAM, for example a smart-card. It depends on whether the card maintains a session, as you can still get the private key used by the smart-card to talk to the processor in some DRAM location. Still, we can not say anything with surity for this case.
| Actually the problem may be easily much more
| complicated by differential caches in a shared memory
| system, which again maybe a distributed memory
| system.
Again, unless you have write-back caches, when the system has shared memory across all processors, this attack should work. For a NUMA or distibuted memory system, this method should work equally well if you can cut the power to all the modules within reasonable time window and be able to load the memory dumper or browser on each processor. Complex to analyze; but not safe.