1

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.

UTF-8
  • 2,300
  • 1
  • 9
  • 24
  • ASLR can (and should) start earlier than `systemd-init`, it starts as soon as the kernel writes the memory map into memory and updates the right register. Even inside the init ram disk (`initrd`) the kernel is using ASLR (that is, if you enable it with `kalsr`). Yet, I'm a little confused with your question. Is there a reason for which you make a distinction between RAM and volatile memory? I believe that they would mean the same on most machines. – grochmal Oct 10 '16 at 23:29
  • @grochmal Thanks for the info. Yes, there is a reason I make a distinction between between RAM and volatile memory. Translating the entire article to English and posting it here would probably be to much and perhaps even illegal. But it talks a lot about there being information stored in places you'd not necessarily think much about. That's mostly on the 2nd page of the article which btw. is about how the GCHQ required The Guardian to destroy a Macbook Air. They required them to destroy every chip which could possibly store information. – UTF-8 Oct 11 '16 at 10:25
  • For example, in the serial controller of the track pad, 2 Mbit can be temporarily stored which meant that they had to destroy that chip. The battery controller had to be destroyed, too. The article doesn't say it directly because the GCHQ doesn't make their list of things to be destroyed public but documents about it have been leaked through Wikileaks. The list includes RAM, DRAM, EPROM, and EEPROM. They also destroyed the keyboard controller because they fear that its cache may hold passwords which have been entered in the past. They don't tell where the crypt. keys allegedly are burned into. – UTF-8 Oct 11 '16 at 10:34

1 Answers1

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

* 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.

Community
  • 1
grochmal
  • 5,677
  • 2
  • 19
  • 30
  • It's not about cold boot attacks as the power can be assumed to be disconnected for quite some time. || The CPU was one of the parts the cared least about. They simply cut through it a single time. Compared to what they did to the other parts, that pretty much nothing. I can see how information may be burned into SRAM but I don't see how this could happen with DRAM. Can you explain it? || They talked about cryptographic keys, not about passwords. So I don't see how the cache of the keyboard has significance or how the cache of the mouse has significance even if you care about passwords. – UTF-8 Oct 11 '16 at 18:45
  • Very good point about displayed crypt. keys stored in the video card buffer if it works. I didn't think about that. But it isn't burned into it because it has been present in a single spot of the video card buffer a lot. It's just that it might still be there from the previous use. But that requires permanent storage. I remember having heard something about a frame which has been displayed previously being shown when a computer started up but don't remember the details. Is video data stored on permanent storage? Because otherwise I don't see how this would work either. – UTF-8 Oct 11 '16 at 18:48
  • @UTF-8 I need to admit that I can't read german at all. And yeah, it is probably not 100% correct to call it a *cold boot attack*, maybe *reset attack* is better. But they're just two faces of the same coin (I updated the answer nevertheless). For the persistence i'll simply quote an old [Rory's answer](http://security.stackexchange.com/a/11918/112042): *most manufacturers try and maximise retention at low current draw*. So you get *some* retention, although i'll argue that a success rate of such a try would be less than 10% (probably). – grochmal Oct 11 '16 at 20:20
  • @UTF-8 For the keyboard I'm thinking about PBKDF2, and since there are not many PBKDFs it is trivial to test all of them to get a key from a password. The mice is pure science fiction, maybe some sort of visual code could be used (yeah, science fiction). As for the video card, those things simply have a rendering buffer, that's literally DRAM. Some cards may have several gigabytes of it, holding textures and hidden parts of previous screens (or GPU computation cache). – grochmal Oct 11 '16 at 20:25
  • The keyboard input of PBKDF2 being known impacts the secrecy of a private key but that's not what the article referred to. The article stated that – according to secret services – cryptographic keys can be burned into memory. I still don't see a single scenario in which this could possibly happen and that's what the question is about (I posed it because I wasn't able to think of any such scenario). – UTF-8 Oct 11 '16 at 20:53
  • Regarding the video card thing: Even if with several gigabyte, that doesn't change the fact that the data is only held there via electric charge. This charge is lost within at most minutes. The answer you linked to states 10 minutes and I remember to have read about 10 minutes, too. We can assume the machine to be shut down for a day. If a machine is destructed in a planned manner by a secret service, it doesn't happen that the machine runs, then is destructed, and then its parts are thrown away for someone with a bottle of liquid nitrogen to grab them within less than 10 minutes. – UTF-8 Oct 11 '16 at 20:57
  • @UTF-8 - AH, OK. I'm pretty confident that you're after the ol' [cambridge report on persistence of data in SRAM](http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-536.pdf). They used SRAM, not really DRAM. But they did it at room temperature not negative temperatures like the "cold" from cold boot. But that was in 2002. This added to Rory's answer above do make you wonder. – grochmal Oct 11 '16 at 21:15