The Forking Way: When TEEs Meet Consensus

Annika Wilde (Ro University)

Network and Distributed System Security (NDSS) Symposium 2025 · Day 1 · Blockchain Security 1

Overview

In "The Forking Way: When TEEs Meet Consensus," Annika Wilde from Ruhr University Bochum presents a critical examination of the interplay between Trusted Execution Environments (TEEs) and blockchain consensus mechanisms, highlighting significant security vulnerabilities arising from their combination. The talk delves into how TEEs, which provide hardware-based isolation for sensitive computations, often fall short in guaranteeing input freshness, making them susceptible to forking attacks. Blockchains, designed for total ordering of events through consensus, are explored as a potential countermeasure, but their integration with TEEs introduces new complexities.

Watch on YouTube · Slides

Key moments

  1. 0:00 Introduction to TEEs, limitations, and forking attacks
  2. 1:58 TEE-blockchain integration and four deployment types
  3. 3:05 Research methodology: analyzing TEE-blockchains and vulnerabilities
  4. 4:25 Overview of four forking attack mitigation strategies
  5. 5:15 Fala blockchain case study: zero-day cloning exploit
  6. 6:45 Proposed solution to fix Fala's cloning vulnerability
  7. 7:50 Limitations of the proposed fix and broader considerations

The Forking Way: When TEEs Meet Consensus

Speakers: Annika Wilde, PhD Student, Ruhr University Bochum

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=5wdntWrHUws

Overview

In "The Forking Way: When TEEs Meet Consensus," Annika Wilde from Ruhr University Bochum presents a critical examination of the interplay between Trusted Execution Environments (TEEs) and blockchain consensus mechanisms, highlighting significant security vulnerabilities arising from their combination. The talk delves into how TEEs, which provide hardware-based isolation for sensitive computations, often fall short in guaranteeing input freshness, making them susceptible to forking attacks. Blockchains, designed for total ordering of events through consensus, are explored as a potential countermeasure, but their integration with TEEs introduces new complexities.

Wilde's research identifies and dissects four primary strategies employed by TEE-based blockchain solutions to mitigate forking attacks, revealing inherent limitations in each. The core contribution of this work is the discovery of previously unknown cloning vulnerabilities that led to zero-day exploits in three production-ready networks: Fala, Secret Network, and Ten. This talk is crucial for anyone involved in the design, development, or security auditing of confidential computing solutions leveraging blockchain technology, as it uncovers fundamental security gaps and proposes practical, context-specific mitigations.

The presentation emphasizes that despite the promising synergy between TEEs and blockchains for enabling confidential and verifiable computations, their "marriage" is fraught with challenges. The talk serves as a stark reminder that a "one-size-fits-all" security solution is inadequate in this complex domain. Instead, a nuanced understanding of application logic, TEE capabilities, and blockchain properties is essential to prevent sophisticated attacks that can undermine the integrity and confidentiality of TEE-based decentralized applications.

Background

▶ Watch: Introduction to TEEs, limitations, and forking attacks (0:00)

The convergence of Trusted Execution Environments (TEEs) and blockchain technology represents a significant step towards building secure and confidential decentralized applications. TEEs, such as Intel SGX or ARM TrustZone, offer hardware-based isolation for runtime memory within a secure enclave, protecting sensitive computations even on a compromised host system. However, TEEs come with inherent limitations: all input and output (I/O) is controlled by the untrusted host, and they lack freshness guarantees. This means a TEE cannot independently verify if the input it receives is current or if the untrusted host is replaying old data. This fundamental weakness opens the door to forking attacks, where an adversary exploits the lack of freshness to manipulate the enclave's state, leading to inconsistencies. These attacks manifest primarily as rollback attacks (replaying old state) and cloning attacks (running multiple instances of an enclave with different states).

On the other hand, blockchain technology leverages consensus mechanisms to achieve a total, immutable ordering of events. This inherent property makes blockchains attractive for mitigating the freshness issues faced by TEEs. However, blockchains also have their own constraints: all data involved in consensus must be publicly available. This public nature restricts the embedding of secrets within smart contracts and makes reproducible randomness challenging, as any source of randomness would need to be public or deterministically derived, compromising its unpredictability.

Recognizing the complementary strengths of these technologies, the community has explored their "marriage." TEEs can provide randomized and confidential computing, addressing the privacy and unpredictability gaps in public blockchains. In return, blockchains offer a total ordering of events, which can be leveraged to provide freshness guarantees and thus mitigate forking attacks against TEEs.

