SRAM has no chill: exploiting power domain separation to steal on-chip secrets

A decade of security research told programmers to hide encryption keys in on-chip SRAM — caches, registers, scratchpads — because SRAM forgets everything the instant power is cut, which makes the classic freeze-the-memory cold boot attack useless against it; this paper (Virginia Tech) points out that modern chips split their power supply into separate domains with pins exposed on the circuit board, so an attacker can solder a probe onto one pad, hold the memory domain at its normal voltage, yank the main power, reboot into their own software, and read the cache back with zero bit errors and no cooling at all.

The argument in one glance

Problem

The key has to be in plain memory while the device runs

Encrypting the storage of a phone, a router or an industrial sensor protects it while it is switched off. But the moment it is unlocked and working, the decryption key exists somewhere in volatile memory in plain form, because the processor needs it. An attacker who steals the device therefore does not attack the encryption; they attack the memory. The classic version of this is the cold boot attack, which chills DRAM until its capacitors hold their charge long enough for the chips to be moved into a machine the attacker controls and dumped.
What people did

Keep the secret inside the chip, where cold boot cannot reach

A large body of work responded by moving cryptography entirely on-chip. Keep the code and data encrypted while they sit in external DRAM, and decrypt only into memories built into the processor die itself — a locked region of cache, the spare vector registers, the small on-chip scratchpad RAM. Published systems do exactly this, using debug registers to hold an AES key schedule or locking a slice of cache and running the plaintext program out of it. The reasoning is sound on its own terms. These memories are inside the package, they cannot be probed on a bus, and they cannot be unsoldered.
Why it fell short

That safety was a circumstance, not a guarantee

SRAM does lose its contents almost immediately without power, and the authors confirm it experimentally rather than assuming it — a cold boot attempt in a thermal chamber at the hard temperature limit of the chip recovers nothing, the extracted cache being indistinguishable from a fresh power-on pattern. But notice what the defence actually depends on. It depends on the attacker being unable to keep power on the SRAM. Nothing in the hardware enforces that. It was true only because pulling the plug on a device pulls the plug on all of it at once.
This paper's idea

Cut the power everywhere except the memory holding the secret

Modern chips do not have one power supply. They have many, split into domains so that idle blocks can be switched off independently, and the supply pins are brought out of the package onto the board so that capacitors can steady them. This paper (Virginia Tech — Jubayer Mahmod and Matthew Hicks) shows that an attacker can clip an external supply onto one of those exposed pads, hold that one domain at its normal voltage, disconnect the main power, and reboot the device into software of their choosing. The SRAM never lost power, so it never lost the secret. No cooling is involved, no bit errors appear, and the memory can be held in that state indefinitely.

Why this problem is worth solving

The attack this one displaces is worth understanding first, because its awkward parts are exactly the parts that disappear here.

A DRAM cell stores a bit as charge on a tiny capacitor. Capacitors leak, which is why DRAM must be REFRESHED — rewritten — roughly every 64 milliseconds, and it is also why DRAM briefly remembers its contents after power is removed. Cooling the chip slows the leak. The original cold boot attack chilled DRAM to around minus 50 degrees Celsius, physically pulled the modules out, plugged them into a machine the attacker controlled, and dumped them. A later attack extended this to phones, where DRAM is soldered down and cannot be moved, by triggering a factory reset that wipes the flash but leaves DRAM contents intact and then booting a small kernel to read them. The attack works but it is noisy. Bits flip during the transfer, so the recovered image is corrupted, and the attacker must SEARCH for the real key among the corruptions — a search whose space grows exponentially with the number of flipped bits

Understanding why SRAM was considered immune requires one detail about how it holds a bit.

