TeeDAO: A Decentralized Autonomous Organization for Heterogeneous TEEs Pinshen Xu∗ , Wentao Dong∗ , Guoxing Chen† , Jianyu Niu∗ , Cong Wang∗ , and Yinqian Zhang‡ ∗ City University of Hong Kong † Shanghai Jiao Tong University
arXiv:2606.04912v1 [cs.CR] 3 Jun 2026
‡ Southern University of Science and Technology
Abstract—Trusted Execution Environments (TEEs) have emerged as a critical technology for safeguarding sensitive data and ensuring code integrity in modern computing systems. However, relying on a single TEE implementation makes systems vulnerable to a central point of attack. Building distributedtrust systems leveraging heterogeneous TEEs helps disperse trust but still faces threats from centralized management and adaptive mobile adversaries. To address these challenges, this paper introduces TeeDAO, a novel three-layer framework that automatically organizes multiple heterogeneous TEE instances and provides unified interfaces to support diverse applications, while ensuring long-term guarantees of availability, integrity, and confidentiality. TeeDAO couples BFT-ordered governance with heterogeneity-aware Distributed Proactive Secret Sharing (DPSS) and Secure Multi-Party Computation (MPC) so that attestation-driven committee changes are consistently reflected in secret recovery, resharing, and computation across a dynamic committee of heterogeneous TEEs. We implement a prototype of TeeDAO, integrating COBRA’s DPSS scheme with the HotStuff BFT consensus protocol, and adapt it for Intel SGX, TDX, and Hygon CSV. Evaluations demonstrate that TeeDAO achieves up to 1.8× higher key-value store throughput in a large cluster with 61 nodes compared to state-of-the-art systems, efficient autonomous management, and minimal computation overhead (< 18%) for multi-party computation tasks.
I. I NTRODUCTION Trusted Execution Environments (TEEs) have emerged as the cornerstone of modern cloud security, enabling the paradigm of Confidential Computing. By leveraging hardwareenforced isolation and remote attestation, TEEs allow users to process sensitive data without trusting the underlying operating system or privileged software. This hardware-rooted trust model has been widely adopted: processor vendors have rolled out diverse implementations, ranging from process-based Intel SGX [1] to VM-based architectures like Intel TDX [2], ARM CCA [3], AMD SEV [4], and Hygon CSV [5]. Major cloud providers (e.g., Azure [6], AWS [7], Google Cloud [8]) also expose these capabilities as standard managed services. Despite various proposals using TEEs to protect securitycritical services, e.g., confidential analytics [9]–[11], key management [12], [13], and digital-asset custody [14]–[19], a single TEE implementation remains questionable in practice [20]–[31]. The major concerns stem from the central point of attacks [32]: Once the underlying hardware trust root is compromised, isolation can fail, and long-lived secrets may be exposed. For example, microarchitectural exploits (e.g., transient execution attacks Spectre/Meltdown [33], [34])
and demonstrated key-exfiltration attacks against commodity TEEs [20], [21], [23], [24] illustrate that such breaks are realistic. Although vendors actively patch these flaws, the history of vulnerabilities suggests an endless arms race, where new zero-day exploits inevitably emerge [35], [36]. Beyond breaches of enclave isolation, a single TEE also faces availability threats (e.g., denial-of-service [37]) and side-channel attacks [38]. As a result, a single-TEE system can hardly offer durable guarantees of availability, integrity, or confidentiality for security-critical services. To address this central point of attack, recent research has turned to distributing trust across heterogeneous TEEs. A seminal example is SVR3 [39], which advances secure key recovery for end-to-end encrypted messaging as deployed in the Signal platform [40]. SVR3 distributes user secret shares across diverse enclave implementations (e.g., SGX, SEV, Nitro) and cloud providers, ensuring that the compromise of a subset of hardware platforms or providers is insufficient to compromise data confidentiality. This approach significantly elevates the bar for adversaries to subvert multiple, distinct roots of trust simultaneously. (See more discussion in Sec. II-A.) While SVR3 validates the utility of heterogeneous TEEs in static deployments, our work targets a more challenging domain: long-running confidential services ranging from databases [9] and analytics engines [10], TLS/CDN infrastructure [12], and blockchain-oriented oracles and exchange applications [16], [41]. In this setting, security cannot be established once at deployment; it must be maintained over time as the committee reconfigures and as TEEs evolve through disclosure, patching, and revocation. Specifically, the system should automatically remove compromised TEEs and incorporate new ones, all while keeping users’ secrets safe. The core difficulty is that these tasks cannot be solved independently. Attestation can indicate which TEE instances remain eligible to serve, but they do not protect secrets that have already been exposed by formerly compromised enclaves. Conversely, DPSS and MPC can refresh and compute over secret shares, but they do not determine which node should receive those shares after disclosure, patching, or replacement. Thus, a longrunning heterogeneous TEE service must make trust evidence, committee membership, and secret-share state evolve together. This dynamic environment imposes two distinct requirements compared to the static deployments:
• Evidence-driven autonomous management: Long-running services must repeatedly reconfigure in response to maintenance and vulnerability disclosures, and each operational change must be authorized by verifiable evidence and strictly governed by protocol rules. This ensures that the compromise of a single administrative authority does not degenerate into a single point of failure.
[49], cryptocurrency wallets [50], [51], and multi-party collaborative analytics [52]–[55]. We implement a prototype of TeeDAO within a heterogeneous TEEs environment, integrating COBRA’s DPSS scheme [44] atop the HotStuff Byzantine Fault Tolerant (BFT) consensus protocol [56]. The system is designed to be versatile: we aptly adapt BLS threshold signatures [57] and the general-purpose MP-SPDZ framework [58] to operate over our DPSS layer, deployed across Intel SGX, Intel TDX, and Hygon CSV enclaves. We also conduct performance evaluations of KVS throughput, management cost, and computation overhead introduced by the framework. The evaluation results show that TeeDAO outperforms state-of-the-art confidential BFT system COBRA in KVS throughput, achieving up to 1.8× higher throughput in the large cluster with 61 nodes, and demonstrates efficient system management with lower reconfiguration and recovery latency in smaller clusters. Additionally, TeeDAO introduces minimal computation overhead compared to vanilla MPC based on Shamir’s secret sharing protocol under the malicious and honest majority models, with performance overhead below 10% for most tasks and within 18% for more complex workloads like machine learning.
• Proactive secret maintenance: The system must withstand adaptive mobile adversaries [42]–[44], who may compromise different TEE implementations1 over time. This necessitates mechanisms to periodically refresh secret shares and effectively invalidate the adversary’s accumulated knowledge across configurations. These challenges further raise the question: How can we design a framework that ensures confidentiality, integrity, and availability for a long-running distributed system built on heterogeneous TEEs? Our TeeDAO Framework. To answer the question, we propose TEE Decentralized Autonomous Organization (TeeDAO), a three-layer framework that manages a committee of heterogeneous TEEs as a distributed-trust infrastructure for longrunning confidential services. TeeDAO enforces a single configuration invariant: the same consensus-certified configuration determines which nodes may order requests, hold secret shares, and participate in service. To this end, TeeDAO first integrates a rule-based governance layer, inspired by the algorithmic transparency of DAOs [45], [46], to realize evidencedriven autonomous management. It standardizes heterogeneous TEEs into a uniform node abstraction by deriving verifiable reports from remote attestation and authenticated vendor revocation/TCB information. These reports enable TeeDAO to authenticate node rejoin and detect compromised TEEs. Furthermore, critical actions, such as provisioning nodes, updating configurations, or evicting compromised platforms, require cryptographically verified threshold approval, thereby asserting operational authority against centralized administrators. It replaces administrator-driven control with consensusgoverned, rule-based governance that admits, revokes, and reconfigures the committee only via evidence-carrying operations that every member can independently verify. Second, TeeDAO stores long-lived secrets and application state as cryptographic shares across heterogeneous TEEs. It uses DPSS to periodically refresh shares as the committee or hardware landscape changes, thereby rendering accumulated leakage obsolete. In addition, TeeDAO supports secure multiparty computation (MPC) over the distributed secrets. Except for the above design, TeeDAO also abstracts all internal complexity through standardized read, write, and execute interfaces, enabling applications to inherit robust distributed trust without redesigning their security foundations. This unified interface can support a wide array of confidential services, including encrypted key-value stores (KVS) [47]–
Contributions. This paper makes three contributions: • We identify the lifecycle problem of long-running heterogeneous TEE services: trust evidence, committee membership, and secret-share ownership must evolve consistently under adaptive compromise. We formalize this setting using an adaptive mobile adversary and the security goals of safety, liveness, and proactive secrecy. • We introduce TeeDAO, a three-layer framework that provides three unified interfaces to support KVS, cryptocurrency wallets, and multi-party collaborative analytics services. TeeDAO enforces the consistency by deriving node eligibility from attestation and revocation evidence, committing membership changes through BFT governance, and coupling each configuration transition with DPSS refresh, resharing, recovery, and MPC execution. • We deploy TeeDAO on three mainstream TEE platforms, i.e., Intel SGX, Intel TDX, and Hygon CSV, and conduct extensive evaluations. The results demonstrate that TeeDAO achieves high KVS throughput, efficient autonomous management, and reasonable MPC computation overhead. II. BACKGROUND AND M OTIVATION A. Heterogeneous TEE Systems TEE is a processor extension to protect sensitive code and data even when the operating system (OS) or software administrators are compromised. It provides a secure runtime environment, referred to as an enclave2 , which is isolated from other privileged software. As said in Sec. I, a single TEE implementation remains questionable in practice [20]–[31]. To address it, one promising approach is to distribute trust
1 We use the term implementation to refer to a specific version of a particular type of TEE hardware.
2 We use enclaves to denote the isolated environments across different TEE technologies.
2
data confidentiality. (See more in Sec. I.) Second, many TEE applications, such as databases [9] and analytics engines [10], TLS/CDN infrastructure [12], and blockchain-oriented applications [16], [41], is long-lived, stateful. In these deployments, secrets and sensitive state must remain protected over months/years despite upgrades, reconfiguration, and especially adaptive compromise. This requires the system to remove compromised TEEs or authenticate new secure TEEs to join through reconfiguration, while maintaining the security of computation and storage.
Research TEE (a)
Cloud offering
CPU-vendor TEE Side-channel Transient execution
Protocol/attestation Fault injection
SGX (b)
TDX SEV
15
17
19 21 Year ('15-'25)
23
25
B. Multi-Party Computation (MPC)
Fig. 1: (a) TEE availability timeline. (b) Representative attacks over time. Controlled-channel attacks (CtrlChan) [64], Branch-shadowing side channels (Branch) [27], Foreshadow [21], Plundervolt (PVolt) [65], ÆPIC [66], SEV remote-attestation weaknesses (SEVRA) [23], Fault injection attacks (Glitch) [24], Ciphertext side channels (CiphSC) [22], TDXdown [30], and TDXploit [31].
Secret sharing and multi-party computation are cryptographic techniques that decentralize trust, ensuring that no single party can unilaterally compromise data confidentiality. Threshold Secret Sharing and Proactive Protection. Shamir’s threshold Secret Sharing (SS) scheme [71] splits a secret into n shares such that any t + 1 shares can reconstruct the secret, while t or fewer reveal nothing. Thus, an adversary does not hold the full secret so long as it controls more than t parties. In threshold signature schemes (TSS) [72], for example, a signing key is shared among n parties, and any t + 1 parties can jointly produce a valid signature, but no smaller subset can reconstruct the key. Classic SS and TSS, however, are static: the set of parties is fixed, and once a share is compromised, it remains valid indefinitely. DPSS [44], [73]–[76] strengthens this by periodically refreshing shares and supporting changes in the committee without reissuing the underlying secret. Modern DPSS constructions (e.g., COBRA [44]) allow parties to collaboratively reshare secrets, recover shares for temporarily offline nodes, and transfer shares to a new committee, thereby providing long-term secrecy even against an adaptive mobile adversary.
across heterogeneous TEEs, which inherently stems from the following observations. i) Various TEEs are available. TEEs can be broadly categorized into two types: process-based TEEs, such as Intel SGX [1], and virtual machine (VM)-based TEEs, including Intel TDX [2], AMD SEV [4], Hygon CSV [5], ARM CCA [3], IBM PEF [59]. These mechanisms are widely available on commodity CPUs and exposed as managed confidential computing services by major cloud providers as shown in Fig. 1. At the same time, research TEEs such as Keystone [60], Sanctum [61], CURE [62], and TIMBER-V [63] explore alternative enclave abstractions and hardware–software codesigns. The wide availability of commodity TEEs establishes a practical basis for building heterogeneous TEE systems. ii) Heterogeneous TEEs reduce correlated failures. Prior studies indicate that different TEEs exhibit distinct vulnerabilities, each tied to their unique design choices and threat models. For instance, as shown in Fig. 1, Intel SGX suffers from various software attacks [28], [67], [68], speculative execution attacks [20], [21], [65], [66]) and side-channel attacks [26], [27], [29], [64], [69], [70]), while AMD SEV have been attacked via weaknesses in memory-encryption [22] and integrity trees [23], [24]. These differences arise from varying security assumptions, isolation mechanisms, and hardware abstractions, creating unique attack surfaces for each TEE type. Thus, this heterogeneity enables systems to avoid a single point of compromise and achieve stronger security guarantees.
Secret-Sharing–Based MPC. MPC protocols [77], [78] allow several parties to jointly evaluate a function on their private inputs while revealing only the output. In secret-share–based MPC [79], each intermediate value is represented as shares under a linear secret-sharing scheme; additions are performed locally on shares, while multiplications require several interactive communication rounds. General-purpose MPC frameworks such as MP-SPDZ [58] compile high-level programs to arithmetic circuits over shares and support malicious-adversary security. Secret-sharing–based MPC ensures that no single party ever sees plaintext inputs or full application state, while still allowing arbitrary computations on those values.
iii) Building practical heterogeneous TEE systems is nontrivial. First, if each TEE stores the same plaintext secret, such as users’ passwords, compromising any one instance would reveal that secret, even if all other instances remain secure. To address this, a promising way is to distribute secret shares among diverse enclave implementations, as illustrated in SVR3 [39]. This ensures that the compromise of a subset of hardware platforms or providers is insufficient to compromise
III. P ROBLEM S TATEMENT As motivated in Sec. II, relying on a single TEE implementation creates a central point of attack: Once that implementation is broken, the running service within TEEs can lose confidentiality, integrity, or become unavailable. Prior work [32], [39] has shown that distributing secrets across multiple TEEs can reduce reliance on any single implementation, but supporting long-running confidential services still has two
3
B. Threat Model
Data
We consider an adaptive mobile adversary A that controls a dynamic set of corrupted nodes at any given time by aligning with prior work [44]. The size of this set is bounded by the threshold t, where n = 3t + 1 is the full committee size. The adversary can also mount network attacks, e.g., intercepting, dropping, delaying, reordering, and replaying messages. A corrupted node may be affected at different depths. If the adversary controls only the host OS or hypervisor while the TEE remains intact, the node may omit, delay, or withhold protocol messages, but the adversary does not learn the enclave’s internal state. If the adversary also exploits a vulnerability in the TEE implementation, it obtains the enclave state, including secret shares and signing keys. In this case, the adversary can make the corresponding node deviate arbitrarily from the protocol, including equivocation, sending malformed shares, or returning inconsistent responses. We model such TEE-compromised nodes as Byzantine faults [80]. For consensus and service correctness, we conservatively treat all corrupted nodes as faulty. For confidentiality, only TEEcompromised nodes contribute leaked secret shares. We assume that compromising different TEE hardware implementations requires distinct exploits. Due to the heterogeneous designs, we assume that the adversary cannot compromise more than t TEEs at any time. This allows the system to proactively refresh secrets before the security threshold is breached. We also assume TEE vulnerabilities eventually become known via authenticated vendor channels (e.g., revocation lists and attestation [81]–[83]). TEE nodes whose attestation status becomes invalid are treated as revoked and removed. Additionally, if cryptographic evidence proves a safety violation (e.g., equivocation) by a node, it is immediately treated as Byzantine and removed.
User
Applications
Attestation Update Code Update
Server
Enclave Type 2 Enclave Type 1
Mutual Attestation
Enclave Type 3
Revocation List Update
…
Enclave Type 4
Fig. 2: Overview of TeeDAO services. challenges, i.e., evidence-driven autonomous management: and proactive secret maintenance, as presented in Sec. I. The central consistency requirement is that a node’s authority to participate in consensus, store a secret share, and contribute to MPC must be derived from the same certified configuration. Otherwise, reconfiguration may remove a compromised TEE from the committee while leaving stale shares or computation authority inconsistent with the new membership. To address these issues, TeeDAO, a long-running distributed-trust service framework built atop a committee of heterogeneous TEE-equipped servers, is proposed. It aims to tolerate the compromise of some TEE implementations over time and support evidence-driven committee reconfiguration without a trusted human operator. Besides, TeeDAO is designed to expose a minimal, uniform API surface for building various confidential services (as discussed in Sec. VII). A. System Model
C. Security Goals
TeeDAO comprises four entities, as shown in Fig. 2. • TEE committee. A committee of n servers runs the TeeDAO runtime inside enclaves. We use ei to denote the enclave node hosted on server i. Each enclave e has a TEE type type(e) and an attestation-derived trust status status(e). The committee maintains replicated service state (including cryptographic secret shares and governance metadata) and collectively executes operations.
We formalize TeeDAO’s security through three properties: (i) Safety (Agreement + Linearizability), capturing the consistency of the replicated service; (ii) Liveness, ensuring service availability; and (iii) Proactive Secrecy, capturing confidentiality against adaptive adversaries.
• Clients. Clients invoke TeeDAO through its service APIs (e.g., storing/retrieving secrets, and requesting computations) to access developers’ applications. Each client request constitutes an operation. Here, application code and configuration updates (e.g., program logic, policies) should remain publicly inspectable/auditable by users or third-party monitors.
Definition 2 (Linearizability). TeeDAO satisfies Linearizability if the execution history of client operations is equivalent to a legal sequential history that preserves the real-time ordering of operations, consistent with the sequence of committed logs Logcfg0 , Logcfg1 , . . ..
Definition 1 (Agreement). TeeDAO satisfies Agreement if, for every configuration cfg, all correct committee members commit the same totally ordered log Logcfg .
Definition 3 (Liveness). TeeDAO satisfies Liveness if, assuming a partially synchronous network and a correct client, any valid operation submitted by the client is eventually committed, executed, and terminated.
• Hardware vendors. Vendors (or trusted disclosure channels) publish authenticated vulnerability disclosures and revocation lists RL for TEE implementations. TeeDAO consumes RL (together with attestation evidence) to update status(e) and guide reconfiguration decisions (e.g., removing nodes running revoked versions, allowing patched nodes to rejoin).
Definition 4 (Proactive Secrecy). TeeDAO satisfies Proactive Secrecy if the adversary’s view across multiple epochs is
4
TABLE I: Summary of notations.
computationally indistinguishable from a simulation that does not possess the secret inputs. Specifically, previously exposed shares in configuration cfgi do not reduce the entropy of secrets refreshed in configuration cfgj (where j > i). D. Challenges and Solutions Building a long-running distributed-trust system under the adaptive mobile adversary model presents unique challenges. We identify three primary challenges in eliminating centralized control, ensuring durability against cumulative compromise, and managing heterogeneity, alongside our proposed solutions. These challenges correspond to one lifecycle: evidence changes trust status, trust status changes membership, and membership changes where secret shares and MPC authority reside. Challenge-1: Removing central points of attack. In traditional distributed systems, critical operations, such as committee admission, revocation, and recovery, commonly rely on privileged administrator credentials. If these credentials are compromised, the adversary can manipulate committee composition and reduce the security of the distributed system back to central point of attack. Solution-1: Consensus-governed committee management using verifiable evidence. TeeDAO replaces administratordriven committee management with committee decisions agreed by the BFT consensus protocol. Committeemanagement actions (e.g., admission, revocation, and recovery) are expressed as consensus-ordered operations and are triggered by verifiable evidence, including authenticated vendor revocation lists/attestation evidence and protocol-level misbehavior evidence. Challenge-2: Guaranteeing adaptive, long-term security. Heterogeneity alone is insufficient for long-term security. Given enough time, distinct TEE implementations will inevitably suffer from the accumulated zero-day vulnerabilities. As described in our threat model, an adaptive mobile adversary [42]–[44] can sequentially compromise different nodes over time. Without a mechanism to invalidate past breaches, the adversary can accumulate secret shares across different configurations until the threshold is reached, eventually recovering the full secret. Solution-2: Proactive share refresh and recovery tied to reconfiguration. TeeDAO binds secret maintenance to committee reconfiguration. When nodes are removed (e.g., due to revocation or detected compromise), TeeDAO refreshes/reshares secrets among the remaining members so that previously exposed shares become useless. When recovered/patched nodes are admitted, TeeDAO establishes fresh shares consistent with the new membership, mitigating long-term share accumulation. Challeng-3: Supporting diverse confidential services. To facilitate the development of distributed trust systems that support various applications, including encrypted key-value store [47]–[49], cryptocurrency wallets [50], [51], multi-party collaborative analytics [52]–[55], it is also challenging to design unified interfaces capable of accommodating diverse
Term
Description
Term
Description
n t ei isValid() status(e) RL p
Committee size Compromise threshold Committee enclave Admissibility predicate Trust status Revocation list Governance proposal
Logcfg Committed log Certcfg (x) Commit certificate Hetero(cfg) Type-count bound type(e) TEE type σcfg Governance state hcfg Code digest cfgi Configuration
storage and computational operations on long-term distributed secrets. Solution-3: Unified service APIs. TeeDAO provides a consistent abstraction layer with minimal APIs (e.g., write/read/execute interfaces) that abstracts away heterogeneity, reconfiguration, and protocol details, enabling multiple services to share the same distributed-trust framework. E. Primitives and Building Blocks This section introduces the primitives and building blocks used. We also list the corresponding notations in Table I. Committee and Configurations. We assume a partially synchronous network model, where messages between honest nodes are delivered within a bounded delay after an unknown Global Stabilization Time (GST). This assumption is widely used in BFT protocols [56], [80], [84], [85]. Nodes communicate via authenticated point-to-point channels (e.g., TLS). The system evolves through a sequence of configurations, denoted as cfg0 , cfg1 , . . .. For each configuration cfg, TeeDAO maintains a common governance state σcfg that includes the membership, governance rules, and the approved code digest hcfg needed to validate and execute actions. Committee management is expressed as governance proposals p. A proposal is admissible in configuration cfg only if isValid(p, σcfg ) holds, including checks driven by evidence (e.g., RL, attestation), policy, and the heterogeneity constraint Hetero(cfg). Ordered Operations and APIs. Both client requests and governance actions are represented as operations and are totally ordered by a BFT replication protocol. Within each configuration cfg, committee members agree on the committed operation log Logcfg and execute operations in that order. We write Certcfg (x) for a commit certificate that operation is committed under cfg (e.g., a QC or threshold signature), which is used to justify committed operations and configuration transitions. Each API invocation returns a return code rc indicating success/failure of the request. Building Blocks and Their Assumptions. We instantiate TeeDAO using established cryptographic and distributed building blocks. Specifically, we employ HotStuff [56] for consensus, standard ECDSA signature for certificates, Shamir’s Secret Sharing (SSS) [71] augmented with Feldman’s VSS [86] for verifiable secret sharing, and MP-SPDZ [58] for MPC computation. Our analysis relies on their standard properties: (A1) BFT safety and liveness. The underlying consensus protocol (e.g., HotStuff) guarantees that correct nodes commit
5
consensus-governed management (Solution-1). Admission, revocation, quarantine, and recovery are expressed as ordered governance operations, producing an agreed configuration sequence. Using the evidence model from Sec. III-B, the DAO layer can quarantine suspected nodes and remove revoked nodes according to policy, making membership and authorization changes auditable and collectively agreed.
Application Key-value Store Crypto Wallet Private Analytics
DPSS
MPC
Consensus
Secure Hardware
Protocol Layer
• Protocol Layer (§IV-D). The Protocol layer runs storage and computation protocols over the DAOmanaged committee. It exposes a minimum, consistent API (write/read/execute interfaces) for services such as KVS, cryptocurrency wallets, and private analytics (Solution-3). To preserve long-term security against a mobile adversary, protocol state maintenance is tied to reconfiguration: when the DAO layer changes the committee (e.g., due to revocation or admission), the Protocol layer performs the corresponding refresh, resharing, or recovery procedure (Solution-2).
DAO Layer
Physical Layer
Fig. 3: A three layer architecture of TeeDAO. a unique, totally ordered log (i.e., safety) and make progress during periods of synchrony (i.e., liveness), provided n ≥ 3t + 1. (A2) Certificate unforgeability. The signature scheme is unforgeable under chosen-message attacks (EU-CMA). The adversary cannot forge a valid commit certificate Certcfg (x) without the secret keys of a quorum of committee members.
B. Physical Layer The Physical layer establishes hardware-rooted identities for heterogeneous TEE nodes and produces attestation reports for the upper layers. It exports a uniform node abstraction in which each node identity is bound to the authorized TeeDAO runtime and to a vendor-authenticated platform security version.
(A3) DPSS correctness and secrecy. The secret sharing scheme ensures that: (i) any set of t + 1 valid shares can reconstruct the secret; (ii) any set of ≤ t shares reveals no information about the secret; and (iii) shares refreshed via proactive resharing are independent of previous shares.
Interfaces to DAO Layer. For each enclave e, the Physical layer exports a type label type(e) identifying its trust domain and an attestation-derived trust status status(e). TeeDAO uses three trust statuses. A Trusted enclave presents fresh, verifiable attestation evidence that binds an enclave-generated public key to the approved code digest and to a non-revoked platform version. A Revoked enclave is associated with evidence of an unauthorized code digest or a vulnerable platform version. An Expired enclave cannot provide sufficiently fresh and verifiable evidence, for example, because the relevant vendor-authenticated security information is missing or stale. These signals feed the DAO-layer admissibility predicate isValid(·, σcfg ) and drive membership management.
(A4) MPC correctness and security. MPC protocols (e.g., MP-SPDZ) provides privacy and correctness against up to t malicious parties. (A5) Heterogeneous independence. Vulnerabilities in distinct TEE implementations are uncorrelated. IV. T E E DAO F RAMEWORK A. Architectural Overview Fig. 3 gives an overview of the TeeDAO framework. TeeDAO follows a three-layer design consisting of the Physical, DAO, and Protocol layers. The layers separate hardwarerooted trust establishment, consensus-governed committee evolution, and confidential services supporting. This separation allows TeeDAO to use heterogeneous TEEs as committee members while keeping membership changes auditable and binding protocol state maintenance to the resulting configuration sequence. We briefly introduce each component below and describe them in detail in the following subsections. • Physical Layer (§IV-B). The Physical layer provides a uniform abstraction for committee members running on heterogeneous TEEs. It derives each member’s trust status from vendor attestation and authenticated vulnerability or revocation information. These trust signals serve as evidence for higher-layer governance decisions in heterogeneous deployments (Solution-1).
TEE Abstraction. We treat heterogeneous TEEs as a uniform abstraction as long as they provide the following primitives: • Attestation. An attestation report binds the enclave measurement, the reported Trusted Computing Base (TCB) version, and an enclave-generated public key used to authenticate subsequent protocol messages. • Isolation. An uncompromised enclave can protect its runtime state from a compromised host OS or hypervisor. • Revocation Lists. Each trust domain publishes authenticated information identifying revoked or vulnerable platform versions (revocation lists, TCB information, or equivalent). We denote this input as RL. To verify attestation reports and RL, enclaves pin vendor verification material (e.g., root certificates or public keys) as part of the certified configuration metadata (carried in σcfg ).
• DAO Layer (§IV-C). The DAO layer replaces administrator-controlled committee management with
6
Mutual Attestation. Given the attestation abstraction deAlgorithm 1: Committee management for comproscribed above, the system must ensure that only uncompromised and recovered members mised TEEs can participate in the protocol. Mutual attestaStep 1: Discover suspect nodes tion [87] provides this guarantee: two enclaves verify each Method 1. status update other’s identity by checking their measurements and software 1. Leader compares type(e) of active members with RL. versions, thereby excluding enclaves running untrusted or 2. Adds nodes in RL to listsusp . tampered code. Method 2. rules violation foreach ei do Leader-based trust-chain attestation. A naı̈ve deployment Submit evidence evidi = {msgi , sigi } and violated would require every pair of the n enclaves to attest to each 3. rules r in accusation acci = {i, evidi , r} to leader. other, resulting in O(n2 ) attestations during initialization. To Leader assesses accusation, verifies message make the process scalable, we adopt a leader-based trust-chain 4. authenticity and rule violation using attestation while keeping verification fully decentralized: verif y(msgi , sigi ) and verif y(msgi , r). • Report generation. When a node joins or refreshes its status, if verification is true then it generates an ephemeral public key inside the enclave and 5. Add accused node to listsusp . produces an attestation report that binds this key to the TeeDAO runtime digest, the reported TCB version, its TEE type, and a freshness proof such as a timestamp or nonce. 6.
else Add accusing member to listsusp .
• Verification against configuration policy. The designated Step 2: propose removal of suspect nodes leader enclave and members can mutually verify each other’s 7. Leader broadcasts a removal proposal p containing report using the pinned vendor roots and the latest available listsusp and supporting evidence. RL for the corresponding enclave. A report is accepted Step 3: admit patched nodes only when the attested code digest matches the governance8. Leader attests the requesting node and broadcasts an approved digest hcfg , the reported security version is not admission proposal p. revoked by the relevant RL, and the freshness proof falls foreach ei do within the accepted window. 9. Attest the requesting node and vote for p only if Once trust is established, the leader aggregates all attestathe attestation report is valid tion results and broadcasts a system-wide attestation report. This evidence is incorporated into governance proposals and becomes a committee membership decision through the DAO vatively quarantine nodes whose trust cannot be validated. layer’s ordered execution and admissibility checks. A compromised leader cannot unilaterally admit an untrusted node. Admission proposals must carry the attestation report for each candidate enclave and the digest of the referenced vendor revocation list. Every member can therefore re-verify the report signature against pinned vendor roots and local policy. If the leader equivocates, omits required evidence, or proposes a node that fails verification, correct members reject the proposal; the protocol then times out and selects a new leader.
C. DAO Layer The DAO layer provides consensus-governed committee management. It replaces administrator-driven control with an auditable, rule-based workflow that turns TEE trust signals and protocol-level evidence of misbehavior into consensus-backed membership and policy decisions. These decisions advance the system through a configuration sequence cfg0 , cfg1 , . . . and expose an externally verifiable record of governance actions. Interfaces to Protocol Layer. The DAO layer exports the current configuration cfg, commit certificates for governance actions and configuration transitions, and the replicated governance state σcfg . The configuration identifies the current member set and certified metadata. A certificate Certcfg (·) attests that an action or transition was committed in the ordered log Logcfg . The governance state records the active rule set, membership metadata, group verification key MPK, approved code digest hcfg , and current phase. The Protocol layer treats a governance action as effective only when it is accompanied by a valid certificate and runs configuration-triggered refresh or recovery procedures only for committed transitions.
Timely Status Refresh. Attestation does not detect unknown zero-day vulnerabilities. Instead, TeeDAO targets timely reaction once vendor-authenticated security information becomes available. We adopt two optimizations for a timely refresh: i) Periodic refresh. Each enclave periodically fetches the latest RL (through the untrusted host but verified inside the enclave) and re-evaluates active peers’ reported security versions. ii) Event-driven refresh. Any enclave that observes a newer vendor-authenticated RL than the one referenced by the current configuration may submit evidence to the leader when that update marks an active member as Revoked. The leader then broadcasts a governance proposal so that the committee can adopt the update consistently. If an enclave’s status cannot be refreshed within a bounded staleness window, the enclave marks status(e) = Expired, allowing DAO policy to conser-
Governance State and Proposals. In each configuration cfg, the committee maintains a deterministic governance state σcfg . Committee-management actions are expressed as proposals p, covering actions such as removal, quarantine, and admission.
7
A proposal is admissible only when isValid(p, σcfg ) holds. This predicate captures the DAO layer’s rule-based policy by checking authorization, attached evidence, and the heterogeneity constraint Hetero(cfg).
by binding membership and share movement to attestationderived trust signals and Hetero(cfg). Interfaces to the Application. This layer exposes three application interfaces. A client calls write(k, v, md) → rc to store or update a secret value v under key k with metadata md. It calls read(k) → (v, md, rc) to retrieve the value and metadata associated with k. It calls execute(code, args) → (out, rc) to run an approved computation over secret-shared state. The return code rc reports the protocol-level outcome and is distinct from the attestation-derived trust status of an enclave. SUCCESS means that the request was committed and certified. NOTFOUND means that the requested key is absent. RECONFIG indicates that the service is temporarily unavailable because the committee is reconfiguring. ABORT indicates that an inconsistency or malicious behavior was detected during protocol execution. For every SUCCESS response, the client obtains a certificate Certcfg (·) binding the result to Logcfg . The client accepts the response only if the certificate verifies under MPK and configuration.
Evidence and Rule-based Enforcement. We next describe the inputs for isValid(·) and rule-based detection. The DAO layer consumes two classes of evidence: • Physical layer trust signals. Namely, each node’s type label type(e), its attestation-derived statusstatus(e), and authenticated vendor security updates such as RL. These inputs determine whether a node remains trusted, has become revoked, or should be treated as expired. • Protocol-level misbehavior evidence. When a member observes misbehavior, it can submit a signed evidence bundle evidi = {msgi , sigi } and an accusation acci = {i, evidi , r} identifying the violated rule r in σcfg . Members process these inputs according to governance policy and update the suspect set listsusp . Consensus-ordered Governance. Evidence becomes effective only after it is turned into a committee decision. All governance actions are executed via the same consensus-ordered workflow: proposals are broadcast, totally ordered, and applied identically by correct nodes to advance from cfg to cfg′ . Algorithm 1 summarizes this workflow for suspect discovery, removal, and admission: • Discover suspects. The leader collects and validates evidence (status updates and accusations) and derives a candidate management action (e.g., remove or admit).
Protocol State and Authenticated Membership. Each member enclave ei maintains a protected state γi . This state contains a key-value table whose per-key records have the form ⟨k, vi , ci ⟩, where vi is a Shamir share of v and ci is a commitment used to detect malformed shares. It also contains the current protocol phase specified by σcfg . All protocol messages are carried over mutually authenticated channels established through Physical-layer attestation. Each received message is therefore attributable to a member identity in cfg, together with its recorded TEE type and trust status.
• Propose an action. The leader packages the intended action as a proposal p with the evidence required for isValid(p, σcfg ).
Normal-phase Operations. TeeDAO stores each secret value v as a degree-t Shamir sharing across the n members in cfg. During the Normal phase, the committee first orders each request in Logcfg and then executes the corresponding DPSS or MPC procedure inside enclaves. The protocol returns SUCCESS only after the request is committed and certified. As shown in Fig. 4, TeeDAO supports three operations. • For write, members store their received record ⟨k, vi , ci ⟩ in γi , and the protocol reports success only after the operation is committed under cfg.
• Order and commit. The committee orders p in Logcfg , producing Certcfg (p), after which all correct members apply p identically to obtain σcfg′ and a new configuration cfg′ . Because every effective governance change must be both admissible and committed, neither a member nor a leader can unilaterally change membership or policy. Lifecycle Phases. The DAO layer also exposes a phase flag phase ∈ {Normal, Reconfig} as a coordination signal. During Normal, the system provides the full service under the current configuration. When a committed governance decision installs cfg′ (e.g., after removal or admission), the system enters Reconfig. The Protocol layer then executes the refresh, resharing, or recovery procedure required by the new configuration. Once those procedures are complete under cfg′ , the system returns to Normal.
• For read, the client collects responses containing (vi , ci , md) for key k. Each response is bound to a committed version through Certcfg (·) that the client can validate. The client discards invalid shares using the commitments {ci } and reconstructs v from any t + 1 valid shares, which is the threshold needed to interpolate a degree-t sharing. If the key is absent, the protocol returns NOTFOUND.
D. Protocol Layer
• For execute, members run an actively secure MPC computation over their shares and any public inputs, and return a certified output Certcfg (reqID, out, ℓ), where ℓ is the committed log position of the operation. 1) Data Management Protocol: To defend against an adaptive mobile adversary, secrets in TeeDAO must remain protected even when the adversary moves between enclaves over time. The Protocol layer therefore couples COBRA DPSS [44]
The Protocol layer turns a DAO-installed configuration cfg into an application-facing confidential service. It stores secrets using DPSS and executes computations over those secrets using MPC. Every protocol outcome is configurationdependent: requests are ordered in Logcfg and returned with a certificate verifiable under the group verification key MPK. This design maintains security across heterogeneous TEEs
8
Read
Write Share
Store
Enclave Storage
Compile
Deploy
Enclave Execution
Execute Request
Enclave Storage
Enclave Storage
Enclave Storage
…
Request Share
… Retrieval Share
Enclave Execution
…
Enclave Storage
Enclave Execution Retrieval Share
This prevents unauthorized computations from running inside the committee. The threat model allows compromised enclaves as well as host and network interference. TeeDAO therefore cannot rely on semi-honest behavior. It uses actively secure MPC over Shamir sharing, such as protocols proposed by Lindell and Nof [88], with consistency checks and degree-reduction steps that preserve correctness in the presence of up to t Byzantine parties3 . If a computation aborts because of a detected inconsistency, members generate signed evidence bundles evidi that can be submitted to the DAO layer as accusations. The DAO layer can then add nodes to the suspect set and trigger reconfiguration according to policy.
Enclave Storage
Result
Enclave Execution
Fig. 4: Interfaces of TeeDAO. maintenance to the DAO-driven configuration lifecycle. When the DAO commits a membership-changing proposal, such as removal, admission, or readmission, it moves the system into Reconfig and installs a new configuration cfg′ . The Protocol layer starts DPSS maintenance during this reconfiguration window because the set of share holders is changing and share movement must follow the new membership and heterogeneity constraints. Concretely, the protocol runs distributed polynomial generation (DPG) to sample a fresh degree-t zerosharing polynomial for refresh or a resharing polynomial for the new configuration. • Secret resharing. To move existing secrets to the new membership set, the committee runs COBRA-style dynamic resharing. Each remaining member contributes a verifiable rerandomization term, producing shares that remain consistent with the same underlying secret but are now held by members of cfg′ . Confidentiality is preserved because the adversary controls at most t enclaves at any time, and correctness is enforced through commitments and consistency checks.
Certified Outputs and Auditing. Upon successful completion, participating members produce a certified output for the client. Members sign, or provide signature shares for, the tuple (reqID, out, cfg, ℓ), where ℓ is the log position of the committed execute operation. The client accepts out only if it verifies the corresponding certificate Certcfg (reqID, out, ℓ). The certificate also supports post-hoc auditing: if an enclave is later marked vulnerable through a status update, clients and auditors can identify outputs certified during the affected configuration window and inspect which transactions depended on the affected committee. V. S ECURITY A NALYSIS A. Safety Analysis Theorem 1 (Safety). Under (A1–A2), TeeDAO satisfies Agreement (Def. 1) and Linearizability (Def. 2). Proof. We prove the following properties by combining the assumed security guarantees of the underlying building blocks (Sec. III-E) with TeeDAO ’s design. • Agreement. Given a configuration cfg. By (A1), correct committee members commit a unique totally ordered log Logcfg . This is exactly Def. 1.
• Proactive refresh. Even without a membership change, the committee periodically or policy-triggeredly refreshes shares by adding a freshly generated degree-t zero-sharing polynomial to the current sharing. This invalidates shares that may have been exposed earlier. The DPG used for refresh is executed inside enclaves and tied to the DAO log so that all correct members refresh the same version.
• Linearizability. Consider an operation op that returns SUCCESS. By the protocol interface, a successful completion is justified by a commit certificate Certcfg (op) for some configuration cfg. By (A2), such a certificate implies that op is committed under cfg, hence appears at a unique position in Logcfg . Define the linearization point of op to be this commit position in the global sequence consistent with the committed logs Logcfg0 , Logcfg1 , . . .. This yields a single sequential history consistent with the committed logs and preserving non-overlap completion order, establishing Def. 2.
• Secret recovery. When a removed enclave is patched and readmitted, it no longer has a valid current share. The protocol runs share recovery so that the recovering enclave obtains helper contributions from other members and reconstructs its own new share under cfg′ . Commitments provide verifiability, and the secret v is never reconstructed in the clear. During the Reconfig phase, clients may receive return code RECONFIG and retry after cfg′ has been installed. 2) Decentralized Computation Protocol: To support general-purpose computation over secret-shared state, TeeDAO executes MPC over DPSS-stored shares. An application deploys each computation as a code artifact identified by its digest. The DAO layer governs which artifacts are admissible through σcfg , in particular through the approved code digest hcfg . An execute(code, args) request is accepted only when the code digest matches hcfg or otherwise satisfies the admissibility rule encoded by isValid(·, σcfg ).
Configuration soundness. The above safety guarantees hold when configuration changes cannot bypass governance rules: A correct node applies a reconfiguration only if it is both committed and admissible under the current governance state. 3 TeeDAO can also be viewed as an enhancement of a pure MPC system, as discussed in Appendix A.
9
Lemma 1 (Only committed and admissible proposals take effect). If a correct node applies a governance proposal p while in configuration cfg, then (i) Certcfg (p) exists, and (ii) isValid(p, σcfg ) holds at the time of application.
VI. P ERFORMANCE E VALUATION We evaluate TeeDAO from three primary service abstractions: KVS, system membership management, and MPC computation. To provide a comprehensive assessment of system performance, we select the state-of-the-art BFT SMR system, HotStuff [56], as the baseline and conduct a comparative analysis with COBRA [44], a cutting-edge BFT SMR system with confidentiality protection. Our evaluation aims to answer the following questions: • (Q1) KVS Performance: How does TeeDAO perform as a key-value storage service versus traditional BFT SMR systems? (§VI-B)
Proof. Correct nodes apply state transitions only for committed log entries; thus p must be in Logcfg and justified by Certcfg (p) (A1–A2). The governance transition checks isValid(p, σcfg ) before applying p by definition of admissibility, so (ii) holds. Corollary 1 (Installed configurations satisfy heterogeneity). For every installed configuration cfg, Hetero(cfg) holds. Proof. Any membership/configuration update is applied only if admissible (Lemma 1). Since Hetero(·) is enforced inside isValid(·, σcfg ), the resulting installed configuration satisfies Hetero(cfg).
• (Q2) Membership Management Overhead: What is the performance overhead of membership management, including system reconfiguration and member recovery? (§VI-C) • (Q3) Computation Task Efficiency: How efficiently does TeeDAO perform computation tasks, including AES encryption, simple graph search algorithms, and machine learning, under varying numbers of nodes? (§VI-D)
B. Liveness Analysis Theorem 2 (Liveness). Under (A1, A3, A4, A5), TeeDAO guarantees that valid client requests are eventually committed and executed.
• (Q4) Heterogeneous TEE Deployment: How does TeeDAO perform under mixed deployments spanning different TEE implementations? (§VI-E)
Proof. Liveness requires physical node availability, consensus progress, and data reconstructability. First, by (A5), the heterogeneity constraint prevents common-mode failures from compromising > t nodes, guaranteeing that a quorum of 2t + 1 correct nodes always exists. Second, by (A1), HotStuff overrides leader omission faults to ensure transaction ordering at the protocol layer; by (A3 and A4), the threshold sharing scheme ensures that the valid committee size of 2t + 1 is strictly larger than the reconstruction threshold t + 1, guaranteeing DPSS reconstruction and MPC execution. Finally, the DAO layer executes reconfiguration to replace persistently unresponsive nodes, preserving the resilience conditions for the layers above, and satisfying Def. 3.
A. Implementation and Experiment Setup Implementation. We implement a prototype of TeeDAO atop several commodity TEE implementations, i.e., Intel SGX, Intel TDX, and Hygon CSV, with the latest DPSS techniques, COBRA [44], and the versatile MPC compiler MP-SPDZ [58]. We implement COBRA with linear secret sharing from scratch atop HotStuff [89]. We also add functionality to adapt the secret sharing storage format to the Montgomery representation of MP-SPDZ for computation. The whole system comprises a total of 10,353 lines of C++ code. Experiment Setup. We evaluate the performance of TeeDAO in two VM-based TEEs (i.e., Intel TDX and Hygon CSV) and process-based TEEs (i.e., Intel SGX). TeeDAO uses Intel Xeon Platinum 8369B CPU (2.7GHz) as Intel SGX platforms, Intel Xeon Emerald Rapids CPU (2.7GHz) for Intel TDX platforms, and Hygon C86-3G 7390 CPU (3.0 GHz) for Hygon CSV. For comparison, COBRA and HotStuff are deployed on a standard server equipped with an Intel Xeon Platinum 8575C CPU (3.2GHz). All platforms are configured with 8 vCPUs and 32GB of RAM, running a Linux kernel version above v5.10. The Intel SGX platform is configured with SGX v2.0 and 16GB of physical memory (maximum EPC 16GB). The experiments were conducted in a controlled environment with a round-trip time (RTT) of 0.05–0.07ms and a bandwidth of 5 Gbps, representing a common deployment scenario for TeeDAO in cloud data centers. All protocols are evaluated under identical settings. Each request carries a 1024-byte payload, and the consensus batch size is set to 400. For secret sharing, both COBRA and TeeDAO use Feldman’s linear commitment scheme [86]. We conduct three sets of experiments to address the questions
C. Proactive Secrecy Analysis Theorem 3 (Proactive secrecy). Under (A2–A4), TeeDAO satisfies Proactive Secrecy (Def. 4). Proof. Fix two executions that induce the same committed logs Logcfg0 , Logcfg1 , . . . and the same API outputs, but differ in the underlying plaintext secrets and private inputs. We show that the adversary’s views are computationally indistinguishable. For each MPC invocation (the execute interface), by (A4) there exists a simulator producing a computationally indistinguishable view given only the public committed information and the output. For secret-shared values used for storage and computation, within any configuration at most t shares can be exposed at any time, so they reveal no information about the plaintext; across configurations, whenever a reconfiguration refreshes shares, previously exposed shares do not help recover secrets in later configurations by (A3). Therefore, conditioned on the same committed logs and the same API outputs, the adversary’s entire view is indistinguishable between the two executions, establishing Def. 4.
10
200 00
400 200
2
4
6 8 10 Throughput (kTPS)
00
12
(a) COBRA (Write)
20 10 20 40 Throughput (kTPS)
(d) COBRA (Read)
400
20
40 60 80 Throughput (kTPS)
00
100
(b) HotStuff (Write) 4-Node 10-Node 25-Node 46-Node 61-Node
30
600
200
60
40 Latency (ms)
Latency (ms)
40
0 0
Latency (ms)
400
600
20 10 100 200 Throughput (kTPS)
10
20 30 40 Throughput (kTPS)
50
60
(c) Ours (Write) 4-Node 10-Node 25-Node 46-Node 61-Node
30
00
TDX-4-Node TDX-10-Node TDX-25-Node TDX-46-Node TDX-61-Node SGX-4-Node SGX-10-Node SGX-25-Node SGX-46-Node SGX-61-Node
800
300
40 Latency (ms)
Latency (ms)
600
4-Node 10-Node 25-Node 46-Node 61-Node
800 Latency (ms)
4-Node 10-Node 25-Node 46-Node 61-Node
800
TDX-4-Node TDX-10-Node TDX-25-Node TDX-46-Node TDX-61-Node SGX-4-Node SGX-10-Node SGX-25-Node SGX-46-Node SGX-61-Node
30 20 10 00
(e) HotStuff (Read)
50
100 150 Throughput (kTPS)
200
(f) Ours (Read)
Fig. 5: Write and read throughput/latency. TABLE II: Reshare latency (s) for storage with 1K entries.
outlined above. We focus on Intel TDX and SGX for direct comparison, and defer the evaluation of CSV to Appendix B due to space constraints. B. KV Storage Performance To address Q1, we evaluate the performance of TeeDAO as a KVS in terms of write and read requests. Write requests. Fig. 5.a-c presents the latency and throughput of three systems given write requests of 1KB secret data with 4 to 61 nodes. The results indicate that HotStuff achieves the highest throughput as it does not perform secret-sharing. Specifically, as the number of nodes increases from 4 to 61, HotStuff’s throughput declines from 81 kTPS to 12 kTPS. In comparison, TeeDAO-TDX outperforms TeeDAO-SGX, benefiting from the larger computing memory provided by TDX VMs and its support for para-virtualization and SR-IOV [90]. At n = 4, TeeDAO-TDX achieves 54% of HotStuff’s throughput, while TeeDAO-SGX achieves 47%. COBRA exhibits the lowest throughput, primarily due to the higher complexity of its consensus protocol and the overhead introduced by frequent locking in its implementation. For instance, at n = 4, COBRA achieves only 9 kTPS, which is 11% of HotStuff’s throughput. With an increasing number of nodes, the overhead introduced by TEEs causes TeeDAO’s throughput to decline more rapidly than that of the other systems. At n = 61, TeeDAO-TDX achieves 20% of HotStuff’s throughput, while TeeDAO-SGX achieves 18%. Nevertheless, both TeeDAO-TDX and TeeDAO-SGX significantly outperform COBRA. Specifically, TeeDAO-TDX achieves a throughput 1.8 times higher than COBRA, while TeeDAO-SGX achieves 1.6 times higher.
System
Metric
n=4
n = 16
n = 25
n = 31
TDX
Poly. Gen. State Recon.
1.899 0.466
10.296 1.345
21.845 2.546
32.392 3.763
SGX
Poly. Gen. State Recon.
3.652 0.503
17.209 1.412
33.685 2.807
45.469 4.243
COBRA
Poly. Gen. State Recon.
3.970 0.963
11.591 1.150
21.343 1.573
30.382 1.680
requests. The throughput of TeeDAO-TDX and TeeDAO-SGX ranks second only to HotStuff and consistently outperforms COBRA. Unlike write operations, read operations do not involve consensus protocols, so I/O overhead and secret-share combination become the dominator. The experimental results show that as the number of nodes increases from 4 to 61, HotStuff’s throughput decreases from 240 kTPS to 23 kTPS. Due to the lower communication and computational complexity of read operations, TeeDAO-SGX and TeeDAO-TDX achieve nearly identical performance. When n = 4, both TeeDAO-TDX and TeeDAO-SGX achieve 45% of HotStuff’s throughput, while COBRA achieves only 19%. However, as the number of nodes increases, the I/O overhead introduced by TEEs significantly impacts performance. When n = 61, the throughput of TeeDAO-TDX and TeeDAO-SGX decreases to 1.5 kTPS, slightly higher than COBRA’s throughput of 0.9 kTPS. C. Management Cost To address Q2, we evaluate the system management cost, including two key operations: polynomial generation during consensus for reconfiguration and secret state reconstruction. We measure the cost of adding (recovery) and removing (reconfiguration) a server from a system containing 1K secret data entries, with configurations ranging from 4 to 31 nodes.
Read requests. Fig. 5.d-f illustrates the latency and throughput of read requests, which follow a similar trend to write
11
0
10
20
Number of replicas
30
(a) Reconfiguration Cost
Vanilla-4-Node
COBRA Ours-TDX Ours-SGX
15 10 5
10
20
Number of replicas
Vanilla-7-Node
Ours-4-Node
Ours-7-Node
2.0 Ratio
20
COBRA Ours-TDX Ours-SGX
Latency (s)
Latency (s)
40
1.5 1.0
30
0.5
(b) Recovery Cost
Fig. 6: Reconfiguration and recovery latency.
AES
Logistic Linear Sum of SecureNN regression regression products
Dijkstra
Fig. 7: Normalized computational cost. TABLE IV: Heterogeneous committee performance.
TABLE III: Recovery latency (s) for storage with 1K entries. System
Metric
n=4
n = 16
n = 25
n = 31
System n Write (kTPS/ms) Read (kTPS/ms) Recovery (s) Reconfig. (s)
TDX
Poly. Gen. State Recon.
1.026 0.179
4.606 0.411
9.788 0.845
14.414 1.265
SGX
Poly. Gen. State Recon.
1.665 0.305
5.128 1.011
10.226 1.947
14.620 2.890
SGX CSV 4 TDX Hetero
20.2/71.1 22.5/64.1 36.1/54.5 25.1/70.4
115.1/8.0 120.1/3.6 122.8/5.3 121.0/5.8
1.970 2.133 1.205 1.731
4.155 4.078 2.365 3.251
COBRA
Poly. Gen. State Recon.
2.267 0.268
4.311 0.736
8.004 1.308
11.347 1.652
SGX CSV 7 TDX Hetero
14.4/119.6 18.4/85.6 33.5/64.3 20.7/79.0
57.4/2.6 61.7/4.3 62.7/1.9 61.2/2.0
2.600 3.262 1.879 2.586
7.208 7.513 4.221 5.541
D. Computation Overhead
Since HotStuff does not provide confidentiality protection, our evaluation focuses on comparing TeeDAO and COBRA.
To address Q3, we compare TeeDAO-TDX with vanilla MPC using Shamir’s secret sharing protocol under both malicious adversary and honest majority models. Fig. 7 presents a normalized comparison of computation time between TeeDAO and vanilla MPC, using the computation time of vanilla MPC with n = 4 as the baseline. The experiment evaluates both systems under n = 4 and n = 7, leveraging benchmark tasks provided by the MP-SPDZ library [58]. These tasks include AES encryption, Logistic Regression, Linear Regression, Sum of Products, SecureNN, and the Dijkstra algorithm. The results demonstrate that TeeDAO introduces low additional latency for most computation tasks, indicating acceptable performance overhead. Specifically, for tasks such as SecureNN and Sum of Products, TeeDAO incurs negligible overhead. For other tasks, such as AES encryption and the Dijkstra algorithm, the performance overhead remains below 10%. Although the overhead for Logistic Regression is slightly higher, it is still controlled within 18%. These data indicate that TeeDAO introduces relatively low performance overhead, even for computationally intensive tasks, making it a practical solution for secure collaborative computation.
Reconfiguration latency. Fig. 6a presents the reconfiguration latency. When there are fewer than 22 nodes, TeeDAO-TDX outperforms COBRA in shorter latency, while TeeDAO-SGX achieves lower overhead than COBRA only when n = 4. This performance advantage is attributed to TeeDAO’s foundation on HotStuff, which has lower protocol complexity compared to the BFT-SMaRt system used by COBRA [91]. Specifically, when n = 4, TeeDAO-TDX achieves 47% of COBRA’s reconfiguration latency, and TeeDAO-SGX achieves 84%. When the number of nodes increases, the I/O overhead introduced by TEEs significantly impacts TeeDAO’s performance. Table II shows that the time required for polynomial generation increases significantly with the number of nodes, surpassing that of COBRA. Moreover, the growth rate of TeeDAO-SGX is faster than that of TeeDAO-TDX. When n = 22, the reconfiguration latency of TeeDAO-TDX begins to exceed that of COBRA. Recovery latency. Fig. 6b illustrates the recovery latency for a faulty node in clusters containing 4 to 31 nodes. The results show that when the number of nodes is fewer than 16, TeeDAO-TDX achieves a shorter recovery time compared to COBRA. Additionally, TeeDAO-SGX slightly outperforms COBRA when the number of nodes is fewer than 13, while still exhibiting higher recovery latency than TeeDAO-TDX. However, as the number of nodes increases, COBRA gradually outperforms both TeeDAO-TDX and TeeDAO-SGX.
E. Performance under Heterogeneous TEEs To address Q4, we further evaluate TeeDAO under mixedTEE deployments. The 4-node committee contains one SGX, one CSV, and two TDX nodes, while the 7-node committee contains two SGX, two CSV, and three TDX nodes. These TEEs differ substantially in their isolation models and virtualization architectures, allowing us to evaluate whether TeeDAO can operate efficiently across heterogeneous trust domains without protocol redesign. Table IV shows that heterogeneous deployment performance falls between the best homogeneous deployment (TeeDAO-TDX) and the slower homogeneous deployment
Table III shows that the polynomial generation time for TeeDAO increases rapidly with the increasing number of nodes, with TeeDAO-SGX exhibiting a faster growth rate than TeeDAO-TDX. At n = 31, the recovery latency of TeeDAO-TDX (resp. TeeDAO-SGX) is 20% (resp. 34%) higher than COBRA.
12
(TeeDAO-SGX). This behavior is expected because consensus, share maintenance, and reconfiguration involve all committee members, causing the slowest TEE type to partially determine the critical path. For example, TeeDAOHetero achieves 25.1 kTPS write throughput at n = 4 and 20.7 kTPS at n = 7, both remaining between TeeDAO-SGX and TeeDAO-TDX. Recovery and reconfiguration exhibit similar behavior. By contrast, read performance is less affected because reads do not require consensus.
on) to an older, valid state, leading to violation of state freshness/integrity guarantees. Distributed TEE nodes can assist one another in preserving the freshness of their states when not all TEEs are crashed. ROTE [97] distributes rollback protection across multiple SGX processors via a broadcast protocol, while Narrator [98]–[100] and Nimble [101] rely on a TEE-backed or blockchain-backed ledger to detect storage rollback. RR and its TEEMS metadata service [102] formalize the restart–rollback fault model and adapt crash-tolerant replication protocols to TEEs with external state. Achilles [103] realizes roll-back resilient recovery for consensus protocols.
VII. A PPLICATION C ASES We illustrate how TeeDAO supports common privacysensitive services by presenting three detailed cases of secret storage [92], [93], key custody/signing [94], [95], and crossorganization analytics [96].
Availability enhancement. TEE-replicated services execute consensus or application logic inside enclaves to enhance availability in the presence of faulty hosts: Engraft [104] protects Raft with SGX, and CCF [105] runs replicated services in TEEs backed by an auditable ledger. These systems largely assume that each TEE provides integrity and confidentiality guarantees, focusing on host crashes or protocol faults rather than complete TEE compromises.
Secret KV Store. Secret KV store provides APIs to store and retrieve secret values, often with versioning and rotation [92], [93]. It can be realized by TeeDAO by storing each item as proactively refreshed shares across a heterogeneous committee. A client can (i) upload a plaintext secret to an admitted enclave, which immediately shares it, or (ii) client-split into shares and upload only shares. Storage uses write(k, share); retrieval uses read(k) plus a policy-controlled reconstruction workflow that avoids concentrating a long-lived secret at any single replica, while allowing users to constrain which TEE types may hold shares.
Heterogeneous TEE systems for compromised TEEs. These systems assume a stronger adversary that may fully break a few particular TEE implementations and therefore distribute trust across different TEE types. Dauterman et al. [32] propose splitting cryptographic trust across independent hardware roots so that security holds as long as at least one root remains honest. Connell et al. [39] propose SVR3 for key recovery by storing users’ key material across Nitro, SEV-SNP, and SGX enclaves in different clouds. Existing systems cannot handle adaptive mobile adversaries. In contrast, TeeDAO provides a general framework to manage membership, resharing, and revocation of heterogeneous TEE committees for long-lived application state.
Multisig Wallet. For digital wallet and transaction signing, a widely deployed pattern is split-key authorization: control is distributed either via on-chain multisig wallets or via MPC custody services where the private key is never present in full and is represented by distributed shares [94], [95]. TeeDAO generalizes the split-key pattern to long-running, reconfigurable committees under heterogeneity constraints. The signing key is stored as shares (write); a signing request triggers an execute workflow where committee members produce signature shares inside admitted TEEs and the leader combines them into a full signature without reconstructing the private key. This supports proactive refresh and reconfiguration, which are not addressed by static multisig or single-domain KMSstyle custody.
Hybrid Systems of TEE and MPC. Several hybrid systems [106]–[109] combine TEEs and MPC to leverage the strengths of both paradigms. Specifically, prior work [106], [107] treats TEE-enabled nodes as semi-honest MPC parties, using TEE integrity guarantees to accelerate MPC. Later, Wu et al. [108] and Hu et al. [109] further adapt the division of tasks between TEE and MPC according to security and cost constraints. However, they do not consider compromised TEEs. In contrast, TeeDAO targets long-lived MPC services under a stronger threat model of adaptive mobile adversaries, tolerating full compromise of any TEE type and its host.
Privacy-Preserving Data Analytics. Cross-organization analytics increasingly use MPC-style designs to compute aggregates without sharing raw records, e.g., Google Private Join and Compute [96]. TeeDAO supports this as a stateful service: each party uploads data as shared state (write); an analytics job runs as an execute task compiled into an MPC protocol by the committee; outputs are released via read under policy. Compared with pure MPC deployments, TeeDAO provides a uniform interface and long-running committee management (admission by attested identity, heterogeneity constraints, and proactive refresh) as the platform layer.
IX. C ONCLUSION We propose TeeDAO, a three-layer framework that manages a committee of heterogeneous TEEs as a distributed-trust infrastructure for long-running confidential services. It also provides a minimal, uniform API surface to support various confidential computing services such as KVS, cryptocurrency wallets, and multi-party collaborative analytics services. Our experimental evaluation results reveal that TeeDAO achieved high efficiency in KV Store and management while imposing a reasonable overhead on system management and MPC computation execution.
VIII. R ELATED W ORKS Rollback resilience. In rollback attacks, an adversary reverts the enclave’s persistent state (or the external storage it relies
13
R EFERENCES
[27] S. Lee, M. Shih, P. Gera, T. Kim, H. Kim, and M. Peinado, “Inferring fine-grained control flow inside SGX enclaves with branch shadowing,” in Proc. of USENIX Security, 2017. [28] J. Lee, J. S. Jang, Y. Jang, N. Kwak, Y. Choi, C. Choi, T. Kim, M. Peinado, and B. B. Kang, “Hacking in darkness: Return-oriented programming against secure enclaves,” in Proc. of USENIX Security, 2017. [29] J. V. Bulck, N. Weichbrodt, R. Kapitza, F. Piessens, and R. Strackx, “Telling your secrets without page faults: Stealthy page table-based attacks on enclaved execution,” in Proc. of USENIX Security, 2017. [30] L. Wilke, F. Sieck, and T. Eisenbarth, “Tdxdown: Single-stepping and instruction counting attacks against intel TDX,” in Proc. of ACM CCS, 2024. [31] F. Rauscher, L. Wilke, H. Weissteiner, T. Eisenbarth, and D. Gruss, “Tdxploit: Novel techniques for single-stepping and cache attacks on intel TDX,” in Proc. of USENIX Security, 2025. [32] E. Dauterman, V. Fang, N. Crooks, and R. A. Popa, “Reflections on trusting distributed trust,” in Proc. of HotNets, 2022. [33] P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, “Spectre attacks: Exploiting speculative execution,” in Proc. of IEEE S&P, 2019. [34] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, J. Horn, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg, “Meltdown: Reading kernel memory from user space,” in Proc. of USENIX Security, 2018. [35] P. Jauernig, A. Sadeghi, and E. Stapf, “Trusted execution environments: Properties, applications, and challenges,” IEEE Secur. Priv., vol. 18, no. 2, pp. 56–60, 2020. [36] M. Li, Y. Yang, G. Chen, M. Yan, and Y. Zhang, “Sok: Understanding design choices and pitfalls of trusted execution environments,” in Proc. of the 19th ACM AsiaCCS, 2024. [37] A. D. Wood and J. A. Stankovic, “Denial of service in sensor networks,” Computer, vol. 35, no. 10, pp. 54–62, 2002. [38] Y. Zhou and D. Feng, “Side-channel attacks: Ten years after its publication and the impacts on cryptographic module security testing,” IACR Cryptol. ePrint Arch., p. 388, 2005. [39] G. Connell, V. Fang, R. Schmidt, E. Dauterman, and R. A. Popa, “Secret key recovery in a global-scale end-to-end encryption system,” in Proc. of USENIX OSDI, 2024. [40] “Signalapp/securevaluerecovery2,” 2025. [Online]. Available: https: //github.com/signalapp/SecureValueRecovery2 [41] I. Bentov, Y. Ji, F. Zhang, L. Breidenbach, P. Daian, and A. Juels, “Tesseract: Real-time cryptocurrency exchange using trusted hardware,” in Proc. of ACM CCS, 2019. [42] A. Herzberg, S. Jarecki, H. Krawczyk, and M. Yung, “Proactive secret sharing or: How to cope with perpetual leakage,” in Proc. of CRYPTO, 1995. [43] R. Canetti, R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Adaptive security for threshold cryptosystems,” in Proc. of CRYPTO, 1999. [44] R. Vassantlal, E. Alchieri, B. Ferreira, and A. Bessani, “COBRA: dynamic proactive secret sharing for confidential BFT services,” in Proc. of IEEE S&P, 2022. [45] V. Buterin, “A next-generation smart contract and decentralized application platform,” vol. 3, no. 37, pp. 2–1, 2014. [Online]. Available: https://cryptorating.eu/whitepapers/Ethereum/Ethereum whi te paper.pdf [46] P. De Filippi and G. McMullen, “Governance of blockchain systems: Governance of and by distributed infrastructure,” Ph.D. dissertation, 2018. [47] M. Bailleu, D. Giantsidi, V. Gavrielatos, D. L. Quoc, V. Nagarajan, and P. Bhatotia, “Avocado: A secure in-memory distributed storage system,” in Proc. of USENIX ATC, 2021. [48] E. Pattuk, M. Kantarcioglu, V. Khadilkar, H. Ulusoy, and S. Mehrotra, “Bigsecret: A secure data management framework for key-value stores,” in Proc. of IEEE CLOUD, 2013. [49] X. Yuan, X. Wang, C. Wang, C. Qian, and J. Lin, “Building an encrypted, distributed, and searchable key-value store,” in Proc. of ACM AsiaCCS, 2016. [50] E. V. Mangipudi, U. Desai, M. Minaei, M. Mondal, and A. Kate, “Uncovering impact of mental models towards adoption of multi-device crypto-wallets,” in Proc. of ACM CCS, 2023.
[1] “Intel® software guard extensions (intel® sgx),” https://www.intel.com/content/www/us/en/architecture-andtechnology/software-guard-extensions.html, 2015. [2] “Intel® trust domain extensions (intel® tdx),” https://www.intel.com/content/www/us/en/developer/tools/trustdomain-extensions/overview.html, 2023. [3] “Arm confidential compute architecture,” https://www.arm.com/architecture/security-features/arm-confidentialcompute-architecture, 2021. [4] “Amd secure encrypted virtualization (sev),” https://www.amd.com/en/developer/sev.html, 2016. [5] “Hygon secure virtualization,” 2023. [Online]. Available: https: //gitee.com/anolis/cloud-kernel/blob/devel-5.10/Documentation/x86/hy gon-secure-virtualization.rst [6] “Azure confidential computing overview,” https://learn.microsoft.com/en-us/azure/confidentialcomputing/overview, 2024. [7] “Nitro enclaves,” https://aws.amazon.com/ec2/nitro/nitro-enclaves/, 2020. [8] “Google confidential computing,” 2024. [Online]. Available: https: //cloud.google.com/security/products/confidential-computing [9] F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, M. Peinado, G. Mainar-Ruiz, and M. Russinovich, “VC3: trustworthy data analytics in the cloud using SGX,” in Proc. of IEEE S&P, 2015. [10] C. Priebe, K. Vaswani, and M. Costa, “Enclavedb: A secure database using SGX,” in Proc. of IEEE S&P, 2018. [11] O. Ohrimenko, F. Schuster, C. Fournet, A. Mehta, S. Nowozin, K. Vaswani, and M. Costa, “Oblivious multi-party machine learning on trusted processors,” in Proc. of USENIX Security, 2016. [12] S. Herwig, C. Garman, and D. Levin, “Achieving keyless cdns with conclaves,” in Proc. of USENIX Security, 2020. [13] B. Fisch, D. Vinayagamurthy, D. Boneh, and S. Gorbunov, “IRON: functional encryption using intel SGX,” in Proc. of ACM CCS, 2017. [14] R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. M. Johnson, A. Juels, A. Miller, and D. Song, “Ekiden: A platform for confidentialitypreserving, trustworthy, and performant smart contracts,” in Proc. of IEEE EuroS&P, 2019. [15] J. Lind, O. Naor, I. Eyal, F. Kelbert, E. G. Sirer, and P. R. Pietzuch, “Teechain: a secure payment network with asynchronous blockchain access,” in Proc. of ACM SOSP, 2019. [16] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier: An authenticated data feed for smart contracts,” in Proc. of ACM CCS, 2016. [17] S. Matetic, K. Wüst, M. Schneider, K. Kostiainen, G. Karame, and S. Capkun, “BITE: bitcoin lightweight client privacy using trusted execution,” in Proc. of USENIX Security, 2019. [18] X. Wen, Q. Feng, J. Niu, Y. Zhang, and C. Feng, “Mercury: Practical cross-chain exchange via trusted hardware,” IEEE Trans. Dependable Secur. Comput., vol. 23, no. 2, pp. 2949–2961, 2026. [19] X. Wen, Q. Feng, H. Lyu, J. Niu, Y. Zhang, and C. Feng, “Teerollup: Efficient rollup design using heterogeneous TEE,” IEEE Trans. Computers, vol. 74, no. 10, pp. 3546–3558, 2025. [20] G. Chen, S. Chen, Y. Xiao, Y. Zhang, Z. Lin, and T. Lai, “Sgxpectre: Stealing intel secrets from SGX enclaves via speculative execution,” in Proc. of IEEE EuroS&P, 2019. [21] J. V. Bulck, M. Minkin, O. Weisse, D. Genkin, B. Kasikci, F. Piessens, M. Silberstein, T. F. Wenisch, Y. Yarom, and R. Strackx, “Foreshadow: Extracting the keys to the intel SGX kingdom with transient out-oforder execution,” in Proc. of USENIX Security, 2018. [22] M. Li, L. Wilke, J. Wichelmann, T. Eisenbarth, R. Teodorescu, and Y. Zhang, “A systematic look at ciphertext side channels on AMD SEV-SNP,” in Proc. IEEE S&P, 2022. [23] R. Buhren, C. Werling, and J. Seifert, “Insecure until proven updated: Analyzing AMD sev’s remote attestation,” in Proc. of ACM CCS, 2019. [24] R. Buhren, H. N. Jacob, T. Krachenfels, and J. Seifert, “One glitch to rule them all: Fault injection attacks against amd’s secure encrypted virtualization,” in Proc. of ACM CCS, 2021. [25] M. Lipp, D. Gruss, R. Spreitzer, C. Maurice, and S. Mangard, “Armageddon: Cache attacks on mobile devices,” in Proc. of USENIX Security, 2016. [26] M. Hähnel, W. Cui, and M. Peinado, “High-resolution side channels for untrusted operating systems,” in Proc. of USENIX ATC, 2017.
14
[51] Y. Yu, T. Sharma, S. Das, and Y. Wang, “”don’t put all your eggs in one basket”: How cryptocurrency users choose and secure their wallets,” in Proc. of CHI, 2024. [52] J. Liagouris, V. Kalavri, M. Faisal, and M. Varia, “SECRECY: secure collaborative analytics in untrusted clouds,” in Proc. of USENIX NSDI, 2023. [53] H. Corrigan-Gibbs and D. Boneh, “Prio: Private, robust, and scalable computation of aggregate statistics,” in Proc. of USENIX NSDI, 2017. [54] N. Volgushev, M. Schwarzkopf, A. Lapets, M. Varia, and A. Bestavros, “DEMO: integrating MPC in big data workflows,” in Proc. of ACM CCS, 2016. [55] P. Zhou, X. Guo, P. Chen, T. Li, S. Lv, and Z. Liu, “Shortcut: Making mpc-based collaborative analytics efficient on dynamic databases,” in Proc. of ACM CCS, 2024. [56] M. Yin, D. Malkhi, M. K. Reiter, G. Golan-Gueta, and I. Abraham, “Hotstuff: BFT consensus with linearity and responsiveness,” in Proc. of ACM PODC, 2019. [57] D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weil pairing,” in Proc. of ASIACRYPT, 2001. [58] M. Keller, “MP-SPDZ: A versatile framework for multi-party computation,” in Proc. of ACM CCS, 2020. [59] G. D. H. Hunt, R. Pai, M. V. Le, H. Jamjoom, S. Bhattiprolu, R. Boivie, L. Dufour, B. Frey, M. Kapur, K. A. Goldman, R. Grimm, J. Janakirman, J. M. Ludden, P. Mackerras, C. May, E. R. Palmer, B. B. Rao, L. Roy, W. A. Starke, J. Stuecheli, E. Valdez, and W. Voigt, “Confidential computing for openpower,” in Proc. of EuroSys, 2021. [60] D. Lee, D. Kohlbrenner, S. Shinde, K. Asanovic, and D. Song, “Keystone: an open framework for architecting trusted execution environments,” in Proc. of EuroSys, 2020. [61] V. Costan, I. A. Lebedev, and S. Devadas, “Sanctum: Minimal hardware extensions for strong software isolation,” in Proc. of USENIX Security, 2016. [62] R. Bahmani, F. Brasser, G. Dessouky, P. Jauernig, M. Klimmek, A. Sadeghi, and E. Stapf, “CURE: A security architecture with customizable and resilient enclaves,” in Proc. of USENIX Security, 2021. [63] S. Weiser, M. Werner, F. Brasser, M. Malenko, S. Mangard, and A. Sadeghi, “TIMBER-V: tag-isolated memory bringing fine-grained enclaves to RISC-V,” in Proc. of NDSS, 2019. [64] Y. Xu, W. Cui, and M. Peinado, “Controlled-channel attacks: Deterministic side channels for untrusted operating systems,” in Proc. of IEEE S&P, 2015. [65] K. Murdock, D. F. Oswald, F. D. Garcia, J. V. Bulck, D. Gruss, and F. Piessens, “Plundervolt: Software-based fault injection attacks against intel SGX,” in Proc. of IEEE S&P, 2020. [66] P. Borrello, A. Kogler, M. Schwarzl, M. Lipp, D. Gruss, and M. Schwarz, “Æpic leak: Architecturally leaking uninitialized data from the microarchitecture,” in Proc. of USENIX Security, 2022. [67] S. Checkoway and H. Shacham, “Iago attacks: why the system call API is a bad untrusted RPC interface,” in Proc. of ACM ASPLOS, 2013. [68] N. Weichbrodt, A. Kurmus, P. R. Pietzuch, and R. Kapitza, “Asyncshock: Exploiting synchronisation bugs in intel SGX enclaves,” in Proc. of ESORICS, 2016. [69] M. Shih, S. Lee, T. Kim, and M. Peinado, “T-SGX: eradicating controlled-channel attacks against enclave programs,” in Proc. of NDSS, 2017. [70] W. Wang, G. Chen, X. Pan, Y. Zhang, X. Wang, V. Bindschaedler, H. Tang, and C. A. Gunter, “Leaky cauldron on the dark land: Understanding memory side-channel hazards in SGX,” in Proc. of ACM CCS, 2017. [71] A. Shamir, “How to share a secret,” Commun. ACM, vol. 22, no. 11, pp. 612–613, 1979. [72] Y. Desmedt, “Society and group oriented cryptography: A new concept,” in Proc. of CRYPTO, 1987. [73] L. Zhou, F. B. Schneider, and R. van Renesse, “APSS: proactive secret sharing in asynchronous systems,” ACM Trans. Inf. Syst. Secur., vol. 8, no. 3, pp. 259–286, 2005. [74] D. A. Schultz, B. Liskov, and M. D. Liskov, “MPSS: mobile proactive secret sharing,” ACM Trans. Inf. Syst. Secur., vol. 13, no. 4, pp. 34:1– 34:32, 2010. [75] J. Baron, K. E. Defrawy, J. Lampkins, and R. Ostrovsky, “Communication-optimal proactive secret sharing for dynamic groups,” in Proc. of ACNS, 2015.
[76] S. K. D. Maram, F. Zhang, L. Wang, A. Low, Y. Zhang, A. Juels, and D. Song, “CHURP: dynamic-committee proactive secret sharing,” in Proc. of ACM CCS, 2019. [77] A. C. Yao, “Protocols for secure computations (extended abstract),” in Proc. of FOCS, 1982. [78] Y. Lindell, “Secure multiparty computation,” Commun. ACM, vol. 64, no. 1, pp. 86–96, 2021. [79] D. Escudero, “An introduction to secret-sharing-based secure multiparty computation,” IACR Cryptol. ePrint Arch., p. 62, 2022. [80] M. Castro and B. Liskov, “Practical byzantine fault tolerance and proactive recovery,” ACM Trans. Comput. Syst., vol. 20, no. 4, pp. 398–461, 2002. [81] “Trusted computing base recovery,” Intel, 2025. [Online]. Available: https://www.intel.com/content/www/us/en/developer/articles/technical /software-security-guidance/best-practices/trusted-computing-base-rec overy.html [82] “Affected processors: Transient execution attacks & related security,” Intel, 2025. [Online]. Available: https://www.intel.com/content/www/ us/en/developer/topic-technology/software-security-guidance/processo rs-affected-consolidated-product-cpu-model.html [83] “Amd sev confidential computing vulnerability,” AMD, 2025. [Online]. Available: https://www.amd.com/en/resources/product-security/bulletin /amd-sb-3019.html [84] H. Lyu, S. Xie, J. Niu, C. Feng, Y. Zhang, and I. Beschastnikh, “Ladon: High-performance multi-bft consensus via dynamic global ordering,” in Proc. of EuroSys, 2025. [85] M. M. Jalalzai, J. Niu, C. Feng, and F. Gai, “Fast-hotstuff: A fast and robust BFT protocol for blockchains,” IEEE Trans. Dependable Secur. Comput., vol. 21, no. 4, pp. 2478–2493, 2024. [86] P. Feldman, “A practical scheme for non-interactive verifiable secret sharing,” in Proc. of FOCS, 1987. [87] G. Chen and Y. Zhang, “MAGE: mutual attestation for a group of enclaves without trusted third parties,” in Proc. USENIX Security, 2022. [88] Y. Lindell and A. Nof, “A framework for constructing fast MPC over arithmetic circuits with malicious adversaries and an honest-majority,” in Proc. of ACM CCS, 2017. [89] “Hot-stuff/libhotstuff,” https://github.com/hot-stuff/libhotstuff, Jan. 2018. [90] “Intel® tdx connect architecture specification,” https://www.intel.com/content/www/us/en/contentdetails/773614/intel-tdx-connect-architecture-specification.html, 2023. [91] J. Sousa and A. N. Bessani, “From byzantine consensus to BFT state machine replication: A latency-optimal transformation,” in Proc. of IEEE EDCC, 2012. [92] (2026) Aws key management service documentation. [Online]. Available: https://docs.aws.amazon.com/kms/ [93] (2026) Azure key vault overview - azure key vault. [Online]. Available: https://learn.microsoft.com/en-us/azure/key-vault/general/overview [94] (2026) Safe{Wallet}. [Online]. Available: https://safe.global/ [95] (2026) Fireblocks. [Online]. Available: https://www.fireblocks.com/ [96] T. Lepoint, S. Patel, M. Raykova, K. Seth, and N. Trieu, “Private join and compute from PIR with default,” in Proc. of ASIACRYPT, 2021. [97] S. Matetic, M. Ahmed, K. Kostiainen, A. Dhar, D. M. Sommer, A. Gervais, A. Juels, and S. Capkun, “ROTE: rollback protection for trusted execution,” in Proc. of USENIX Security, 2017. [98] J. Niu, W. Peng, X. Zhang, and Y. Zhang, “NARRATOR: secure and practical state continuity for trusted execution in the cloud,” in Proc. of ACM CCS, 2022. [99] W. Peng, X. Li, J. Niu, X. Zhang, and Y. Zhang, “Ensuring state continuity for confidential computing: A blockchain-based approach,” IEEE Trans. Dependable Secur. Comput., vol. 21, no. 6, pp. 5635–5649, 2024. [100] W. Wang, J. Niu, M. K. Reiter, and Y. Zhang, “Formally verifying a rollback-prevention protocol for tees,” in Proc. of FORTE, 2024. [101] S. Angel, A. Basu, W. Cui, T. Jaeger, S. Lau, S. T. V. Setty, and S. Singanamalla, “Nimble: Rollback protection for confidential cloud services,” in Proc. of USENIX OSDI, 2023. [102] B. Dinis, P. Druschel, and R. Rodrigues, “RR: A fault model for efficient TEE replication,” in Proc. of NDSS, 2023. [103] J. Niu, X. Wen, G. Wu, S. Liu, J. Yu, and Y. Zhang, “Achilles: Efficient tee-assisted BFT consensus via rollback resilient recovery,” in Proc. of EuroSys, 2025.
15
platform-state evidence, but a compromised enclave may expose its local plaintext state, so TEE protection alone does not invalidate previously leaked shares. TeeDAO combines these mechanisms at the system layer: heterogeneous TEEs provide concrete trust domains and attestation-derived eligibility, while DPSS/MPC maintains confidentiality and computation over distributed shares. When evidence changes the committee, TeeDAO couples the certified configuration transition with refresh, resharing, or recovery, preventing past compromise from accumulating across configurations. Previously related designs already appear in secure recovery, digital-asset custody, threshold signing/wallet infrastructure, and privacypreserving analytics (e.g., Signal SVR3 [39], Confidential Space + MPC [113], Fireblocks [95], CoVault [114]).
[104] W. Wang, S. Deng, J. Niu, M. K. Reiter, and Y. Zhang, “ENGRAFT: enclave-guarded raft on byzantine faulty nodes,” in Proc. of ACM CCS, 2022. [105] H. Howard, F. Alder, E. Ashton, A. Chamayou, S. Clebsch, M. Costa, A. Delignat-Lavaud, C. Fournet, A. Jeffery, M. Kerner, F. Kounelis, M. A. Kuppe, J. Maffre, M. Russinovich, and C. M. Wintersteiger, “Confidential consortium framework: Secure multiparty applications with confidentiality, integrity, and high availability,” Proc. VLDB Endow., vol. 17, no. 2, pp. 225–240, 2023. [106] M. S. Riazi, C. Weinert, O. Tkachenko, E. M. Songhori, T. Schneider, and F. Koushanfar, “Chameleon: A hybrid secure computation framework for machine learning applications,” in Proc. of ACM AsiaCCS, 2018. [107] Y. Lu, B. Zhang, H. Zhou, W. Liu, L. Zhang, and K. Ren, “Correlated randomness teleportation via semi-trusted hardware - enabling silent multi-party computation,” in Proc. of ESORICS, 2021. [108] P. Wu, J. Ning, J. Shen, H. Wang, and E. Chang, “Hybrid trust multiparty computation with trusted execution environment,” in Proc. of NDSS, 2022. [109] X. Hu, R. Li, Y. Liu, and Q. Wang, “Towards efficient and practical multi-party computation under inconsistent trust in tees,” in Proc. of IEEE S&P, 2025. [110] “The deployment dilemma: Merits & challenges of deploying mpc,” 2023. [Online]. Available: https://mpc.cs.berkeley.edu/blog/deploymen t-dilemma.html [111] V. Goyal, A. Polychroniadou, and Y. Song, “Unconditional communication-efficient MPC via hall’s marriage theorem,” in Proc. of CRYPTO, 2021. [112] G. Beck, A. Goel, A. Hegde, A. Jain, Z. Jin, and G. Kaptchuk, “Scalable multiparty garbling,” in Proc. of ACM CCS, 2023. [113] (2023) How confidential space and mpc can help secure digital assets. [Online]. Available: https://cloud.google.com/blog/products/identity-s ecurity/how-confidential-space-and-mpc-can-help-secure-digital-asset s [114] R. D. Viti, I. Sheff, N. Glaeser, B. Dinis, R. Rodrigues, B. Bhattacharjee, A. Hithnawi, D. Garg, and P. Druschel, “Covault: Secure, scalable analytics of personal data,” in Proc. of USENIX Security, 2025.
B. Performance of CSV To further evaluate the generality and performance of TeeDAO, we conducted additional experiments on the CSV platform. The experimental setup and evaluation methodology are consistent with those described in Sec. VI-A. TABLE V: Recovery and reshare latency (s) with 1K entries. Metric
n=4
n = 10
n = 16
n = 25
CSV-Recovery
Poly. Gen. State Recon.
1.826 0.307
4.006 0.545
7.828 0.914
16.918 1.381
CSV-Reshare
Poly. Gen. State Recon.
3.274 0.804
9.288 1.478
17.257 2.259
36.018 4.287
Item
Table V reports the latency of TeeDAO-CSV during reconfiguration and fault node recovery protocols. The results are consistent with previous findings: at n = 4, TeeDAO-CSV achieves lower latency than COBRA. However, as the number of nodes increases, the TEE overhead causes TeeDAO-CSV’s latency to gradually surpass that of COBRA. Table VI summarizes the maximum throughput and corresponding latency of TeeDAO-CSV. TeeDAO-CSV achieves higher throughput than COBRA for when n < 25, but its throughput decreases more rapidly as the number of nodes increases. At n = 25, the write throughput of TeeDAO-CSV becomes comparable to COBRA.
A PPENDIX A. Complementarity of MPC and Heterogeneous TEEs Deploying MPC in real systems faces a well-known deployment dilemma between security and performance [110]. On the one hand, MPC requires large and diverse committees to achieve strong security; small or closely related parties undermine the independence that secret sharing relies on. On the other hand, MPC communication and coordination costs grow with both the number of parties and the number of interactive multiplications, making large committees expensive in bandwidth and latency [111], [112]. MPC and TEEs address different parts of the problem. MPC protects secrets by distributing them across parties and computing over shares, but it does not decide which machines should remain eligible to hold shares as platforms are patched, revoked, or replaced. TEEs provide attested execution and
TABLE VI: Performance of TeeDAO-CSV. Item Write Read
16
Throughput (kTPS) n=4 n = 10 n = 25
n=4
22.5 120.1
64.1 3.6
15.6 40.5
8.4 9.1
Latency (ms) n = 10 n = 25 97.9 5.1
190.8 11.0