1 Introduction An increasingly connected world makes us dependent on computing devices that handle a wide range of security- and privacy-critical operations. We use smartphones and watches to manage bank transactions and store biometric information. On the industrial and government side, embedded devices monitor remote system operations and feed data critical to industrial processes and national defense. Physical access to these devices leads to a wide range of security exploits, including impersonation, proprietary software cloning, and infiltration and exploitation of industrial and defense infrastructures. A standard approach to prevent data theft from a system’s non-volatile memory (NVM) is to enforce full-disk encryption methods, such as BitLocker and VeraCrypt. These encryption methods protect data using a password or PIN so that even if a device is lost or stolen, NVM remains inaccessible to an attacker. Disk encryption changed the attackers’ focus on other types of memories, such as DRAM. Halderman et al. show how an attacker gains access to a disk encryption key by cold booting a system and dumping its main memory.10 In this attack, the authors use low temperature ( – 50 ∘ C ) to ‘freeze’ the data in DRAM cells so that even if the memory is out of power for a short time, it retains its logic states. Once ‘frozen’, an attacker physically removes and inserts the victim DRAM in another machine to run forensics on the dumped memory image. While this attack is practical for larger devices where DRAM is removable (for example, laptops), it poses a few technical challenges for mobile and other embedded devices. In an embedded device, memory chips and processors are soldered on the pc boards (PCBs), making it difficult to remove them from a system. FROST17 overcomes this challenge by allowing device reset to factory default—preserving DRAM’s content while the device boots from another media. To defend devices from cold boot attacks, researchers have proposed numerous methods where sensitive code and data remain encrypted in on-chip memory; decryption occurs only in the on-chip memories such as caches.16,26 Since systems-on-a-chip (SoCs) already contain large enough on-chip storage to hold keys and cryptographic states, executing software on the memory requires no additional hardware. For example, TRESOR uses x86 debug registers to store sensitive AES states without leaking security-critical information to off-chip memory.16 Researchers extend this idea to ARM devices, where the CPU fetches the encrypted software and data to the on-chip memories before decryption and execution.6,7,8,9,23,26 These works advocate fully on-chip execution for cryptographic operations because attacking a processor’s internal memory is expensive and demands sophisticated attack methods, such as decapsulation. This article evaluates the security of on-chip computation schemes, specifically under the cold boot attack model and empirically shows that these methods are secure from the traditional cold boot attack.10 On-chip memories, primarily SRAM, are integrated directly into the processor die, offering greater security against physical attacks (for example, probing attacks11,26) compared to off-chip memories. Research shows that SRAM can partially retain data for a few milliseconds under extremely low temperatures (below – 110 ∘ C ).1 However, achieving such temperatures poses significant challenges, risks damaging components such as the battery, and requires specialized equipment. Additionally, exploiting SRAM in embedded devices typically necessitates a physical power disconnect, which far exceeds SRAM’s brief data retention time. This article introduces Volt Boot, a method for executing physical memory disclosure attacks on on-chip SRAM memories by exploiting SoCs’ power domain separation. These domains operate at specific voltages, managed by components such as PMICs, capacitors, and inductors, to balance performance and power efficiency. We demonstrate that traditional cold-boot-style attacks, which leverage low-temperature-induced data retention, are ineffective on embedded SRAM (§Section 3). We uncover a new attack vector that exploits power domain separation of modern SoCs and show that such architectural design choices can be weaponized for leaking fully on-chip security-critical information(§Section 4). Using three commercially available Cortex-A profile devices, we demonstrate the attack by retrieving data from caches (§Section 6.1), CPU registers (§Section 6.2), and iRAMs (§Section 6.3). Provided that an application runs from internal memory (for example, cache) undisturbed by operating system’s background process, we retrieve memory image with 100% accuracy. Finally, we analyze the trade-offs involved in potential countermeasures (§Section 7)
2 Background On-chip SRAM: Static random access memory (SRAM) is the building block of temporary on-chip storage, such as caches, iRAM, registers, translation lookaside buffers (TLBs), and branch target buffers (BTBs), making them one of the most common type of memory in modern computing devices. Figure 1 illustrates a typical SRAM cell, which is composed of two inverters in a positive feedback configuration to store one bit of data. Transistors N1 and N2 provide access to the data bit (Q) and its complement ( ∼ Q), respectively. Unless a processor executes a read/write command, Word Line remains de-asserted with data stored in the cross-coupled structure formed by inverters. Figure 1. Schematic diagram of a typical SRAM cell. Unlike other types of memory, direct access (that is, direct software read/write) to many types of on-chip SRAM (for example, instruction cache) is uncommon in typical processors. However, most architectures provide access to these internal memories through various methods to debug low-level memory errors; ARM provides co-processor instructions in ARMv8 architecture, while RISC-V processors22 allow memory-mapped access. For a more concrete example, the Cortex-A72 processor offers access to 15 distinct internal RAMs—including caches, TLBs, and BTBs—via its cp15 co-processor interface. Fully on-chip computation: Storing plain-text security-critical information in a DRAM is unsafe, motivating both industry and academic research to push for safer off-chip memory management schemes. Since Intel’s 6th generation, all subsequent processors are able to obfuscate data in the DDR3 and DDR4 DRAMs using session keys and pseudo-random numbers.15,25 For devices without inline encryption, researchers propose fully SoC-bound computations where sensitive information never leaves a chip’s physical boundary. In most cases, it is unnecessary to encrypt and decrypt every memory-bound transaction as software can store intermediate states in on-chip memories as plain text. This idea inspired numerous on-chip computation methods. Sentry7 and Copker9 uses iRAMs and caches as temporary memory to avoid exposing secrets to DRAM. Cache-assisted secure execution (CaSe) extends this idea by adding Trust-Zone support to a partially locked cache. The processor fetches encrypted software from main memory and stores it in a locked cache as plain text. From this point, the plain-text data/code remains in the cache for the duration of execution. Similarly, TRESOR,16 PRIME,8 and Security Through Amnesia23 use on-chip registers (for example, debug) to implement cryptographic algorithms on-chip. These methods essentially emulate a microcontroller’s behavior in an application processor and reduce the attack surface to the border of the chip itself. Given no plain-text data is released off-chip, these methods provide strong security against the most sophisticated physical memory disclosure attacks, for example, cold boot. Power domain separation. SoCs integrate numerous circuit blocks, each exhibiting unique analog characteristics. To meet stringent performance and power efficiency requirements, these blocks are divided into separate voltage domains. The power management unit (PMU) within the SoC dynamically manages the voltage levels for these domains at runtime, tailoring them to the workload of each domain. In modern, complex SoCs, dozens of off-chip supply pins connect to various power domains, enabling precise control over analog circuit behavior. This setup mitigates challenges such as ground bounce, power-supply noise, and per-pin current limitations. We broadly categorize the power-supply domains of an SoC into three main areas, as illustrated in Figure 2: Core power domain: The processing elements are in this domain. For example, the ARM cluster in a multi-core SoC draws power from the core supply voltage domain. Apart from computing elements such as CPU extensions and GPUs, this domain supplies power to L1 caches and their associated control circuitry.
Memory power domain: This domain supplies power to the memories and their associated peripherals. Most SoCs manage main memory, non-volatile memory (for example, Flash), and L2/L3 caches with this power domain.
I/O power domain: Power for the I/O controllers and external peripherals is drawn from this domain. Figure 2. A simplified block diagram of an SoC’s power domains. The PMIC is an external component that maintains a specific voltage level at each power-domain supply pin. SoC designers subdivide power domains into smaller logical blocks that allow fine-grain control of the different components within an SoC. For example, some processors allow powering down individual cache components in its L1 memory domain through software.3 The domains are separated using power gating to balance energy consumption and performance of independent blocks at startup and runtime.
3 Cold Booting On-Chip SRAM Is Ineffective In the absence of refresh, a DRAM cell’s data-retention time depends on the time it takes for capacitors to leak enough charge to alter the digital value sensed. Temperature affects DRAM cell discharge rate; lower temperatures increase data retention time. Reducing the temperature of a memory device keeps the data in the memory for a short period even if the power is turned off, which is the fundamental idea behind the cold boot attack.10 Both DRAM and SRAM partially retain their data across power cycles for a short time when the temperature is reduced below a certain level1,2,10 due to their intrinsic capacitance (although DRAM has much longer retention time). We discuss the technical hurdles that prevent a cold boot attack on SRAM as follows: SRAM’s placement: On-chip SRAMs are tightly coupled with processing cores and are built into the processor die itself. Such placement of SRAM makes it inaccessible given the traditional physical attacker threat model. The embedded nature of SRAMs complicates the cooling process as well because an attacker needs to freeze the entire device. Cold booting this memory requires extreme low temperature and risks bricking of the system. Short retention time: We cannot launch a cold boot attack on embedded memories by resetting a device through software because a system easily prevents such attempts by purging residual memories as part of a core’s power down sequence.5 Disconnecting the power from a device is the only reliable way to prevent the system from executing any residual memory-purging routines. An abrupt power disconnect from a device while executing critical security operations ensures target information remains in SRAM. To power cycle an embedded device, we must manually disconnect its power supply (for example, the battery). As the literature suggests, SRAM retains information for only a few milliseconds—even under extremely cold conditions, which is insufficient to execute a reboot by manually disconnecting power from a device.17 Effect of low temperature: Typically, systems turn off when the operating temperature crosses a certain threshold set by the manufacturers. Executing a cold boot attack on SRAM requires extremely low temperature (below – 110 ∘ ),1 which is far beyond the operating limit of most devices. We reproduced a similar attack as FROST17 in cache memory (SRAM, as opposed to the DRAM targeted in the original attack) of a Raspberry Pi 4 (a quad-core cortex-A72 device) to study cold temperature data retention of its embedded SRAM.3 We load bare-metal software to populate both the d-cache and i-cache of each core and extract the cached data in a binary image. Then the device undergoes static cooling in a TestEquity thermal chamber for an hour to stabilize the core temperature. We power cycle the device for a few milliseconds and extract the cache data to compare it to previously stored binaries. Table 1 lists the mean mismatch between post-reboot retrieved cache and pre-stored binary for each core at different temperatures. The information retrieval errors indicate almost no data retention even at – 40 ∘ C . Note SRAMs boot up into random states where approximately 50% of the bits are 1s. Temperature 0 ∘ C – 5 ∘ C – 40 ∘ C Recommended Min. SoC’s hard limit Error 50.14% 50.06% 50.39%
4 Volt Boot Volt Boot is an attack that exploits an SoC’s power domain separation to induce cross-power-cycle data retention in embedded SRAM. In this section, we show circuit design choices made for power and performance reasons lead to a new cold-boot-style attack, but with increased precision and fewer requirements than traditional low-temperature-based data retention attacks. 4.1 Threat model. Our threat model is based on the cold boot attack10 where an attacker has physical access to a device. The most significant modifications to the original cold boot threat model are the location and type of the memory. Our target is SRAM embedded within the core of a device, which prevents direct access to the memory contents without damaging the chip. Then the attacker boots the victim device from a media, for example, boot ROM or USB, to dump the uninitialized volatile memory image. This threat model is consistent with the threat model presented in the FROST,17 Sentry,7 and CaSE26 systems. These papers consider an adversary capable of capturing a device (that is, lost or stolen) that is protected against memory disclosure attacks using a lock screen and off-chip memory encryption. Our threat model extends to headless embedded devices that collect, store, and transfer sensitive information in an unsupervised environment. Note that a number of system-protection methods exist where devices are permanently locked from programming or software updates. The behavior of such devices resembles an application-specific IC (ASIC), and we consider these systems out of the scope of our threat model. 4.2 Inducing data retention. SoCs need external pins to supply specific voltage to optimize performance and efficiently use energy under fluctuating loads. Usually, a PMIC supplies power to each domain in a particular order to bring up the board from reset. Figure 3 illustrates how a typical PMIC is used to drive an SoC. Generally, LDOs supply power to the domains where voltage fluctuation is limited, whereas domains with high load fluctuation (and dynamic voltage and frequency scaling) use switching regulators to save energy from heat loss. When a power domain of an SoC draws a large current under the demand of software/hardware, the parasitic inductance of the board and the package drop the voltage at the supply lines; this is called droop. To counter droop, the supply voltage pins are extended out of the SoC to connect capacitors so that they ‘absorb’ the current surge, keeping supply voltage closer to nominal. Regardless of the type of regulator used in a power domain, the pins connected to the PMIC require passive components to filter out noise generated during load fluctuation. Figure 3. Typical power supply system. The LC combination supply lines are for switching regulators, whereas the decoupling capacitor filters out noise during fluctuating load driven by LDOs. Each power domain is power-gated to allow independent control at startup and run-time. Our observation is that if we externally maintain a steady voltage to the pin that supplies power to a target memory domain, it retains SRAM data—even while the rest of the system undergoes a power cycle. We maintain the domain voltage level from an external voltage probe while disconnecting the main supply line to the PMIC. That is, Volt Boot artificially creates SRAM data retention across a power cycle using a voltage probe in a PCB’s test pad or bare passive component’s lead that is connected to a target memory domain. As discussed in Section Section 3, cold booting is an impractical way of attacking on-chip SRAM. Even if it is possible to retain information across power cycles, the extracted data is erroneous because SRAM’s charge leakage follows a normal distribution, and so some cells will lose their data even for a short power disconnect.19 Note that SRAM cells are bistable, which makes it harder to look for keys using the algorithm proposed in the original cold boot attack.10 Since our attack involves no other physical variables (for example, temperature) and memory discharge rate, manufacturing technology node is irrelevant. 4.3 Attack enablers. While power domain separation serves as the basis for our attack, a combined effect of multiple aspects and attributes of a system enables Volt Boot. We identify each attack enablers as follows: Ubiquity of SRAM: SRAM is available in every computing device, ranging from resource-constrained microcontrollers to server-class processors. We can induce artificial SRAM state retention in any SoC that has separate SRAM and compute core power domains. Internal RAMs store data in plain-text: As mentioned in Section Section 2, cryptography application developers consider on-chip memories safer compared to external memories. As a result, unlike external DRAMs, scrambling or encrypting SRAM’s data is uncommon in commodity processors. Thus, access to data residing in on-chip SRAM guarantees a plain-text version of the information, even if external memories implement scrambling or encryption. Domain-specific exposed power-supply pins: As discussed, performance, energy efficiency, and die area reduction are the primary reasons to expose domain-specific voltage pins out of an SoC; some of these pins are connected to the embedded SRAM. By construction, data remains error-free in SRAM as long as its supply voltage remains above its data-retention voltage. Note, this voltage is well below the nominal supply voltage of the power domain the cells are connoted to. The power domain separation through power-gating methods and dedicated pins exposed from the SoCs let us shut down the entire system while the small portion that holds sensitive data ‘alive.’ No default RAM reset hardware: SRAM stays at an uninitialized state after booting-up because of two main reasons: First, some SRAMs are large (>1MB) compared to the other on-chip resources, and resetting such large memory by iterating over the entire address (usually line by line for caches) space reduces boot speed significantly. Second, SRAM’s startup state has numerous security applications, such as PUF21 and TRNG.12 Note that cleaning and invalidating a cache at the boot phase does not erase the contents; these operations set the invalid bits to prevent a cache hit, but the data remains unchanged. The co-processor interface still allows reading out the cache contents from a proper exception level ( EL3 for ARM devices). Therefore, initializing cache lines using a software interface is currently the only means to reset the power-on state of L1 caches, which needs the execution of DC ZVA instructions for every line.3,4 The purpose of this instruction is to allow initializing a large block of memory in the cache for a particular data structure without writing zeros in the external memories. Note cleaning/invalidation instructions apply to both instruction and data caches, but resetting instructions are exclusive to d-caches.
5 Attack Evaluation An SoC’s domain-separated power management architecture allows us to supply voltage to a target memory through exposed pins and keep part of the chip active (that is, retaining state) while the rest of the system resets. The actual method used to access embedded SRAM varies depending on the targeted SoC, but devices’ power-supply methods are very similar at a high level. We evaluate Volt Boot using ARM devices from different vendors, and to explore the generality of the attack, we choose devices that span a broad range of applications. For example, Raspberry Pis represents a wide array of systems, ranging from embedded devices common in IoT applications to systems capable of running a full-fledged operating system. To expand the targeted memory types, we include an SoC designed for multimedia applications, because it contains large memory-mapped SRAM (that is, iRAM). Table 2 lists the specification of the evaluation platforms. The SoCs in these systems draw power from three different power-management devices, and we observe similar circuit design choices for the off-chip passive components (see Figure 3). System on Chip CPU core Board SRAM Manufacturer BCM2711 Quad-core Cortex-A72 Raspberry pi 4 Model B L1I: 48KB, L1D: 32KB, L2: 1MB Broadcom BCM2837 Quad-core Cortex-A53 Raspberry pi 3 Model B L1I: 32KB, L1D: 32KB, L2: 512KB i.MX535 Cortex-A8 i.MX53 Evaluation board L1I:32KB, L1D: 32KB, L2: 256KB, iRAM: 128KB NXP We use a bench power supply with a current-driving capability of more than 3A to ensure stable voltage delivery to the target power domain of the SoC. Although attaching a probe at the same voltage level typically draws only a few milliamps, a sudden disconnection of the compute core supply line from the PMIC causes a momentary current surge in the target power domain. This surge can lead to a voltage drop below the SRAM’s data-retention threshold (§Section 2), resulting in errors in the extracted data. Consequently, a power supply capable of providing sufficient current is crucial, especially when the target memory domain also powers the CPU core(s). 5.1 Attack execution steps. In this section, we discuss how to execute an attack on SoCs (see Figure 4 for summary). Identifying target domains and their associated pins: To target a device, the first step is identifying the pins supplying power to the SRAM. Directly locating these pins on an SoC is often impractical due to advanced packaging, such as BGA. However, exact pins are not necessary, as supply pins connect to nearby passive components (for example, decoupling capacitors) or test pads, typically near the PMIC. Their layout generally follows a standard pattern (see Figure 3). For our evaluation platforms, Table 3 lists the test points and pin names, with visual representations in Figure 5.
Attaching a voltage probe: We measure the nominal voltage at the target pin(s) and connect an external power supply at the same level. The power source must provide sufficient current to maintain the voltage when the device’s main power is off, preventing data loss. For example, a Raspberry Pi 4 draws 400–600mA through test pad TP15 with an 800mV probe, depending on workload. When the main supply is disconnected, the cores draw power from the probe, which keeps the voltage constant even during high momentary current demand. After a few microseconds, current drops to 8mA, and the memory remains in retention state indefinitely.
Power cycling and booting the system: Once the external probe is in place, we disconnect the device from the main power source while our voltage probe keeps the target SRAM in its data retention state. Systems vary in boot-up methods after power down—some require user data erasure to boot from alternative media, while others boot internally without external media. We emulate this by booting Raspberry Pis from USB storage and use a post-reboot data-extraction program to: (A) Reduce contamination on the SRAM’s retained data during boot-up by avoiding storing data to it (either explicitly or implicitly). (B) Exfiltrate data from the SRAM to other memory (for example, Flash, DRAM, or a debugger) for post-processing. The cache extraction software uses CP15 instructions to read cache data into general-purpose registers. For out-of-order processors, data ( DSB SY ) and instruction ( ISB ) synchronization barriers must follow cache access instructions, such as the Cortex-A72’s SYS #0, c15, c4, #0,
Analyzing the memory contents: The attacker must tailor post-processing strategies based on the target SRAM and their objectives. Volt Boot reads memory without errors, but noise in the extracted data can arise from the dynamic behavior of the software (in cache) during an attack. For instance, extracting cryptographic keys from cache memory with precision depends heavily on the workload of the processing core and the influence of background processes. Figure 4. Executing Volt Boot attack. Boards PCB Test Pads to Probe Nominal Voltage Target Memories Power Domains Raspberry Pi 3 PP58 1.2V L1D, L1I, registers Core (VDD_CORE) Raspberry Pi 4 TP15 0.8V L1D, L1I, registers Core (VDD_CORE) i.MX53 SH13 1.3V iRAM Memory (VDDAL1) Figure 5. Pictures of our evaluation platforms (a) Raspberry Pi 4, (b) Raspberry Pi 3, and (c) i.MX535, showing the test points we attach our voltage probe to. 5.2 Attacker accessible memory area. At startup, the CPU uses part of the embedded SRAM before even an attacker has access to those memories. What percentage of memory is available after SoC boot-up depends on the target memory type of an SoC. To find the accessible proportion of the SRAM, we execute bare-metal software that populates a target memory with predefined patterns. The bare-metal setup allows us to calculate the effect of the CPU’s boot phase on internal memories, avoiding dynamic behavior, such as cache eviction. Once the software loads the data/instruction in the target memory, we execute the steps discussed above. Our experiments on the L1 caches of the BCM2711 and BCM2837 show no clobbering during the initial boot phase, consistent with the fact that L1 caches in these SoCs are software-enabled. This allows an attacker to avoid activating the cache, thereby accessing its full contents. In contrast, these Broadcom devices feature a built-in video core that shares the L2 cache with the ARM CPU cores. During startup, the video core uses pre-compiled binaries for system initialization, overwriting L2 cache contents and preventing any post-reboot data recovery. The i.MX535 has similar behavior for caches, but boot ROM uses part of the iRAM as scratchpad memory before initializing the DRAM controllers. That is, the CPU resets part of iRAM before allowing any debug connection or software execution. Such a boot method is standard among Cortex-M devices; they clobber 2 K B SRAM (main memory) at the boot phase.14,24 Our experiments show that approximately 95% of an i.MX535’s iRAM is exposed to Volt Boot.
... continue reading