For those that don’t know what full disk encryption or cold boot are and how they might be connected, here is a short introduction.
This chapter briefly introduces the concepts of full disk encryption and cold boot attacks. If you already know, what they are you can safely skip to the next chapter.
What is full disk encryption?
Full disk encryption or short FDE is a way to protect data on your harddrive. In contrast to file based encryption where each file must be encrypted individually FDE encrypts the whole harddrive / partition.
In a layered view FDE sits between the physical harddisk and the filesystem, whereas a file based encryption sits above the filesystem or is implemented as a part thereof. Back to FDE: As the encryption takes place between the filesystem and the harddisk, FDE solutions are (normally) implemented in the kernel.
FDE is advantageous when everything, even the structure of the filesystem itself, should be inaccessible without the encryption key. This also solves the nasty problem of the plethoria of temporary files generated while you work – with everything beeing encrypted there is no possibility to forget a file. Jürgen Pabel did a presentation about FDE at 25c3.
What is a cold boot attack?
Although it might seem so, RAM chips do not lose their stored information as soon as the power is cut off. Whenever the power ist cut off, the information stored in the chips slowly fades, eventually losing all stored information.
Imagine that a running computer has a secret hidden somewhere in memory. In our case the secret would be the FDE encryption key. Lets further assume that the running operating system denies us access to this secret. A possible attack against this computer is to kill the operating system by switching off the computer and boot a custom operating system made for recovering that precious secret.
If the timespan between switching off and switching on is short enough the data stored in memory is still more or less the same data the originally running OS proteced from prying eyes.
Back to the special purpose operating system: If the system is small enough only a small portion of the systems memory got overwritten by booting it. The attacker now has all the time needed to dump the whole memory content to a disk and with it maybe the sought secret.
It is also possible to extract the memory chips and plug them in a different computer. Further the attack can be improved significantly by cooling down the chips as this will preserve the stored information for much longer. Besides an interesting paper on the subject Alex Halderman et al. have a nice video on their website. Also make sure you look at Jacob Appelbaums presentation at the 25c3.
Locked Computer != Locked Encryption Key
Back to the discussion my friend and I had. Cold boot attacks do work (see Hargreaves, Chivers), there is no denying this. Both, my friend and I agreed that it is quite unlikely that someone steals your computer while you are sitting in front of it and type in a lengthy document. In all likelyhood your laptop is left on the train or stolen while you fetch yourself a coffe. In both cases your laptop should be locked by you, “locked” as in “you need to enter your password to continue to work”.
My friends idea is to remove the FDE encryption key from memory as soon as the computer is locked. The problem there: Even if the computer is locked, it is still doing disk I/O. And to decrypt this disk I/O the key is needed – a classical catch 22. In all likelyhood the computer might even be doing more disk I/O than with you sitting and working on it (footnote: I/O is slow. So the best time to re-index documents ot to virus-scan disk is when the user is not hindered by it).
After we agreed that keeping the key in memory is a bad thing the question was where to store the key in such a way, that the processor can access it without exposing it to cold-boot-attacks in main memory.
Said friend proposed to move the encryption key into the processor cache. This sounds absurd because the processor cache tries very hard to keep RAM and cache consitent. But this behavior can be changed. Modern processors allow the cache to be frozen, so that the content of the cache is no longer synchronized with the main memory.
The primary goal can be achieved: To remove the key from main memory and still be able to do disk I/O. This in itself is a huge achievment to thwart cold boot attacks.
So far, so good. But, even if the technical problems of freezing the cache are solved, there remain more problems to be solved.
For example, disabling the cache of a CPU is like throwing a good handful of sand into a well oiled machine: It (nearly) grinds to a halt. What is even worse is that all disk I/O has to go through this slowed-down CPU-core. The core has to read the encrypted blocks from memory and it has to write the decrypted blocks back to memory. That means hitting the memory wall twice for each byte. If this really is an issue has to be seen, after all memory is much faster than disk. The widespread DDR2-800 RAM transmits 6.4 GB/s whereas current harddisks peak at roundabout 100 MB/s. And that doesn’t even take the harddisks latency into account.
A practical protection against cold boot attacks gets ever more important. One reason for this is that mobile devices stay turned on for longer and longer times. The following
uptime has been executed on my MacBook – and I have no inclination to do a shutdown any time soon.
18:45 up 6 days, 1:23, 5 users, load averages: 1,00 1,06 1,06
Freezing the cache whenever the computer gets locked could be a solution when security is more important than performance. For mainstream or server usage a better way has to be found. I am already thinking about this problem, we’ll see if I find something.
- 1 Frozen Cache – http://frozencache.blogspot.com/
- 2 Christopher Hargreaves, Howard Chivers, “Recovery of Encryption Keys from Memory Using a Linear Scan,” Availability, Reliability and Security, International Conference on, vol. 0, no. 0, pp. 1369-1376, 2008 Third International Conference on Availability, Reliability and Security, 2008. — http://www2.computer.org/portal/web/csdl/doi/10.1109/ARES.2008.109
- 3 Alex Halderman et. al., “Lest We Remember: Cold Boot Attacks on Encryption Keys” — http://citp.princeton.edu.nyud.net/pub/coldboot.pdf / http://citp.princeton.edu/memory/