Obelix: Mitigating Side-Channels through Dynamic Obfuscation

Obelix: Mitigating Side-Channels through Dynamic Obfuscation

Speakers: Jan Wichelmann, Anja Rabich, Anna Pätschke, Thomas Eisenbarth

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=4PhNFozCuNM

Overview

This talk introduces Obelix, a novel software-based, drop-in countermeasure designed to mitigate a broad spectrum of side-channel attacks against workloads running within Trusted Execution Environments (TEEs). Presented by Jan Wichelmann from the University of Lübeck, the research addresses a critical vulnerability in the security model of TEEs: despite hardware-enforced isolation and memory encryption, these environments remain susceptible to information leakage through observable side channels. Obelix aims to provide a comprehensive solution by employing a dynamic obfuscation engine that conceals both control flow and data flow patterns.

The significance of Obelix lies in its ambition to offer a single, unified software solution for a problem traditionally tackled with ad-hoc, attack-specific, or hardware-dependent countermeasures. By transforming programs in an oblivious manner through compiler extensions, Obelix enables developers to deploy hardened applications without requiring deep expertise in side-channel resistant coding practices. This work is crucial for enhancing the practical security of TEEs in cloud computing and other untrusted environments, where the confidentiality of proprietary algorithms and sensitive data is paramount.

Background

▶ Watch: Introduction to Obelix and Trusted Execution Environments (TEEs) (0:00)

Trusted Execution Environments (TEEs), such as Intel SGX or ARM TrustZone, were introduced by processor vendors to protect sensitive workloads executing on untrusted platforms, like third-party cloud machines. The core premise of TEEs is to provide a hardware-enforced isolation layer around an application, shielding it from privileged attackers, including the cloud provider itself. This isolation is primarily achieved through mechanisms like memory encryption, which prevents unauthorized access to code and data, and remote attestation, which allows users to verify the integrity of their workload before deploying secrets.

However, the promise of TEEs for absolute confidentiality has been significantly undermined by the proliferation of side-channel attacks. These attacks exploit unintentional information leakage from the system's physical implementation rather than flaws in cryptographic algorithms or direct memory access. The talk highlights two prominent categories of side-channel attacks that TEEs fail to fully address:

1. Memory Access Pattern Leakage: Even with memory encryption, an attacker can observe which memory locations or pages are being accessed. For instance, if a program accesses "ingredient A" on "shelf one" and then "ingredient B" on "shelf two," the attacker learns the access pattern, even if the contents of the shelves are encrypted. This pattern can reveal sensitive information, such as accesses to lookup tables in cryptographic implementations, which has been historically exploited in numerous cache attacks to break cryptographic keys. Existing countermeasures often require writing constant-time code, a highly manual and error-prone process that is impractical for most developers.

1. Single-Stepping Attacks: TEEs operate under a strong attacker model where the adversary can interrupt the execution environment with high precision. An attacker can program a timer to interrupt the TEE after every single instruction, effectively "single-stepping" through the program. During each step, the attacker can precisely measure the instruction's latency and any associated memory accesses. By observing the unique latency pattern of different instructions (e.g., a fast register operation versus a slow memory access), the attacker can reconstruct the program's control flow, identify memory access points, and ultimately infer the underlying algorithm or "secret recipe." This level of leakage severely compromises the confidentiality of proprietary code.

The speaker emphasizes that current countermeasures for TEEs are typically fragmented: some target single-stepping, others cache attacks, and most are either hardware-specific, incompatible, or demand significant manual effort. There is a notable absence of a robust, general-purpose, software-based solution that can comprehensively address multiple side-channel attack classes with minimal developer overhead. This gap forms the primary motivation for the Obelix project, seeking to provide a unified, drop-in mechanism for TEE side-channel protection.

Key Findings

▶ Watch: Side-channel attacks: Single-stepping and instruction latency leakage (3:00)

The core contribution of Obelix is its demonstration that a significant number of diverse side-channel attacks against TEEs can be mitigated through a single, software-based, dynamic obfuscation engine. This engine effectively hides both the control flow and data flow of a program, making its execution patterns indistinguishable to an adversary.

