Physical Coercion of Digital Sanctums: An Analysis of Hardware Attacks on TEEs and Architectural Resilience in the Oasis Protocol

The Paradox of Trusted Execution in Untrusted Environments

Confidential computing has emerged as a paradigm-shifting technology, promising to solve one of the most fundamental challenges in modern data processing: securing data while it is in use. At the heart of this paradigm lies the Trusted Execution Environment (TEE), a secure and isolated area within a main processor designed to protect the confidentiality and integrity of code and data from all other software on a system, including the operating system (OS) and hypervisor. Technologies such as Intel® Software Guard Extensions (SGX) and AMD’s Secure Encrypted Virtualization (SEV) provide hardware-enforced “enclaves” or secure virtual machines, creating digital sanctums where sensitive computations can occur. The core promise is profound: an application can run securely on a third-party machine, such as in a public cloud, without needing to trust the infrastructure provider. This capability is foundational for privacy-preserving smart contracts, secure multi-party computation, and protecting sensitive workloads in untrusted environments.

However, a dangerous paradox exists at the core of the TEE value proposition, stemming from a critical mismatch between the security guarantees offered by chip manufacturers and the real-world deployment models of their users. Both Intel and AMD have explicitly stated that their threat models for technologies like SGX and SEV do not extend to adversaries who have physical access to the hardware. According to the vendors, opening a server chassis and tampering with internal components is considered “out of scope”. Yet, the primary use cases driving TEE adoption, confidential cloud computing and decentralized blockchain networks, operate under the precise assumption that the physical host

is the adversary. A malicious cloud provider, a rogue data center technician, or a competing validator in a proof-of-stake network are all actors who possess or can gain the very physical access that the TEE threat model excludes.

This fundamental conflict between the vendor’s stated security boundaries and the user’s operational reality creates a systemic vulnerability. It implies that any security architecture that relies solely on the TEE’s hardware guarantees for protection against a physical adversary is built on a flawed premise. This gap is not a minor footnote in a technical manual; it is the central vulnerability that enables a devastating class of physical attacks. The recent disclosure of low-cost, highly effective hardware attacks demonstrates that this is not a theoretical concern but a practical and present danger. This report analyzes these physical attacks in technical detail, dissects the underlying architectural trade-offs in modern CPUs that make them possible, and presents a case study of the Oasis Protocol, which has engineered a multi-layered, defense-in-depth architecture designed to remain secure even in the face of TEE compromise. This analysis frames the recent attacks not as isolated “hacks” but as the predictable consequence of a foundational misalignment in security philosophy, elevating the critical importance of holistic system-level architecture over blind trust in a single hardware component.

A Taxonomy of Physical Attacks on Modern CPUs

The threat model gap has been exploited by researchers through a variety of sophisticated physical attack vectors. These attacks demonstrate that with direct hardware access, the formidable cryptographic and isolation barriers of TEEs can be systematically dismantled. This chapter dissects three distinct and highly effective physical attacks, providing a technical case study for each.

Fault Injection Attacks: The VoltPillager Case Study

Fault Injection Attacks (FIAs) are a class of active physical attacks that intentionally introduce transient errors, or “faults,” into a system’s normal operation to induce exploitable behavior. Rather than targeting a software vulnerability, FIAs target the physical properties of the integrated circuit itself. Techniques such as manipulating the CPU’s supply voltage (voltage glitching) or its clock signal (clock glitching) are remarkably low-cost and can be highly effective when an attacker has physical access to the target device.

A quintessential example of this is the VoltPillager attack. This is a hardware-based voltage glitching attack that targets the core voltage of a modern Intel CPU, allowing an attacker to induce predictable faults within a running SGX enclave. The attack is particularly notable because it successfully circumvents software-based countermeasures. Previous attacks, such as Plundervolt (CVE-2019-11157), used privileged software interfaces to undervolt the CPU. In response, Intel released microcode updates that disabled this software interface. VoltPillager, however, demonstrates the limitations of such software-only patches. A determined physical attacker can simply bypass the patched software layer and target the underlying hardware interface directly.