An SRAM cell is typically SIX TRANSISTORS. Two inverters are wired in a loop so that each one drives the other, a POSITIVE FEEDBACK arrangement that holds the bit actively rather than storing it as charge, plus two access transistors that connect the cell to the bit lines when the word line is asserted. The only thing this loop needs in order to remember is enough supply voltage to keep driving itself. That threshold is called the DATA RETENTION VOLTAGE, and it is well below the nominal supply of the domain and below the turn-on voltage of either inverter. Processors already exploit this, scaling the voltage of idle memory down to save leakage energy while keeping the contents. But with no capacitor to coast on, SRAM has very little stored charge, so once the supply actually goes away the loop collapses in milliseconds. Prior measurements found around 80 percent retention after 20 milliseconds without power at minus 110 degrees Celsius, and zero percent at minus 40

What people did before, and where it broke

Encrypt the storage and hope the key stays hidden. Standard full-disk encryption protects data at rest and forces a password on every reboot.
But the running system has to hold the key in the clear. Which moves the attack from the storage to the memory, and cold boot showed how to get it.
Scramble or encrypt what goes out to DRAM. Recent memory standards obfuscate DRAM contents with session keys, and researchers proposed DRAM that wipes itself at power-on.
But the self-wiping designs were never shipped, and the scrambling has already been defeated by later cold boot work.
Move the cryptography on-chip. Hold the key schedule in spare CPU registers, or lock a slice of cache and run the plaintext program from it, so that anything crossing the chip boundary is encrypted. Several published systems take this route, effectively turning a large application processor into a microcontroller for the duration of the sensitive operation.
But the guarantee was never checked against a determined attacker. The argument was that on-chip SRAM cannot retain data across a power cut, and that cooling it is impractical because the memory is inside the processor die, so freezing it means freezing the whole device past its rated limits.
Reset the memory in software during power-down. A power-down sequence can scrub residual state before the lights go out.
But an abrupt physical disconnect never runs the scrub. Which is precisely why the attacker yanks the power rather than asking politely.
The gap. Every one of these defences treats the loss of SRAM state as a physical fact. It is not a fact; it is a consequence of the whole chip losing power at the same moment. Chips stopped working that way years ago, for reasons that have nothing to do with security.

How separate power domains turn into a memory snapshot

From an energy-saving design decision to an error-free dump of a locked cache

Split the chip into independent power domains for efficiency

A system-on-chip contains blocks with very different needs, so designers give them separate supply voltages controlled by a power management unit. Roughly, a CORE domain feeds the processors and their L1 caches, a MEMORY domain feeds main memory, flash and the outer caches, and an I/O domain feeds the controllers. Each is power-gated so it can be shut off when idle.
↓ →
Notice that the supply pins are brought out onto the circuit board new

When a domain suddenly draws current, board and package inductance makes its voltage sag. To counter that sag the supply pins are extended outside the package so capacitors can be attached to absorb the surge, and the regulators need passive filtering components regardless. Those components and the test pads beside them are reachable with a probe.
↓ →
Find the pad that feeds the memory holding the secret new

Modern packages hide their pins underneath the chip, so no individual pin can be touched. It does not matter. The same net appears on a decoupling capacitor lead or a board test pad, and these cluster near the power management chip in a recognisable layout. Measure the voltage there and note it.
↓ →
Hold that one pad at its normal voltage from outside new

Attach a bench supply set to the measured voltage, with enough current capability that it does not sag when the rest of the board suddenly leans on it. Then disconnect the main power. The domain briefly draws a surge as the cores fall back on the probe, then settles into a tiny standby current and stays alive.
↓ →
Reboot the device into attacker-controlled software new

The processor sees an ordinary power cycle and boots, in these experiments from a USB drive on one board and straight from internal ROM on another. The extraction program is written to avoid touching the target memory, because anything it stores there overwrites the evidence.
↓ →
Read the retained memory out through the debug interface new

Direct software reads of a cache are not part of normal programming, but chips expose their internal RAMs for hardware debugging. On these processors a co-processor instruction indexes into the cache arrays, followed by synchronisation barriers, and the contents are copied into registers and then out to DRAM. The scratchpad memory on the third board is simply read over JTAG.

Demonstrated on three commercially available ARM boards from two vendors, recovering data from L1 instruction and data caches, from the vector registers, and from an on-chip scratchpad RAM.

The idea