Key findings and contributions of Obelix include:

• Comprehensive Side-Channel Mitigation: Obelix is shown to harden programs against several critical side-channel attack classes. Specifically, it directly addresses single-stepping attacks by uniformizing instruction latencies and memory access pattern attacks (including cache attacks) by making memory accesses oblivious. The paper also describes its ability to prevent CERTS side channels through additional masking on scratchpads.
• Dynamic Obfuscation Engine: The system operates by transforming the program at a low level, introducing elements that obscure the true execution path and data access patterns. This dynamic approach ensures that the observable behavior of the program remains constant, regardless of the actual operations being performed or data being accessed.
• Software Drop-in Solution: A crucial aspect of Obelix is its implementation as an LLVM compiler extension. This allows any program to be compiled in a "secure fashion" without requiring the developer to have expert knowledge in side-channel hardening techniques. This significantly lowers the barrier to entry for securing TEE workloads.
• Combination of Techniques: Obelix achieves its broad coverage by cleverly combining two primary techniques:
• Oblivious RAM (Oram): Used to obscure data access patterns, ensuring that every memory access appears identical to an observer.
• Code Obfuscation: Achieved by transforming the program into a sequence of uniformly structured "blocks" with fixed latency patterns, effectively defeating single-stepping attacks.
• Extendability: Beyond the primary mitigations, Obelix is designed with extensibility in mind. The researchers suggest that with minor extensions, such as adding hashing and fences at specific points, the framework could also provide protection against transient execution attacks (e.g., Spectre) and fault injection attacks (e.g., Rowhammer), further broadening its applicability to "almost all relevant side channels for TEEs."
• Performance Trade-offs: While highly effective in terms of security, the current implementation, particularly its reliance on a linear Oram, introduces significant performance overhead for large programs. However, the authors argue that for small programs or applications where responsiveness is not the primary concern (e.g., asynchronous background tasks), the security guarantees may outweigh the performance impact. They also highlight that ongoing research into more efficient Oram schemes could drastically improve Obelix's practical applicability in the future.

In essence, Obelix provides a paradigm shift in TEE security by offering a unified, compiler-driven, software-based solution that can protect against a multitude of side-channel threats, thereby making TEEs genuinely more trusted environments.

Technical Deep Dive

▶ Watch: Limitations of existing side-channel countermeasures for TEEs (4:00)

Obelix tackles the challenge of side-channel leakage in TEEs by implementing a dynamic obfuscation engine that operates on both data and control flows. The core technical innovations lie in its dual approach: making memory accesses oblivious and uniformizing instruction execution latencies.

Oblivious Memory Accesses with Oram

The first step in Obelix's strategy is to eliminate memory access pattern leakage. The fundamental problem is that even with encrypted memory, the physical addresses or pages being accessed are visible to an attacker. This allows an adversary to infer program behavior, especially when sensitive operations rely on lookup tables or specific data structures.

Obelix employs Oblivious RAM (Oram) to solve this. The concept of Oram is to transform every memory access such that the access pattern observed by an attacker is always identical, regardless of the actual data item being requested. The speaker illustrates this by suggesting that for every memory access, the system accesses every single memory location and then uses a "magic constant-time selection primitive" to pick the desired data. While this is a conceptual simplification, the underlying principle of Oram schemes is to introduce dummy reads and writes, shuffle data, and ensure that the physical locations accessed are independent of the logical access pattern. This ensures that the attacker always sees the same "access pattern" (e.g., accessing everything each time), thus learning nothing about the specific data item being accessed.

The speaker acknowledges the common concern regarding Oram's performance overhead, stating, "Oram, that's slow." This is a known limitation of many Oram schemes, as they inherently involve more memory operations than direct access. However, Obelix integrates Oram as a necessary component to achieve comprehensive data flow obfuscation.

Uniform Control Flow with Code Obfuscation

The second major technical challenge addressed by Obelix is mitigating single-stepping attacks, which exploit the unique latency patterns of different instructions to reconstruct program logic.

Obelix's solution involves transforming the program's code into a sequence of uniformly structured execution blocks. The process is as follows:

