Technical Perspective: Defending Data from SRAM-Based Attacks

The accompanying paper, “SRAM Has No Chill…” by Mahmod and Hicks, is both a fascinating read and, in my opinion, will have a significant impact in practice. Here’s why!

More than 15 years ago, a research paper introduced a new security attack with a catchy name: Cold Boot.¹ What is Cold Boot? It is an attack targeting secrets stored in dynamic random access memory (DRAM).

Surprisingly, DRAM cells retain their charge for several seconds after being powered off. In fact, when chilled to –50°C, they can preserve their contents for tens or even hundreds of seconds. This opens up the following straightforward attack vector. An attacker can steal a running device, rapidly cool its DRAM using canned air, insert a USB stick containing a malicious OS image, and reboot the device from external media. Even if the device loses power briefly during reboot, DRAM retains most of its data. Once the malicious OS boots up, the attacker can access sensitive data preserved in DRAM. One of the most well-known Cold Boot attack demos involved stealing a disk’s encryption key to decrypt its contents.

The discovery that DRAM contents are vulnerable to simple Cold Boot attacks sparked a wave of research in both academia and industry focused on designing systems resilient to such attacks. While various architectures were proposed, the most common approach was implementing encrypted DRAM systems.

Academic research proposed several software-only solutions. Encrypting DRAM contents in software is challenging because the encryption logic, including its state and data, must never be exposed to DRAM. This requires solving two key challenges: identifying non-DRAM memory to securely store both state and data (including the encryption key), and building a runtime that prevents exposing its logic state to DRAM (even in scenarios such as handling interrupts or flushing a cache).

Industry proposed encrypted DRAM implemented in hardware. Hardware vendors have put forward trusted computing extensions, such as Intel SGX, Intel TDX, or AMD SEV-SNP. These hardware extensions enable DRAM encryption (and integrity protection) by storing the encryption key securely on the system-on-chip (SoC). The encryption logic is performed entirely in hardware and thus never exposed to DRAM.

Despite many trade-offs, all these approaches rely on a fundamental assumption: static random access memory (SRAM) is safe because it loses its contents almost instantly upon power loss. Thus, encryption keys and all sensitive states needed for encrypted DRAM can be placed in the on-chip SRAM of the SoC (for example, in caches or in dedicated internal RAM) or in internal registers that, like SRAM, also lose their contents upon power loss.

Problem solved! We’re safe now, right?

Not quite. The accompanying paper demonstrates we are not as safe as we think.

Why? Because modern SoCs include power domains that allow selective powering of different parts of the SoC. Why is this a problem? Modern SoCs prioritize energy and thermal efficiency, employing sophisticated strategies. If certain parts of the SoC are unused, they are powered down to save energy or operated at lower frequencies to reduce heat. Smart, right?

Yes, for performance, but no for security.

Thanks to this paper, we now know that power domains introduce a new attack vector: An attacker can reboot an entire SoC while keeping the internal SRAM powered. This allows a malicious OS to be booted, enabling access to secrets stored in SRAM that never lost power.

The attack works as follows: The attacker attaches a voltage probe to power the SRAM using the appropriate power domain, then reboots the rest of the system. Upon bootup, the attacker boots a malicious OS from an attached external device. Once running, the malicious OS can read the contents of the still-powered SRAM.

I hope this sparks your interest to dive into the paper. You will learn about SRAM and read about experiments demonstrating how SRAM is not susceptible to Cold Boot attacks because it loses its contents after even just a few milliseconds of power disconnection. You will then discover how voltage probes can be attached to keep SRAM powered on three different SoCs. Finally, you will learn how much SRAM can be recovered—from internal caches, internal RAM, and some CPU registers.

Like the Cold Boot paper, this work is likely to inspire a wave of research aimed at designing systems—whether in software or hardware—that protect data from SRAM-based attacks. Stay tuned; this is an exciting and important line of research.