This integration has led to various deployment models:

  1. TEE-based Smart Contracts: Blockchain nodes execute smart contracts inside TEEs to provide confidentiality for their state and execution.
  2. TEE-based Consensus Protocols: TEEs are used to accelerate or scale consensus mechanisms, potentially by offloading parts of the agreement process to a trusted environment.
  3. TEE-based Layer 2 Solutions: Platforms use TEEs to offer confidential smart contracts for Layer 1 blockchains that do not natively support such features.
  4. TEE-based Off-chain Solutions: TEEs provide secure blockchain access for applications like crypto wallets or lightweight clients, ensuring the integrity of data accessed from the blockchain.

The research presented in the talk involved a comprehensive analysis of 29 TEE-based blockchain applications across these four categories, specifically examining their strategies for preventing rollback and cloning attacks and evaluating their limitations and potential pitfalls. This extensive survey aimed to understand the landscape of existing mitigations and identify where they fall short.

Key Findings

▶ Watch: Research methodology: analyzing TEE-blockchains and vulnerabilities (3:05)

The comprehensive analysis conducted by Annika Wilde and her team identified four broad strategies employed by TEE-based blockchain applications to mitigate forking attacks (rollback and cloning):

  1. Stateless Enclaves: This strategy involves designing enclaves that do not persist any state. By re-executing all transactions from the ledger upon restart to recover their state, these enclaves are inherently rollback resistant by design. This simplicity offers a strong defense against state replaying.
  2. Ephemeral Identities: To distinguish between legitimate enclaves and malicious clones, this approach assigns unique, short-lived identities to enclaves. This allows for the detection of multiple enclaves claiming to be the same instance, thereby preventing cloning attacks.
  3. Fixed Set of Clients: In scenarios where the application logic permits, defining a predetermined and trusted set of clients can be used to detect inconsistencies in the enclave's state. If multiple clients query an enclave and receive conflicting states, it indicates a potential attack.
  4. Serialization Properties of the Underlying Blockchain: Many applications leverage the blockchain's inherent ability to provide a total order of events. By serializing state updates or other critical data onto the ledger, enclaves can use this ordered history to ensure state consistency and protect against rollback.

Despite the existence of these strategies, the research uncovered significant limitations and pitfalls. These limitations often manifest in the expressiveness of the enclave application (e.g., stateless enclaves cannot easily support complex, long-running stateful computations), key management requirements, and how effectively they handle faults or blockchain forks. For instance, serialization techniques can be vulnerable if the underlying blockchain experiences forks, leading to conflicting transaction histories.

Crucially, the study revealed that no single mitigation strategy is a "one-size-fits-all" solution. The complexity of the problem was starkly demonstrated by the discovery of previously unknown cloning vulnerabilities that led to zero-day exploits in three production-ready networks:

  • Fala: A Layer 1 blockchain designed for confidential smart contracts.
  • Secret Network: Another prominent platform for confidential smart contracts.
  • Ten: (Details not explicitly expanded in the talk, but listed as a target).

These findings highlight that even mature, production-ready systems are susceptible to subtle yet critical flaws in their TEE-blockchain integration. The research not only identified these vulnerabilities but also played the role of a "marriage counselor," leveraging the in-depth analysis to propose concrete fixes and counter-measures for the identified issues, emphasizing the need for tailored solutions.

Technical Deep Dive

▶ Watch: Overview of four forking attack mitigation strategies (4:25)

The methodology for this research involved a meticulous analysis of 29 TEE-based blockchain applications, followed by an in-depth examination of an additional 28 TEE-based blockchain implementations. The evaluation focused on how these platforms cope with rollback and cloning attacks, assessing them against three core properties: functionality, robustness, and performance. This broad survey aimed to characterize the landscape of existing solutions and identify common patterns and weaknesses.

The four broad mitigation strategies, while conceptually sound, each carry specific technical limitations:

  1. Stateless Enclaves: While excellent for rollback resistance, this approach severely limits the expressiveness of the enclave application. Any stateful computation requires re-executing the entire transaction history, which can be computationally intensive and impact performance, especially for complex smart contracts or high transaction volumes.
  2. Ephemeral Identities: This strategy relies on robust key management and a secure mechanism for enclaves to attest their ephemeral identity to clients or other enclaves. Failures in identity generation, distribution, or verification can undermine its effectiveness.
  3. Fixed Set of Clients: This solution is highly restrictive, only applicable when the application logic allows for a predefined and trusted client base. It doesn't scale well for public, permissionless applications and introduces a centralization point.
  4. Serialization Properties of the Underlying Blockchain: This approach leverages the blockchain's immutability and ordering. However, it is vulnerable to blockchain forks. If the underlying ledger forks, different enclaves might process conflicting transaction histories, leading to inconsistent states. Solutions using this often rely on BFT consensus blockchains (which are designed to be fork-free) rather than Nakamoto-style consensus (which allows for transient forks).