1. Define a Uniform Code Pattern: A fixed sequence of instructions is defined as the "uniform code pattern." For example, the speaker suggests a pattern consisting of three specific instructions in a predefined order.
2. Program Transformation: The original program's instructions are then mapped onto this uniform pattern.

• If an original instruction matches a part of the uniform pattern, it is used.
• If an original instruction does not fit the pattern, dummy instructions are inserted to fill the gaps. These dummy instructions perform no meaningful computation or memory access for the program's logic but contribute to the overall fixed latency. Examples provided include a "dummy memory access" to an unused ingredient (data that is thrown away) or a "dummy steering instruction" (e.g., an arithmetic operation like adding zero).

1. Block-Based Execution: The program is broken down into blocks, where each block, after obfuscation, always exhibits the same instruction count and the same fixed latency pattern. This ensures that when an attacker single-steps through the program, they observe an identical latency signature for every block, making it impossible to infer the actual instructions executed or their sequence.

Comprehensive Obfuscation: Combining Oram for Code and Data

A critical insight of Obelix is that merely obfuscating instruction latencies is insufficient if the attacker can still observe which code blocks are being executed. If code blocks are stored in regular memory, an attacker could still mount a memory access pattern attack against the blocks themselves, revealing control flow (e.g., loops, branches).

To address this, Obelix extends the use of Oram to the code itself. The system employs two distinct Orams:

1. Code Oram: Stores the obfuscated code blocks.
2. Data Oram: Stores the program's data.

The execution flow within Obelix is then:

• When the program needs to execute an instruction block, it first fetches this block from the Code Oram. This fetch operation is oblivious, meaning the attacker cannot discern which specific block was retrieved. The fetched block is placed into a code scratchpad near the computation unit.
• For any data access, the program interacts with the Data Oram. Data items are retrieved from the Data Oram into a data scratchpad. All data access operations, whether real or dummy, are performed obliviously. If a data item is modified, the updated version is written back to the Data Oram, maintaining consistency and obliviousness.
• The system also incorporates dummy accesses during scratchpad operations to maintain uniform behavior. For instance, after fetching a code block, dummy data might be read and written back to maintain the Oram's access pattern.

By combining these techniques, Obelix ensures that:

• The attacker always observes the same instruction latency pattern.
• The instruction counts appear uniform.
• The specific code block being executed is hidden.
• The specific data item being accessed is hidden.

This multi-layered obfuscation strategy provides a robust defense against both single-stepping and memory access pattern attacks. The speaker also mentions that for CERTS side channels, specific masking techniques are applied to the scratchpads and C data scratchpads to further prevent information leakage. The framework's design also allows for "minor extensions" like adding hashing and fences to counteract transient execution attacks (e.g., Spectre) and fault injections (e.g., Rowhammer), highlighting its broad defensive potential.

The primary technical trade-off, as repeatedly noted, is the performance overhead, especially with the use of a linear Oram. However, the modular design suggests that as more efficient Oram schemes emerge from research, they could be integrated into Obelix to improve its practical performance without compromising security.

Demo / Proof of Concept

▶ Watch: Obelix solution: Uniform code patterns against single-stepping (6:00)

The talk describes Obelix as a practical, implemented system rather than a purely theoretical concept. The proof of concept for Obelix is a compiler extension, specifically built for LLVM. This implementation demonstrates how the proposed obfuscation techniques can be applied to real-world programs.

The speaker states that this LLVM compiler extension is capable of taking an arbitrary program and compiling it in a "secure fashion." This means that the compiler automatically applies the necessary transformations – inserting dummy instructions for uniform code patterns, integrating Oram for both code and data access – without requiring manual intervention or expert knowledge from the developer. The compiled output is a hardened executable that is resilient to the side-channel attacks described.

While the talk does not feature a live, step-by-step demonstration of the compiler or an obfuscated program in action, the existence of the LLVM extension and "example targets" on GitHub serves as the concrete proof of concept. This open-source availability allows researchers and developers to inspect the implementation, verify its mechanisms, and experiment with applying Obelix to their own programs. The compiler extension embodies the core tenet of Obelix: providing a software drop-in solution that abstracts away the complexities of side-channel mitigation for TEEs.

