Which kinds of cryptographic keys can be burned into volatile memory?

Question

I just read this article (link goes to the page of the article where to quote is from) and have a quesiton regarding the paragraph "Tipps vom Geheimdienst" ("Tips of the Secret Service"):

Aus den Unterlagen entnahmen die Experten auch zahlreiche sinnvolle Hinweise, etwa dass auf flüchtigen Medien kryptographische Schlüssel eingebrannt sein können, da sie meist an der gleichen Stelle gespeichert werden. Selbst wenn ein solcher Speicher nicht mehr mit Strom versorgt ist, könnten Abbilder des Schlüssels extrahiert werden.

This is my translation of it to English:

The experts took numerous usable hints from the documents. For instance, that cryptographic keys can be burned into volatile storage media because they mostly are saved in the same spot. Even if such a storage medium isn't connected to power any more, images of the key can be extracted.

Operating systems use address space layout randomization so I doubt any cryptographic keys stored in RAM while the operating system is fully running (keys for home folder encryption; PGP keys; keys of TrueCrypt (or TrueCrypt successor) volumes; etc.). Those keys should (afaik and please let me know if I'm wrong) only reside in RAM, in the CPU, and on the way in-between RAM and CPU. If they are written to swap, that's of course really bad but swap is permanent storage, not volatile storage which the article talks about.

The only useful kind of key I can think of whose secrecy might be endangered by it being burned into volatile memory is keys used for full disk encryption of the disk the operating system runs on because at the point where it's being decrypted, the operating system isn't fully running so I suspect ASLR might not either.

Is full disk encryption of the disk the operating system runs on vulnerable to this? Are there any other kinds of keys which are vulnerable to this?

I don't regard any keys involved in preventing the user from booting systems without valid signature or any keys involved in UEFI as useful. I regard such restrictions as malicious.

Answer 1

I'll argue that no key is secure against a reset attack (or a cold boot attack) in the context you cite. Since you distinguish between volatile memory and RAM (DRAM) let's first enumerate (at a high level) places that may have caches:

• Input devices will have some kind of cache (mice and keyboard definitely).
• So will do output devices (e.g. a video card buffer, hell, those things have DRAM of their own).
• Buses will not have a cache, but there is one place where buses direct onto a cache and nowhere else: the front end and back end buses are used between the CPU itself and the CPU cache. Yes, the CPU has a cache of its own, and it uses SRAM.

Before we dive into the CPU let's look at two devices that do have a cache: since the keyboard (most of them today) has a cache, a key that you type may be compromised. And since the screen is taken from a buffer in the video card any key that is shown may be compromised. That's a lot of keys already, but let's look at the CPU cache next:

Since encryption and decryption is performed by the CPU, then the key is very likely to be kept in the CPU cache. This is because the CPU uses a least accessed policy for cache overwrites (and a key will be used often if decryption/encryption is happening). And unless you're using some kind of HSM* the encryption/decryption using any key will go through the CPU. Therefore I'll argue that any key that is actually used to perform encryption/decryption can be compromised.

Reality note

Still, the idea of a successful reset/cold boot attack on a chip taken from a random machine is almost in the realm of science fiction. Prof of concept of cold boot attacks have been performed, but they're costly and of quite limited use.

On the other hand, we may be getting close to cold boot attacks as the years progress with better (physical) tools but we are no there yet. For example, I have serious doubts that the biggest issue I highlighted above, the CPU cache, is possible to attack. Taking out the SRAM chip from the CPU without damaging it seems like a daunting task.

Some Reading

• Low temperature data remanence in SRAM - cambridge university
• Similar question on remanece in chips

---

_{* If you are using an external HSM then the network card cache may compromise a key. That is, unless the key is stored in the HSM. But that is another story.}