The methodology behind VoltPillager involves a low-cost tool, built for approximately $30 using a common Teensy microcontroller board, that connects directly to the motherboard’s Serial Voltage Identification (SVID) bus. The SVID bus is the communication channel between the CPU and the on-board Voltage Regulator (VR), which controls the CPU’s power supply. This interface is fundamental to the CPU’s power management and cannot be disabled. By injecting malicious messages onto this unprotected bus, VoltPillager grants the attacker precise, microsecond-level control over the CPU’s core voltage. By inducing carefully timed voltage drops during sensitive operations inside an SGX enclave, the attack can cause computational faults that break both confidentiality and integrity. Researchers demonstrated proof-of-concept key-recovery attacks against cryptographic algorithms and were able to fault security-critical operations by delaying memory writes, all on fully patched systems. This attack underscores a critical principle: patching a software access vector does not eliminate the vulnerability if an unprotected hardware vector to the same function remains accessible to a physical adversary.

Memory Bus Interception: The Rise of Interposer-Based Attacks

A more recent and insidious class of physical attack involves directly intercepting the high-speed communication channel between the CPU and the system’s main memory (DRAM). By physically placing a malicious device (an “interposer”)in the memory bus, an attacker can eavesdrop on or actively manipulate all data flowing to and from the TEE’s encrypted memory region.

The Battering RAM Attack

The Battering RAM attack is an active, man-in-the-middle assault on the DDR4 memory bus, executed using a custom-built hardware interposer that physically sits between a memory module (DIMM) and its socket on the motherboard. The hardware required is remarkably inexpensive, costing less than $50 to produce using off-the-shelf analog switches and a simple printed circuit board (PCB). The attack operates in two distinct phases to evade detection:

1. Stealth Mode: During system boot-up, the interposer remains completely passive and transparent. It allows all signals to pass through unmodified, ensuring that the system’s firmware and the TEE’s initialization routines can perform their trust checks and establish memory encryption keys without detecting any anomaly.
2. Malicious Mode: Once the system is running, the attacker can flip a switch to activate the interposer’s malicious logic. In this mode, it actively manipulates signals on the memory bus to silently redirect physical addresses. It can create a “memory alias,” making a protected memory page belonging to an SGX enclave or an AMD SEV-SNP virtual machine appear to have the same physical address as a memory page controlled by the attacker.

This address aliasing capability enables devastating replay attacks. The attacker can first capture the encrypted data (ciphertext) being written to a protected memory location. Later, they can “replay” this captured ciphertext into their own malicious enclave. The CPU, tricked by the address alias, will then use the victim’s keys to decrypt the data within the attacker’s enclave, granting the attacker arbitrary read and write access to the victim’s plaintext secrets. This technique completely shatters the confidentiality and integrity guarantees of both Intel SGX and AMD SEV-SNP. Critically, the attack exploits a fundamental design choice in modern,

scalable TEE memory encryption schemes, which, for performance reasons, omit certain cryptographic freshness and integrity checks.

The Wiretap Attack

The Wiretap attack is a passive variation of the memory bus interception technique, also utilizing a DIMM interposer on the DDR4 bus. Unlike Battering RAM, its goal is not to actively modify data but to passively eavesdrop on memory traffic to extract a single, catastrophic secret: the SGX attestation key. The hardware for Wiretap is more sophisticated and costly than that for Battering RAM, requiring a logic analyzer and other electronics that total around $1,000.

The interposer passively “wiretaps” the bus, capturing a complete trace of the memory traffic. By analyzing this captured data, the attacker can exploit the predictable, deterministic patterns in Intel’s memory encryption algorithm to reconstruct the machine’s unique DCAP (Data Center Attestation Primitives) attestation key. The theft of this key represents a total failure of the SGX trust model. Remote attestation is the cornerstone of SGX’s security, allowing a remote party to cryptographically verify that a specific application is running inside a genuine, untampered SGX enclave on a legitimate, up-to-date platform. With the stolen key, an attacker can forge attestation reports (“quotes”), making any malicious software appear to be a legitimate, secure enclave. This completely undermines the root of trust for any system that relies on SGX attestation, including numerous confidential blockchain networks like Phala, Secret, and Crust, which were shown to be vulnerable.

