This is mitigated by a Trusted Computing Group feature - at boot, the OS sets a non-volatile flag, and clears it again on clean shutdown after wiping any sensitive material from RAM. If the system boots with the flag set then the firmware wipes the RAM before booting anything. This doesn't protect you against someone pulling the RAM out of the system and dumping it there, but that's a much harder attack.
It is important to note they could access an image in the memory up to 0.75 seconds after cutting power, but after 1.0 seconds everything had completely decayed. This sounds less like a "cold boot" attack and more like the residual power is still flowing on the substrate for 0.75 seconds.
I wasn't able to automate the use of the freeze spray alas, but I believe that did let me access data after more significant durations.
With the freeze spray I did also manage to unplug the power cable completely and switch SD cards manually.
Edit: In "Cold Boot Attacks are Still Hot:
Security Analysis of Memory Scramblers in Modern Processors"
they say "To assess the feasibility of cold boot attacks on today’s denser and smaller
components, we measured the retention time of five DDR3 and two DDR4 modules from various manufacturers. At
normal operating temperatures, a significant fraction of the data is lost within 3 seconds of losing power."
The Pi 4 I used makes use of DDR4 from what I recall.
It sounds like a typical freezer cools to around -20C, I think the freezer spray I used directly on DDR chip, claims to chill to around -50C, but not sure how much the surface temperature decreases after spraying and how fast it warms up again.
LN2 is 77 K (-196 ºc) and dirt cheap -- cents/pence per litre. Most electronics works surprisingly well in it, at least until it warms up and the condensation starts to be a problem ;-).
I would not expect "residual power" to last for 0.75 seconds. Even if it did, RAM has to actively be refreshed by the memory controller. (DDR self-refresh is only enabled during sleep and I dunno if the Pi even supports that)
It's nice to recover an image but encryption keys are not that. One bit flip and it's game over. This experiment is more useful for human-readable document forensics than anything else.
> If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones.
Can you elaborate a bit? Off the top of my head, I feel like that scenario would leave 128-choose-8 possibilities open, or about 1.4 trillion. Are we calling that "trivial" or am I misunderstanding the attack?
(If you're calling that "trivial", I think that could be reasonable in a cryptography context where you're considering attackers with a lot of resources. It's just different from how I usually use that word. I don't disagree with your conclusion that leakage of even a few bits is worth worrying about.)
If it's 1.4T it depends on what you're using it for. Someone on SO has a verify speed for 512 bit rsa keys at 350k/second which would leave it at I think a month and a half to run 1.4T. That's a random user and a single machine. ECDSA 128 bit verify maybe 6k/s on a single core of a not-great CPU. That puts you about a month or two of a moderate machine assuming there's no fancy gpu things for doing it.
If you just recovered a secret key, you have no idea how many bits were flipped or their positions or if they were flipped at all or even it if it's actually a key rather than random garbage data. Key strength is therefore maintained.
Posting a secret key here and specifying "exactly one bit was flipped" reduces the problem to N guesses where N is the key length since you know all the other N - 1 bits are correct. Leaking just a few bits has catastrophic consequences, in your example all bits except one are leaked.
You can't simultaneously have that key strength is maintained as long as they don't know how many bits are flipped, or where in memory the key was, but also that leaking any number of bits is catastrophic. If your memory dump creates a different distribution on the space of possible keys, it has already compromised the cryptographic security of the key, it's just a question of how much, and the answer here is a lot - even if we had GBs of garbage data, that is still tiny compared to the whole space and can be sifted extremely quickly
> If your memory dump creates a different distribution on the space of possible keys
Is it possible to determine that this has happened though? If you're trying to recover an image and a bunch of bits are flipped, the result might be somewhat corrupted but a coherent image will still be visible. You know that the data was corrupted and where the damage is. Ciphers have avalanche effects, a single bit flip produces completely unusable output which by design reveals no information.
There is extensive research on key finding attacks. Often they only need 30% of the bits. Things can be sped up by exploiting entropy - keys are really random, unlike most of the rest of your memory, so that filters things down, and as you said, an incorrect key produces total garbage on decrypt, which is easy to detect, so you can automate testing and discarding key candidates. Lastly, if you have knowledge of the applications or algorithms involved, you often get some extra data structure around the keys, which makes searching the memory dump trivial.
All that is to say, yes, this is a viable attack vector, even if some or many of the bits are flipped
If you can reliably find the key in memory, even if it's partially damaged, it may practically possible to recover it. You can try keys sorted by edit distance from the recovered material. Maybe there are better methods taking into account the actual cryptography.
The original comment said "One bit flip and it's game over". Which is clear nonsense, I don't have to specify that there's exactly one bit flip, I just need to know that the key is in that general neighborhood and its security is already compromised.
It would be interesting to do this with different delays to see how the noise level increases as the delay increases, then once you have a bunch of images recovered, make an animation of the image getting more and more noisy as the time increases, would also be interesting to compare the results for different ambient temperatures, how much more feasable would this be during January in Norway vs August in Texas?
That's something they did in one of the original papers - "Lest We Remember: Cold Boot Attacks on Encryption Keys" by Halderman et al, with an earlier version of DDR, think it was DDR2.
It's something I'd like to try too. Good point re. the temperature also, I bought a PT100 temperature probe I need to use to measure the surface temperature of the RAM chip too.
* Hardware memory encryption / bus encryption. If implemented correctly, keys never touch RAM and will be discarded instantly across any power disruption.
* Control physical access: don’t allow an attacker access to the DRAM chips.
* Control logical access: use trusted boot systems which don’t allow an attacker to dump arbitrary memory, combined with physical access control so they can’t directly address memory externally.
That is correct, AMD Zen4 (Ryzen 7000) supports transparent full memory encryption. It also supports more granular memory encryption, for example to prevent the host accessing VM guest memory.
Keeping secrets out of main memory, either with registers, encrypted memory, or use of a secure enclave (which in turn uses encrypted memory) for sensitive operations.