To illustrate these points and the discovery of zero-day exploits, Annika Wilde detailed the case of Fala, a production-ready Layer 1 blockchain with an active mainnet that utilizes TEEs for confidential smart contracts.

Fala's Architecture:

Each node in the Fala network runs two primary components:

  • A Relayer: This component fetches blocks from the blockchain and forwards them to the enclave. It acts as the untrusted intermediary between the blockchain and the TEE.
  • An Enclave: This secure component parses transactions from the blocks received from the relayer and executes them to update the smart contract state.

A subset of nodes also runs an additional component responsible for performing consensus and publishing new blocks to the blockchain.

Fala's Existing Mitigations:

Fala primarily employs stateless enclaves and serialization techniques. The enclave does not persistently store smart contract state. Instead, upon restart or initialization, it re-executes all relevant transactions from the ledger to reconstruct its current state, making it resistant to simple rollbacks.

The Cloning Vulnerability in Fala (Zero-Day Exploit):

Despite these mitigations, the research uncovered a critical cloning vulnerability in Fala. The attack proceeds as follows:

  1. Assume two enclave clones exist, both having processed transactions from the ledger up to a certain point.
  2. A malicious node can terminate one of its relayers, effectively isolating the associated enclave. This isolated enclave stops receiving new transactions and thus cannot update its state.
  3. When a client queries the smart contract state from this isolated enclave, the enclave responds with an outdated state.
  4. Crucially, the client receives this outdated state without any indication that the data is stale or that an attack is in progress. The adversary can then choose to present either the current state (from the honest enclave) or the outdated state (from the isolated clone), leading to equivocation on the smart contract state.

Proposed Fixes for Fala:

The researchers proposed several enhancements to mitigate this cloning vulnerability:

  1. Enhanced Heartbeat Mechanism: Fala already uses a heartbeat mechanism where enclaves regularly issue heartbeat transactions to prove they are alive. These transactions include the current block height. The proposed tweak involves:
  • Enclaves exchanging these heartbeat messages via a separate peer-to-peer (P2P) network.
  • Enclaves verifying two things: 1) they regularly receive heartbeats from other enclaves, and 2) the included block height in these heartbeats matches their own last processed block.
  • Limitation: This solution requires the enclave to be connected to at least one honest node to ensure it receives all heartbeat transactions. Furthermore, randomized smart contracts are still vulnerable to cloning; an adversary could execute the contract twice with the same input, obtain different random outputs, and then choose the more favorable one.
  1. Client-Side Freshness Validation: To address the issue of clients receiving outdated responses without detection, it was suggested to include the current block height in all responses from the enclave to the client. This allows the client to validate the freshness of the response, immediately detecting if the data is stale.
  • Limitation: This still does not solve the issue with randomized computations, as the client can only verify freshness, not the uniqueness of execution.
  1. Reliance on Ephemeral Identities for Randomized Computations: To fully protect against cloning of randomized executions, the only robust solution is to rely on ephemeral identities. This ensures that only one legitimate enclave instance is running on each node at all times, preventing an attacker from running multiple clones to "reroll" random outputs.

The paper emphasizes that selecting the correct countermeasure, or combination thereof, requires careful consideration of the specific blockchain provisions, the goals of the application, and the desired security properties. The same in-depth analysis and identification of vulnerabilities were extended to 28 additional TEE-based blockchain implementations, leading to the discovery of similar zero-day exploits in Secret Network and Ten.

Demo / Proof of Concept

▶ Watch: Proposed solution to fix Fala's cloning vulnerability (6:45)

While the talk meticulously describes the mechanics of the cloning vulnerability in Fala and outlines the proposed mitigation strategies, it does not explicitly mention a live demonstration or a technical Proof of Concept (PoC) being presented during the conference session. The focus was on the analytical discovery of the zero-day exploits and the detailed explanation of how these attacks manifest and how they can be countered through architectural and protocol adjustments. The technical deep dive into Fala serves as a detailed exposition of the attack vector and the proposed fixes, effectively functioning as a conceptual PoC.

Defensive Implications

▶ Watch: Limitations of the proposed fix and broader considerations (7:50)

The research presented by Annika Wilde offers crucial insights for developers, architects, and security professionals working with TEE-based blockchain solutions. The primary defensive implication is that there is no "one-size-fits-all" forking mitigation. Each TEE-blockchain integration requires a tailored approach, considering the specific application logic, the capabilities provided by the underlying blockchain, and the desired security guarantees.