The success of both Battering RAM and Wiretap reveals a critical, performance-driven design decision in modern TEEs. The desire to make TEEs viable for large-scale data center workloads, which require protecting vast amounts of memory, directly led to the adoption of scalable memory encryption designs. This architectural choice, however, introduced a new and severe physical attack surface by trading away some cryptographic robustness for performance and scale.

Comparative Analysis of Physical TEE Attacks

The following table provides a structured comparison of the analyzed attacks, highlighting their distinct methodologies, costs, targets, and ultimate impact on TEE security.

Feature	VoltPillager	Battering RAM	Wiretap
Attack Vector	Active Fault Injection (Voltage Glitching)	Active Memory Bus Interception (Address Aliasing)	Passive Memory Bus Interception (Eavesdropping)
Hardware	~$30 Teensy Microcontroller	~$50 Custom DDR4 Interposer	~$1,000 Interposer + Logic Analyzer
Required Access	Physical access to motherboard SVID bus	Physical access to DIMM slots	Physical access to DIMM slots
Target Tech.	Intel SGX	Intel SGX, AMD SEV-SNP (with scalable memory encryption)	Intel SGX (with deterministic memory encryption)
Primary Impact	Breach of Confidentiality & Integrity (via faults)	Breach of Confidentiality & Integrity (via replay)	Catastrophic breach of Attestation (Key Theft)
Vulnerability	Unprotected hardware power management interface (SVID)	Lack of cryptographic freshness/integrity in scalable memory encryption	Deterministic patterns in scalable memory encryption

Architectural Vulnerabilities in TEE Memory Encryption

The efficacy of the Battering RAM and Wiretap attacks is not due to a simple bug but rather a consequence of a fundamental architectural trade-off made in the design of modern TEEs. To understand this, it is necessary to examine the evolution of TEE memory encryption technology and the tension between security and performance at scale.

The Scalability vs. Security Trade-Off

To support confidential computing in cloud and data center environments, where applications may require hundreds of gigabytes or even terabytes of protected memory, chip manufacturers developed “scalable” memory encryption engines. Technologies like Intel’s Total Memory Encryption – Multi-Key (TME-MK) and AMD’s Secure Memory Encryption (SME) are designed to encrypt the entire system memory with minimal performance overhead. To achieve this efficiency, these systems often employ deterministic encryption schemes. In such a scheme, a given block of plaintext at a specific physical address will always encrypt to the same block of ciphertext. This is typically achieved using a counter-mode cipher where the counter is derived from the physical address.

While this approach is extremely fast, it comes at a significant cryptographic cost. It lacks semantic security, and more importantly, it offers no inherent protection against replay attacks. The system’s security relies entirely on the assumption that an attacker cannot control or alias physical memory addresses. The Battering RAM attack demonstrates that this assumption is false for a physical adversary. By using an interposer to manipulate the address bus, an attacker can make two different memory locations appear to have the same address from the CPU’s perspective, allowing them to capture ciphertext from one location and replay it to another, thereby breaking the encryption. This vulnerability is a direct consequence of the decision to omit per-block cryptographic integrity and freshness metadata (like a MAC or nonce) in favor of achieving higher performance and supporting larger protected memory sizes.

Contrast with Intel SGX v1 Architecture

This modern, scalable approach stands in contrast to the memory encryption model used in the original Intel SGX architecture (SGX v1). While the precise implementation details of SGX v1’s Memory Encryption Engine (MEE) are proprietary, its design was architecturally different. It was built around a limited, protected region of memory called the Enclave Page Cache (EPC), which was typically restricted to a small size (e.g., 128 MB or 256 MB). This limited scalability made SGX v1 less suitable for large data-intensive applications, but its memory protection model was more robust against the types of physical manipulation exploited by Battering RAM and Wiretap.

