Solution Against Cold Boot Attack In the Making
Bubba writes "I just discovered this blog: Frozen Cache. It describes a concept for preventing cold boot attacks by saving the encryption key in the CPU cache. It is claimed that by disabling the CPU cache the key will remain in cache and won't be written to memory. The blog says they're working on a proof-of-concept implementation for Linux. Could this really turn out to be a working solution?" Update: 01/19 20:26 GMT by KD : Jacob Appelbaum, one of the authors of the cold boot attack paper, wrote in with this comment: "It's not a solution. It simply seeks to make it more obscure but an attacker would certainly still be able to pull off the attack. From what is on that blog, there's still a full keyschedule in memory at this time. This is how we reconstruct the key, the redundant information in memory; it's not just the 128/256 bit key itself. For older methods, they needed the actual specific key bits but we don't need them because we recreate them. Basically, the CPU is acting as a ghetto crypto co-processer. Emphasis on ghetto. It's a nice suggestion but the devil is in the details and sadly the details in this case aren't really up to snuff. It's a bogus solution."
Not to mention, this is posted on the internet. Select the text you don't know about, right click and choose search google for "text". Firefox automagically opens a search on the topic in a new tab, and chances are the Wikipedia article is one of the top five results which should be a good enough starting point to see if the topic is of any interest to you. Magically, the old style of handholding journalism where authors are forced to assume the reader has the education of a 5th grader goes away, and society can actually advance further than the lowest common denominator.
You need to understand that there are different types of RAM. The main memory, that of which you have gigabytes, is DRAM. CPU caches are SRAM.
DRAM is, essentially, a tiny capacitor that is regularly recharged. If you cool it down, it doesn't lose its charge as fast, so you can read it even after power loss.
SRAM works differently. The data is stored by a few transistors wired together in a way so they can maintain a specific set state even when the external input goes away. There are no capacitors involved here, so once the supply voltage drops, the data is lost.
Cut hole in case wall so your "intrusion switch" doesn't trip.
Oh the fun cat and mouse game of security.
Carefully repowering SRAM can maintain the contents. I have seen SRAM come up with essentially 99% of the contents still intact after the SRAM had been powered down for over a week. I guess that once powered up, the SRAM has a preference to come back the way it was before powerdown.
Or perhaps the slight residual voltage kept the SRAM contents intact. (Even though it was probably less than one tenth of a volt.) SRAM draws very little current when the voltages are reduced. Thus the power rails can maintain some small voltage for a very long time. .
Transistors, especially MOSFETs are quite capacitive by nature of functioning by P-N junctions. MOSFETS have fairly considerable gate capacitance due to the fact that the gate is insulated by a layer of gate oxide, forming a quite apparent capacitor. This is indeed why your computer has a clock speed limit, it takes time to charge up these capacitors due to an RC time constant.
Except that real "trusted computing" using a TPM chip doesn't store the key in the CPU or in RAM, it is stored in the TPM.
This is a dangerous belief. It is true that some keys remain inside the TPM, at least as long as the chip is being accessed only through its wire interface. However, the TPM ist not suitable for bulk encryption. Applications therefore typically use the TPM only to store keys, which are extracted to memory when needed.
http://erichsieht.wordpress.com/category/english/