Defenders should take the following actions:

  1. Prioritize Statelessness for Rollback Protection: Whenever feasible, design enclaves to be stateless. By re-executing transactions from the ledger to recover state, enclaves gain robust rollback resistance. This is identified as the best available mitigation for rollback attacks.
  2. Employ Ephemeral Identities for Randomized Executions: For applications involving randomized computations within TEEs, ephemeral identities are indispensable. This is the only reliable method to prevent cloning attacks where an adversary might re-execute an enclave to obtain different random outputs and choose the most favorable one. Implementing robust identity attestation and lifecycle management for enclaves is critical.
  3. Implement Client-Side Freshness Validation: To prevent clients from unknowingly accepting outdated or manipulated enclave responses, all enclave outputs to clients should include the current block height or a similar freshness indicator. Clients must then validate this information to ensure the response is recent and consistent with the blockchain's state.
  4. Carefully Evaluate Blockchain Serialization: While leveraging the blockchain's serialization capabilities can lock enclave state and protect against rollback, this strategy is highly dependent on the underlying blockchain's consensus mechanism. If the blockchain allows for forks (e.g., Nakamoto-style consensus), then serialization alone is insufficient, as conflicting transaction histories can emerge. Solutions should ideally use blockchains with BFT consensus, which are designed to prevent forks.
  5. Consider Fixed Client Sets Judiciously: The strategy of defining a fixed set of clients can be viable but only if the application's logic and trust model allow for such a restrictive setup. It is generally not suitable for public, permissionless decentralized applications.
  6. Adopt a Holistic Security Design: Developers must move beyond simply integrating TEEs and blockchains and instead focus on their secure interaction. This involves analyzing potential attack surfaces at the intersection of the untrusted host, the TEE, and the blockchain, and understanding how an adversary might manipulate inputs or outputs.
  7. Explore Formal Verification: As suggested in the Q&A, exploring formal verification methods for the combined TEE-blockchain architecture could provide stronger security guarantees and help uncover subtle vulnerabilities that might be missed by empirical analysis. This is a promising avenue for future work and a high standard for critical systems.
  8. Stay Informed on Exploits: The discovery of zero-day exploits in production networks like Fala, Secret Network, and Ten underscores the ongoing need for vigilance. Continuous security auditing, penetration testing, and staying updated with the latest research on TEE and blockchain security are paramount.

Key Takeaways

  • The integration of Trusted Execution Environments (TEEs) with blockchain technology, while promising for confidential computing, introduces complex security challenges, particularly forking attacks (rollback and cloning) due to TEEs' lack of input freshness guarantees.
  • Four primary mitigation strategies exist: stateless enclaves, ephemeral identities, fixed sets of clients, and leveraging blockchain serialization. However, all have significant limitations related to application expressiveness, key management, and handling blockchain forks.
  • The research uncovered critical cloning vulnerabilities that led to zero-day exploits in three production-ready networks: Fala, Secret Network, and Ten, demonstrating that existing mitigations are often insufficient.
  • Effective defense against forking attacks requires a tailored approach, carefully considering the specific application logic, whether the enclave is stateful or performs randomized computations, and the properties of the underlying blockchain (e.g., fork-freeness).
  • For robust protection, stateless enclaves are the best defense against rollback attacks when possible, and ephemeral identities are essential to prevent cloning of randomized executions.
  • Implementing client-side freshness validation (e.g., including block height in all enclave responses) and being acutely aware of how blockchain forks can impact serialization-based mitigations are critical for system integrity.

About the Speaker(s)

Annika Wilde is a PhD Student at Ruhr University Bochum. Her research focuses on the security aspects of Trusted Execution Environments (TEEs) and their integration with blockchain technologies, particularly in the context of confidential computing and distributed systems. Her work, as presented in "The Forking Way: When TEEs Meet Consensus," contributes significantly to understanding and mitigating sophisticated attacks against these combined architectures.

Reviews

Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT

Solid academic security research with real teeth: three zero-days in production networks, a systematic taxonomy of forking mitigations, and an honest accounting of what each approach actually buys you. This is a PhD student doing work that production engineers at those networks missed — that's the signal.

Heather Calloway (CISO) — WEAK

Credible academic security research that found real zero-days in production systems — that part is legitimate and not nothing. But this talk is built for cryptosystems researchers, not for the security leaders, operators, or governance bodies who would need to act on findings like these.

→ Top-rated talks at Network and Distributed System Security (NDSS) Symposium 2025

All talks from Network and Distributed System Security (NDSS) Symposium 2025