The Oasis Protocol’s security team explicitly notes that their most critical infrastructure runs on SGX v1 technology, which utilizes a “fundamentally different memory encryption design that is unaffected by these attacks”. This indicates that the earlier, less scalable architecture likely incorporated stronger integrity protections that are absent in the newer, performance-optimized designs. The evolution from SGX v1 to Scalable SGX, therefore, was not a simple linear improvement but a path of design trade-offs. The industry’s push toward enterprise and cloud scale introduced new vulnerabilities that did not exist in the original, more constrained model. This context is crucial for understanding the rationale behind Oasis’s architectural choices, which appear to be a deliberate, risk-mitigating decision to favor a stronger, albeit less scalable, hardware security model for the most security-critical components of the network.

Mitigation Through Architectural Resilience: The Oasis Protocol Case Study

In the face of potent physical attacks that undermine the core hardware guarantees of TEEs, a new security paradigm is required, one that does not place blind faith in a single hardware component. The Oasis Protocol provides a compelling case study in building such a system. Its architecture is founded on the principle of “defense-in-depth,” layering multiple, independent security mechanisms to create a resilient system that can withstand the failure of any single component, including the TEE itself.

Beyond the Enclave: A Defense-in-Depth Philosophy

The Oasis Network’s architecture is modular, separating the proof-of-stake consensus layer from the execution layer, which consists of multiple parallel runtimes known as ParaTimes. Confidential ParaTimes, such as Sapphire (EVM-compatible) and Cipher, leverage TEEs to enable privacy-preserving smart contracts. The network’s core security philosophy, however, is to treat the TEE as just one of many defensive layers. The system is explicitly designed such that compromising a TEE on a node is insufficient to compromise the security of the network or the confidentiality of user data. This is achieved by integrating security into the protocol’s governance, economic, and cryptographic structures.

On-Chain and Economic Defenses: Raising the Cost of Attack

Oasis effectively leverages the native properties of blockchain technology to create powerful security layers that are entirely independent of the TEE hardware. This transforms the security problem from a purely technical one, which might be solved with a $50 interposer, into a complex socio-economic challenge that is orders of magnitude more difficult and expensive for an attacker to overcome.

• Governance-Gated Access: In a naive TEE-based system, a successful remote attestation might be sufficient to grant a node access to sensitive keys or committees. This is a fragile model, as demonstrated by the Wiretap attack which allows attestation forgery. In the Oasis Network, TEE attestation is merely a prerequisite. To join a highly sensitive committee, such as the one managing the network’s distributed key manager, a node operator must first be approved through a formal, on-chain governance vote.¹⁶ This shifts a critical access control decision from an automated, forgeable hardware check to a decentralized, human-in-the-loop process that is far more resistant to technical exploits.
• High Economic Staking Requirements: To be eligible to join a confidential ParaTime committee, a prospective node operator must also be a registered validator and have a significant economic stake in the network. For instance, joining the Sapphire ParaTime committee requires a stake of at least 5 million ROSE tokens. This creates a massive economic barrier to entry. Even if an attacker were to steal an attestation key using the Wiretap attack, they could not use it to join the committee and steal user data unless they were also willing and able to acquire and lock up millions of dollars worth of cryptocurrency. This stake acts as a security bond that would be slashed if the node were to act maliciously, making such an attack economically irrational for all but the most well-funded and determined adversaries.

Cryptographic and Protocol-Level Defenses

Beyond economic and governance controls, the Oasis Protocol implements cryptographic best practices to minimize the impact of a potential breach.

• Ephemeral Keys and Forward Secrecy: When clients submit transactions to a confidential ParaTime, the data is encrypted using ephemeral keys that are rotated frequently, typically with every epoch. This ensures forward secrecy. Even if an attacker were to mount a successful physical attack and extract the
  current set of decryption keys from a node’s TEE, they would be unable to decrypt any past transactions, as the keys used for those transactions have been securely erased and no longer exist. This dramatically limits the temporal scope and potential damage of a successful compromise.