The defence was resting on a physical accident, and the accident had already expired. The claim that on-chip SRAM cannot survive a power cycle is true in the narrow sense the earlier literature meant it — take the power away and the feedback loop collapses in milliseconds, far too fast to matter when yanking a battery takes hundreds of milliseconds. What that claim quietly assumes is that taking the power away is an all-or-nothing act. Chips have not worked that way for a long time. They are carved into power domains precisely so that parts of them can be off while other parts are on, and the boundaries are drawn for energy and performance reasons, not security ones. On the two Raspberry Pi boards the L1 caches sit in the same domain as the cores, and on the third board the scratchpad RAM sits in a memory domain with the core on a different pin entirely — a cleaner separation, and therefore an easier target. Discovering that a security property was never enforced but merely happened to hold, until an unrelated engineering trend stopped making it hold, is the same accidental-guarantee failure covered elsewhere on this site where a memory abstraction turns out to rest on physical behaviour the abstraction never mentioned.

Removing the physics removes the noise, and the noise was the attack. Cold boot is fundamentally a race against leakage, which makes it statistical. Some cells lose their state and some do not, the proportion depends on temperature and on the manufacturing process, and the attacker is left holding a corrupted image that must be searched for a plausible key. SRAM makes that search harder still, because a cell is BISTABLE — it settles into one of two states rather than draining toward a single rest value — so a wrong bit gives no hint about which direction it came from. Volt Boot deletes the whole problem. The supply never drops below the data retention voltage, so no cell ever forgets, and the recovered image is exact. What is left over is not a hardware error rate but a software question, namely whether the secret was still in that memory when the power was cut. Converting a probabilistic attack into a deterministic one by eliminating the variable everyone was modelling, rather than by modelling it better, is the same attack-the-assumption move covered elsewhere on this site where a defence calibrated against an expected error rate is bypassed by an approach that produces no errors.

The security mechanism makes the attack cleaner, not harder. The sharpest detail in the evaluation is what happens under a real operating system. When an ordinary Linux application fills a data structure that approaches the size of the cache, the kernel and other processes evict some of it, and extraction falls to around 90 percent. But the on-chip cryptography systems this paper targets do not run that way. They LOCK the cache lines holding the secret so that nothing can evict them, because eviction would push plaintext out to DRAM and defeat the entire point. Locked lines cannot be disturbed by the kernel, so the attacker recovers the plaintext program in full. Similarly, the caches on these boards stay uninitialised after boot because zeroing a megabyte line by line would slow start-up, and because the random power-on pattern of SRAM is itself useful for generating device fingerprints and random numbers. Finding that a hardening feature and a performance optimisation both work in the attacker favour is the same defence-becomes-vector inversion covered elsewhere on this site where a mechanism added to make a system faster or safer widens the surface it was meant to narrow.

Walking through the attack on a running board

From a soldering iron on a test pad to a plaintext cache image

Numbers from the paper measurements on a Raspberry Pi 4, a Raspberry Pi 3 and an NXP i.MX53 evaluation board.

Step 1 of 5

First, confirm the old attack really does fail

Before proposing anything, the authors reproduce a cold boot attack on cache memory. Bare-metal code fills the instruction and data caches of all four cores, the board is cooled in a thermal chamber for an hour, power is cut for a few milliseconds, and the caches are read back. Mismatch against the stored data is about 50 percent at every temperature tried, down to minus 40 degrees Celsius, which is the hard limit of the chip.

fifty percent is what pure chance looks like here, because an uninitialised SRAM powers on with roughly half its bits set
measured against a fresh power-on image instead, the difference is about 0.10, meaning the cache simply came back as if nothing had ever been written to it

Why it works