Defensive Implications

▶ Watch: Demonstrating uniform code pattern transformation with dummy instructions (7:00)

Obelix offers significant implications for defenders seeking to secure workloads within Trusted Execution Environments, providing a compelling alternative to existing, often inadequate, solutions.

Firstly, the most impactful implication is the provision of a software drop-in countermeasure for TEE side-channels. Historically, securing TEEs against side-channel attacks has been a formidable challenge, often requiring developers to meticulously craft constant-time code for sensitive operations, a process that is both error-prone and labor-intensive. Alternatively, hardware-based countermeasures are typically specific to certain attack vectors and lack interoperability. Obelix bypasses these limitations by automating the hardening process via an LLVM compiler extension. This means that developers can compile their existing codebases with Obelix, gaining robust side-channel protection without needing to be experts in microarchitectural security or rewriting their applications. This democratizes TEE security, making it accessible to a broader range of applications and developers.

Secondly, Obelix's broad coverage against multiple side-channel classes is a critical advantage. By simultaneously addressing single-stepping attacks (via code obfuscation and uniform instruction latencies) and memory access pattern attacks (via Oblivious RAM for both code and data), it tackles two of the most potent threats to TEE confidentiality. Furthermore, its extendability to CERTS side channels and potential for mitigating transient execution attacks (Spectre) and fault injection attacks (Rowhammer) positions it as a near-universal defense mechanism. For organizations deploying sensitive intellectual property, cryptographic keys, or proprietary algorithms in cloud-based TEEs, Obelix provides a comprehensive layer of protection that significantly raises the bar for attackers.

Thirdly, defenders must carefully consider the performance overhead associated with Obelix. The reliance on Oblivious RAM, particularly linear Oram as used in the current implementation, introduces a substantial performance penalty. For latency-critical applications or very large programs, this overhead could be prohibitive. However, for use cases where security guarantees outweigh execution speed – such as asynchronous data processing tasks, batch computations, or applications with strict confidentiality requirements where a 100x slowdown might still result in acceptable wall-clock time – Obelix presents a viable and highly secure option. Defenders should perform thorough profiling and evaluation to determine if the performance trade-off is acceptable for their specific workload. The research also highlights the ongoing efforts in the Oram community to develop more efficient schemes, suggesting that future iterations of Obelix could offer improved performance.

Finally, the open-source nature of the compiler extension and example targets on GitHub provides transparency and fosters trust. Defenders can audit the implementation, understand its mechanisms, and contribute to its improvement. This collaborative approach is vital for security solutions, allowing for community review and validation of the countermeasure's effectiveness and correctness. Organizations can integrate Obelix into their secure development lifecycle, treating it as a critical tool for ensuring the integrity and confidentiality of their TEE-protected assets in untrusted environments.

Key Takeaways

• Obelix is a software-based, dynamic obfuscation engine designed to mitigate multiple side-channel attacks against Trusted Execution Environments (TEEs).
• It achieves comprehensive protection by hiding both control flow and data flow, making program execution patterns indistinguishable to adversaries.
• The core technical approach combines Oblivious RAM (Oram) for oblivious memory access patterns and code obfuscation (uniform instruction latency patterns and dummy instructions) to defeat single-stepping attacks.
• Implemented as an LLVM compiler extension, Obelix provides a practical "software drop-in" solution, enabling TEE hardening without requiring specialized side-channel security expertise from developers.
• Obelix specifically addresses single-stepping, memory access patterns (cache attacks), and CERTS side channels, with the potential for extension to transient execution attacks (Spectre) and fault injection attacks (Rowhammer).
• While offering strong security guarantees, the current implementation, particularly its use of linear Oram, introduces significant performance overhead, which must be evaluated for specific use cases; however, ongoing Oram research promises future performance improvements.

About the Speaker(s)

The talk "Obelix: Mitigating Side-Channels through Dynamic Obfuscation" was presented by Jan Wichelmann from the University of Lübeck. He is the primary speaker and researcher introducing this novel work. The research itself is a collaborative effort, with Anja Rabich, Anna Pätschke, and Thomas Eisenbarth also credited as contributors to the paper.