• Distributed Key Management: The network’s key manager, which is responsible for managing the keys used to encrypt smart contract state, is not a centralized entity. It is a distributed service that runs across a committee of TEE-enabled nodes. Policies that govern access to key material must be signed by a threshold of the committee members. This distributed trust model prevents a single compromised node from unilaterally releasing keys or altering access control policies, requiring an attacker to compromise a significant fraction of the committee simultaneously.

Hardware-Specific Defenses and Policies

Finally, while Oasis’s architecture is designed not to over-rely on the TEE, it still employs intelligent, hardware-specific strategies to harden this layer of defense.

• Strategic Selection of Intel SGX v1: As established in Chapter 2, the most direct and effective mitigation against the Battering RAM and Wiretap attacks is the deliberate selection of hardware that is not vulnerable. The Oasis Network’s most critical components, including the key manager and the Sapphire runtime, are built on the older Intel SGX v1 technology. This architecture’s memory encryption design is fundamentally different from the newer, scalable models and is not susceptible to the same address aliasing and replay attacks. This represents a conscious and sophisticated architectural decision to prioritize security robustness and a proven hardware foundation over raw performance and scalability for the network’s most vital functions.
• Adaptive CPU Blacklisting: The network maintains a dynamic, on-chain registry of CPU models and microcode versions that are known to be vulnerable to specific attacks. Nodes are required to periodically refresh their TEE attestations with the network. If a node’s attestation report indicates that it is running on blacklisted or outdated hardware or firmware, it is automatically deemed ineligible to participate in confidential ParaTime committees and is ejected if it is already a member. This mechanism allows the decentralized network to respond rapidly to new vulnerability disclosures and enforce security updates across all node operators without requiring a centralized mandate or a disruptive network-wide upgrade.

Redefining the TEE Threat Model for Decentralized Systems

The emergence of low-cost, effective, and publicly documented physical attacks like VoltPillager, Battering RAM, and Wiretap has irrevocably shattered the simplistic view of Trusted Execution Environments as impenetrable digital fortresses. These attacks have proven that the foundational threat model mismatch, whereby hardware vendors exclude physical access from their security guarantees while key deployment scenarios depend on protection against it, is not a theoretical edge case but a practical and exploitable reality. The promise of running a secure computation on an untrusted host cannot be fulfilled by the TEE in isolation when the host is a determined physical adversary.

The Oasis Protocol’s multi-layered, defense-in-depth architecture, however, provides a powerful and pragmatic blueprint for building resilient confidential systems in this new reality. Its security model is predicated on a “zero-trust” posture toward the underlying hardware, assuming that the TEE itself can and will be compromised. By weaving security into every layer of the stack, Oasis demonstrates how to build a system that remains secure even if its foundational hardware layer fails. The protocol’s resilience stems not from a single component, but from the holistic integration of:

• Economic Security: Using high staking requirements to make attacks economically irrational.
• Decentralized Governance: Employing on-chain voting as a human-in-the-loop access control mechanism that is immune to technical forgery.
• Cryptographic Prudence: Implementing forward secrecy with ephemeral keys to limit the impact of any potential breach.
• Risk-Aware Hardware Selection: Deliberately choosing older, more robust hardware (SGX v1) for critical components, prioritizing security over scalability.

Ultimately, the Oasis model shows that the future of confidential computing, particularly in high-stakes decentralized environments, depends on architectural resilience. The ultimate security guarantee cannot be outsourced to a single hardware vendor; it must be engineered into the system’s core economic, cryptographic, and governance logic. This approach provides a robust path forward, enabling the development of truly secure and private applications in an inherently untrusted world.

The Oasis Challenge

Calling all security researchers, developers, and white hats! The Oasis Network is committed to building the most secure confidential computing ecosystem, and we invite you to contribute. You can get involved through our active bug bounty program or by taking on our latest security challenge.

Ready to test your skills? Explore the new challenge here: https://x.com/OasisProtocol/status/1974580942225440997