Power domains exist so idle blocks can be switched off independently → the boundary between a memory and the rest of the chip is a real electrical boundary an attacker can exploit → so the system can be power-cycled while the memory holding the secret never loses its supply.
An SRAM cell needs only enough voltage to sustain its feedback loop, well below the nominal supply → holding the pad at its normal voltage is more than sufficient → so not one cell forgets and no error correction or key search is needed.
The supply pins must be brought outside the package to attach filtering and decoupling components → the target net appears on capacitor leads and board test pads near the power management chip → so no chip decapsulation or micro-probing is required, only a bench supply and a probe.
Chips expose their internal RAM arrays through debug interfaces for diagnosing memory faults → a rebooted attacker image can index into the cache arrays directly → so the retained contents are readable without any cooperation from the software that put them there.
Caches are left uninitialised at boot because zeroing them costs start-up time and their random power-on state is useful for fingerprints and random numbers → nothing overwrites the retained data before the attacker gets control → so the full image survives into the attacker session.

What it costs (trade-offs and scope)

It needs physical possession and board-level work. The attacker must identify the right test pad, attach a probe, and supply several amps through a bench power supply. This is the stolen-device threat model, not a remote one.
It needs a way to boot code on the device. Signed boot with the image hash burned into fuses would block the extraction step entirely. Many devices lack it because it complicates firmware updates in the field.
Extraction is only perfect when the data survives. The headline 100 percent is retention accuracy, not key-recovery accuracy — under a general-purpose operating system, a structure near the size of the cache loses lines to eviction and recovery drops to between 86 and 92 percent.
Some memory is destroyed by the boot process. On the Broadcom parts a video core wipes the shared L2 during initialisation, and on the NXP part the boot ROM uses the start of the scratchpad as workspace, leaving about 95 percent of it recoverable with an overall error of 2.7 percent.
Three boards, all embedded-class ARM. The evaluation covers two Raspberry Pi models and one multimedia evaluation board. The argument that the attack generalises rests on the ubiquity of power domain separation rather than on measurements from server or smartphone parts.

The evaluation

The paper does something unusual for an attack paper, which is to spend a full section demonstrating that the obvious attack does not work. Cold boot is reproduced properly, with an hour of static cooling in a thermal chamber and bare-metal code controlling exactly what is in the caches, and it recovers nothing. Only then is Volt Boot introduced and applied to three targets: caches under bare-metal code and under Linux, the 128-bit vector registers that published systems use to hold AES key schedules, and a 128 kilobyte on-chip scratchpad, checked by storing four copies of a bitmap image and measuring where the errors land.

Property	Cold boot on DRAM	Cold boot on on-chip SRAM	Volt Boot on on-chip SRAM
What keeps the data alive
How long the window lasts
Errors in the recovered image
Equipment required
Effect on cache-locking defences

Retention accuracy is 100 percent for bare-metal cache contents on all four cores of both Raspberry Pi boards and for the vector registers. Under Linux, recovery of a data structure the size of the cache falls to between 85.67 and 91.78 percent because of eviction by other processes, while smaller structures are recovered completely. The on-chip scratchpad is recovered with 2.7 percent overall error, concentrated in the region the boot ROM uses as workspace.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The headline number needs reading carefully, and the authors flag this themselves in a footnote. The claim of 100 percent accuracy is about DATA RETENTION — whether the bits that were in the memory are still there — and not about whether an attacker successfully extracts a key, which depends entirely on whether the secret happened to be resident when the power was cut. The Linux measurements make the distinction concrete, since recovery falls to between 86 and 92 percent once the kernel starts evicting lines, and it is only the cache-locking defences that guarantee a perfect result. The scope is also narrower than the framing suggests. Three boards were tested, all embedded-class ARM parts from two vendors, and the generality argument leans on the ubiquity of power domain separation rather than on measurements from a modern phone or server chip. Two accidental defences show up in the results and are reported rather than hidden: a video core wipes the shared outer cache on the Broadcom parts during initialisation, and the boot ROM on the NXP part scribbles over the start of the scratchpad, which prompts the honest footnote that hiding secrets in that clobbered 5 percent might be a defence, though they did not verify that the whole region is overwritten. The countermeasure discussion is likewise candid about what does not work. Removing power domains is impractical, purging memory at shutdown fails against an abrupt disconnect, and hardware reset of cache data arrays does not exist because cache correctness depends on the tag arrays rather than the data arrays. What is left is enforcing the secure-world attribute on cache lines, since clearing that attribute also erases the line, and mandating signed boot so the attacker cannot run the extraction code in the first place.

