Hacker News Reader

Comment by drones | Hacker News Reader

I thought ram chips had volatile memory. As soon as it loses power it effectively wipes all data, no? How does the physical removal process preserve the contents? Are modern RAM chips not volatile anymore?

View on HN

They literally freeze them with liquid nitrogen, which makes them preserve their state.

Huh, TIL: https://en.wikipedia.org/wiki/Cold_boot_attack

A RAM module should keep some power in the module to erase itself when the external power is lost. Or when suddenly the temperature drops by a lot.

An alternative is to encrypt the data.

AMD calls that SME for example. https://www.amd.com/en/developer/sev.html

(quote from link)

> The key is generated by the AMD Secure Processor at boot.

Wouldn't this key _also_ be accessible? Maybe not on the same _chip_ but it's still at some level in a memory chip somewhere, they would just need to find it?

It's stored inside the CPU of the secure element, in something like a register. Otherwise both the key and the ciphertext would be in the ram and the protection would be pointless.

Possibly, but now you have only one circuit to harden against such attacks, and you can continue using commodity DRAM ICs and modules.

Seemingly it'd be possible to attack an operating memory controller by etching with a laser, editing the circuit with a Focused Ion Beam (FIB) machine and putting some probes down to extract the key. But it's then an arms race with chip manufacturers who would try and bake in ever more sophisticated and complex tamper-detection to their chips.

Look up Christopher Tarnovsky talks from Black Hat 2009, Black Hat 2010, DEF CON 20, hardwear.io 2019.

It isn't nearly as easy since the key never leaves the inside of the CPU. The key never goes to main memory or is exposed outside of the part used to encrypt/decrypt memory inside the CPU. Attacking a specific register instead the 'secure' enclave of a CPU is much harder than attacks like the OP where your rip out the RAM.

This type of system has been used pretty successfully for nearly a decade on the AMD SOCs used in the XBOX consoles.

It doesn't lose content as soon as you lose power.

One fun way I saw this was when working on LCD support in a bootloader. You do a quick power cycle and if the framebuffer location is fixed in memory and you don't initialize the contents, you may see faded traces of the picture from previous boot.

In my experience that's more of a side effect from TFT displays. Each pixel has its own gate and can hold a charge for quite a long time.

It can also be a side effect of older LCDs, when power is lost the crystal can take a long amount of time to depolarize. If you apply backlight you'll see an afterimage.

LCDs are driven by the controller and have no knowledge of the framebuffer location, or even access to the host address and data busses. So if you see an afterimage, that's in the pixel.

No, physical attacks are possible for many years now. They just require very high manual skill level. Ram chips must be immediately (as fast as possible after power goes down in case you don’t have control over when computer loses power) frozen by liquid gas and then moved into ram-reading jig.

Or you know a can of bottled air upside down and a bootable usb will do it unless the efi is locked down and USB-boot disabled, in that case you also need to move it over to your own laptop.

I remember switching my Commodore 64 off and on rapidly while it was displaying something on the bitmap graphic screen. The system would reset, but you could enable graphic mode and see 90% of what was there.

At normal DRAM module operating temperatures and assuming you want to stick to JEDEC specifications, retention times may typically be 50uS[1]. This low number is due to the standard having an extremely low tolerance for errors, and the inevitable problem of some MOS transistors/capacitors (a cell) being defective and having a much higher leakage rate than typical cells. Hence the standard has to cater for the weakest cell due to the extremely low tolerance for errors.

In [2], the authors used readily available compressed gas[3] to chill (probably to approx -50oC) DDR1 and DDR2 DRAM modules during operation, then whilst the DRAM modules remained chilled, cut power to the computer, waited a period of time and then read out the DRAM module data for comparison. With power cut for 10 minutes, a read error rate of just 36 bytes per megabyte was observed. This increased to an error rate of 1700 bytes per megabyte at 60 minutes when chilling to a lower temperature using LN2.

The authors of [2] tested DDR1 and DDR2 DRAM retention without use of cooling, and results varied between different DRAM modules (different sense amplifiers, different MOS transistor/capacitor fabrication methods, different DRAM module heatsink designs, etc) but generally it showed 5 minutes unpowered would generally erase all data, but some remnants could still remain (e.g. enough to make a faint outline out of a photo stored in memory).

Note that like the 2008 paper[2], this paper also uses DDR1 and DDR2 DRAM chips. The main reason for this choice is DDR3+ specifications and modern memory controllers implement "data scrambling"[4], originally not for security reasons (that's just a bonus side effect), but for electrical reasons to reduce di/dt noise on the data bus. "Data scrambling" means that data is XOR'd with a pseudorandom function, thus if you write 11111... or 00000... you'd expect on average the data bus to have the same average electrical characteristics. Since row hammer, the pseudorandom function has been improved to provide security against cold boot attacks. It's possible for the memory controller to use low-latency strong encryption such as ChaCha8. AMD "Memory Guard" uses AES128/NIST SP 800-90[5] and Intel's "Total Memory Encryption" uses AES128/256-XTS[6].

[1] Page 19 (PDF), https://www.egr.msu.edu/classes/ece410/mason/files/Ch13.pdf

[2] https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...

[3] https://en.wikipedia.org/wiki/Freeze_spray

[4] https://web.archive.org/web/20190616183914/https://www.eecs....

[5] https://www.amd.com/system/files/documents/amd-memory-guard-...

[6] https://cdrdv2-public.intel.com/679154/multi-key-total-memor...

Reply on news.ycombinator.com