Background

When a guarantee turns out to be a circumstance

This paper sits in the site’s security and hardware clusters and rhymes with several ideas covered elsewhere on this site. Its core move — showing that a widely relied-upon safety property was never enforced by anything, and held only because of an unrelated fact about how machines happened to be built — is the same accidental-guarantee failure the Rowhammer pages describe, where the isolation between memory rows was assumed rather than checked until charge started leaking between them, and where the fix has to make the guarantee explicit rather than patching the symptom. Its threat model rhymes with the temporal memory safety page, which likewise finds that a property everyone assumed the system maintained needs real machinery to actually hold. The observation that a mechanism added for performance opens the attack, since power domains exist purely to save energy, is the same optimisation-becomes-vector inversion the cache side-channel and control-flow prediction pages make when a structure built to go faster turns out to leak what it was speeding up. Its insistence on reproducing the old attack first, in a thermal chamber, rather than citing the belief that it fails, is the same measure-it-yourself discipline the performance-analysis page argues for when a proxy has quietly stopped describing the thing it stands for. And its target audience — small unattended devices that collect sensitive data and can simply be picked up — is the same physically-exposed-embedded-system setting the MIPS hardening page works in.

If you remember only three things

1. The accepted defence against cold boot attacks was to keep secrets out of external DRAM and do the cryptography inside the processor, in a locked slice of cache or in spare vector registers, because on-chip SRAM holds its bit in a feedback loop with almost no stored charge and forgets in milliseconds once power is gone. The authors verify that this is true — a cold boot attempt in a thermal chamber at minus 40 degrees Celsius, the hard limit of the chip, recovers a cache indistinguishable from a fresh power-on pattern. But the property was never enforced by hardware. It held only because cutting power to a device cut power to all of it.
2. Chips stopped working that way for energy reasons. A system-on-chip is divided into power domains that can be switched off independently, and their supply pins are brought outside the package so capacitors can steady them against voltage sag, appearing on board test pads near the power management chip. Volt Boot attaches an external supply to one such pad, holds that domain at its normal voltage, disconnects the main power, and reboots the device into attacker software — which reads the retained memory back through the hardware debug interface that exposes internal RAM arrays. Standby current settles to about 8 milliamps and the memory can be held alive indefinitely.
3. Because no physical variable is being raced, there are no errors to correct. Cold boot leaves a corrupted image requiring a key search that grows exponentially with the flipped bits, and SRAM makes that worse because its cells are bistable. Volt Boot recovers bare-metal cache contents, data cache patterns and 128-bit vector registers with complete accuracy. The irony is sharpest under a real operating system, where eviction costs the attacker some data — except against the very systems this targets, which lock their cache lines so the secret cannot be evicted, and therefore hand over the entire plaintext program.

Check yourself

Check your understanding

1. On-chip SRAM was considered immune to cold boot attacks, and the authors confirm experimentally that freezing a board recovers nothing from its caches. Predict what makes the attack possible anyway.
2. Cold boot on DRAM leaves the attacker with a corrupted image and an expensive search for the real key. Predict why Volt Boot needs no such search.
3. Under ordinary Linux the attack recovers only 86 to 92 percent of a data structure the size of the cache, yet the paper argues it is perfect against the systems it targets. Predict why.
4. The paper surveys countermeasures and finds most of them impractical. Predict which one it identifies as genuinely effective on existing hardware.

Sources

Jubayer Mahmod and Matthew Hicks. “SRAM Has No Chill: Exploiting Power Domain Separation to Steal On-Chip Secrets.” ASPLOS 2022, Lausanne. Virginia Tech. DOI 10.1145/3503222.3507710.
Full text of the paper was used for this explainer, including the cold boot reproduction in Section 3, the attack construction and enablers in Section 5, the execution steps and accessibility measurements in Section 6, the three target memories in Section 7, and the countermeasure discussion in Section 8.