Papers
Topics
Authors
Recent
Search
2000 character limit reached

In-TEE Dual-Enclave Model Overview

Updated 5 February 2026
  • In-TEE dual-enclave model is an architectural paradigm featuring isolated TEEs that securely share code, data, and execution state.
  • It employs hardware-based mechanisms and formal protocols to achieve secure memory sharing, mutual attestation, and high-throughput inter-enclave communication.
  • The approach minimizes TCB expansion and optimizes performance in use cases like collaborative attestation, distributed sandboxing, and modular service decomposition.

An In-TEE dual-enclave model describes an architectural paradigm in which two or more mutually isolated trusted execution environments (TEEs)—usually referred to as enclaves—are instantiated on the same or distributed physical substrates, and enabled to cooperate through hardware- or formally-enforced secure sharing of code, data, or execution state. This paradigm underpins a wide diversity of secure computing workloads, including collaborative attestation, distributed sandboxing, fine-grained service decomposition, and high-throughput secure data sharing. Recent advances emphasize hardware, formal, and protocol-layer mechanisms for secure dual-enclave interactions and selective memory sharing, minimizing trusted computing base (TCB) expansion and eliminating redundant data copies within or across TEE boundaries.

1. Memory Models and Formal Definitions

In TEE platforms such as Intel SGX and RISC-V Keystone, the default spatial isolation model prohibits enclaves from mapping or accessing other enclaves’ memory regions, thereby preventing zero-copy sharing and recurring performance bottlenecks.

Elasticlave (Yu et al., 2020) extends this by introducing a per-region permission lattice and a region-sharing state machine:

  • State: S=P,R,A,M,VS = \langle P, R, A, M, V \rangle with enclaves PP, region descriptors R:UID(OwnerID×Size)R: \text{UID}\to(\text{OwnerID} \times \text{Size}), access permissions AA, memory MM, and virtual mappings VV.
  • Permissions: Power set P({r,w,x,l})P(\{\text{r},\text{w},\text{x},\text{l}\}); lock (l\text{l}) is exclusive.
  • Region Lifecycle: Regions can be created by one enclave (owner), temporarily and selectively shared (via “share”), and later unmapped and destroyed. Sharing is mediated by a privileged monitor which atomically updates permissions using RISC-V PMP hardware.

Cerberus (Lee et al., 2022) employs a single-sharing model with immutable “root snapshot” regions. Key definitions:

  • Ownership map: o:PAEIDo: \mathrm{PA} \to \mathrm{EID}
  • Shareability predicate: e,p:  Shareable(e,p)(o(p)=e)(o(p)=rootsnap(e))\forall e, p:\; \mathit{Shareable}(e,p) \coloneqq (o(p)=e) \lor (o(p)=\mathit{rootsnap}(e))
  • Clone-on-write: Write attempts by the accessor enclave transparently allocate private copies, preserving write isolation.

Table 1. Comparison of Region Sharing Mechanisms

Model Mutability Sharing Granularity Enforcement Mechanism
Elasticlave Mutable / Atomic Arbitrary regions PMP, monitor (RISC-V)
Cerberus Immutable (snap) Single root snapshot OS call + formal TAP model
Stockade Mutable Individual EPC pages SGX microcode, monitor enclave

2. Secure Dual-Enclave Communication and Attestation

Several approaches instantiate in-TEE dual-enclave cooperation beyond intra-TEE memory sharing.

Stockade (Park et al., 2021) splits an application or service into:

  • A bi-enclave, containing all of one user software module and hardware-confined to its own linear address range (ELRANGE); hardware disables EEXIT and enforces all code/data accesses remain within this range.
  • A trusted monitor enclave, which intermediates all syscalls on the bi-enclave’s behalf, validates system services against signed policies, and belongs to both parties’ trust perimeter.

Antonino et al. (Antonino et al., 2023) generalize the dual-enclave pattern across heterogeneous TEE substrates such as Intel SGX (deployer/owner) and AMD SEV (guest VM), using authenticated remote protocols to establish mutually authenticated state and attest cross-TEE application integrity:

  • Code, runtime measurements, and provisioning secrets (transport and MAC keys) are cryptographically bound to each enclave’s root of trust.
  • Runtime provisioning allows remote parties to request a SGX proof that explicitly incorporates the SEV VM measurement and application data, unifying cross-vendor TEE trust.

3. Lifecycle Protocols and Hardware Operations

Elasticlave formalizes a region lifecycle: Create \rightarrow Map \rightarrow Share \rightarrow Map in accessor \rightarrow (optional lock transfers) \rightarrow Unmap \rightarrow Destroy. Each transition triggers atomic updates in region- and enclave-specific permission tables, with hardware-enforced isolation by PMP entries.

Stockade introduces two additional user-level instructions and extends the EPCM:

  • ESADD(SEPC, target_SECS_phys): Owner enclave signals intent to share a page; hardware records owner.
  • ESACCEPT(SEPC): Co-owner enclave accepts the page; hardware updates EPCM to list both owners.
  • TLB-miss handlers consult EPCM extension fields to enforce that only these two SECS structures may access the page.
  • Local attestation over shared pages ensures mutual agreement on allowed code identities.

Cerberus prescribes a two-step dual-enclave instantiation:

1
2
3
// In source enclave A:
MakeImmutable(); // freeze pages
OS_call(ShareMemory, A, B, X); // B views A's pages as root snapshot
Upon any write by B to shared pages, copy-on-write triggers page reallocation, maintaining integrity.

Flexible Remote Attestation model (Antonino et al., 2023) operates via a protocol comprising: out-of-band platform setup; secure-channel establishment using SN public keys; VM launch and measurement; secure provisioning of per-VM MAC key; SGX quote generation with VM measurement included; and third-party verification using certificates from both TEE platforms.

4. Security Invariants and Formal Guarantees

All recently proposed models incorporate rigorous formal verification to guarantee classical and compositional confidentiality and integrity under strong attacker models.

  • Elasticlave Theorem 1 (Bounded Escalation): No accessor enclave can ever escalate permissions beyond the owner-granted maximum, due to lattice-constrained permission transitions and absence of escalation interfaces.
  • Elasticlave Theorem 2 (Enforceable Serialization): Exclusive “lock” bit allows robust, OS-independent mutual exclusion for region mutations; attempts by faulty/malicious enclaves to violate the access protocol are foiled by immediate hardware faults.
  • Cerberus Security Lemmas: Integrity and confidentiality are preserved under both MakeImmutable and ShareMemory operations; shared pages are never write-shared, and any difference in secret (high) state is unobservable to the adversary for all protocol-allowed action traces.
  • Flexible Attestation (Tamarin Models): Formal proof in Tamarin certifies injective agreement on session keys, secrecy of provisioned keys (unless platform root is compromised), and authenticity of synthesized dual-TEE attestation proofs.

5. Hardware, TCB, and Performance Considerations

Elasticlave achieves low TCB (≈6.8 kLoC total), adds only a handful of security instructions, and relies solely on small PMP-based metadata extensions. One PMP entry per region per core is required; every additional 8 PMP entries add ≈1% to core area. Context switch cost is less than 0.15% of cycles for up to 4 regions.

Stockade requires minimal microcode extensions: a single bit per SECS, extended EPCM with co-owner field, ESADD/ESACCEPT instructions, and new TLB-miss checks for bi-enclaves. Disabling EEXIT adds confinement guarantees. Performance overhead in sandboxed I/O (SQLite) is ≈1.49× over raw SGX but ≈1.38× faster than software-based sandboxes. Hardware-protected inter-enclave communication achieves up to 1.9× speedup over AES-GCM over shared pages. CPU-bound enclave operations incur <3% overhead.

Cerberus reports clone latency of ≈23 ms (on SiFive FU540), with copy-on-write adding at most 19% for heavy-write workloads. End-to-end fork in an HTTP server is only 2.1× over native (vs. 33× for Graphene-SGX) when leveraging dual-enclave sharing.

Antonino et al.’s cross-TEE attestation protocol incurs negligible overhead relative to ML workload runtime: sub-second setup/attestation (e.g., provisioning 0.089 s vs. 90–1100 s VM runtime). The protocol is portable to Intel TDX, SEV-SNP, or ARM TrustZone—challenges involve scalable secure channel management and proof composition across multiple roots of trust.

6. Limitations, Extensions, and Open Challenges

Current formal models such as Cerberus restrict sharing to read-only (immutable) snapshots to simplify reasoning and verification, while Elasticlave’s mutable model allows more expressive sharing policies and atomic lock transfer at the cost of a more complex hardware monitor.

Compositional remote attestation across heterogeneous TEE roots (Intel, AMD, ARM, TPM) remains an open challenge, as does scaling secure dual-enclave coordination to many enclaves or TEEs, and maintaining attestation freshness across VM migration and rollback. Dual-enclave models like Stockade and Elasticlave achieve strong mutual isolation and high throughput for typical microservice or modular workload patterns, but may require hardware or firmware updates not yet fully standardized in commercial TEE deployments.

A plausible implication is that continued convergence of hardware-enabled permission-lattices, per-region tracking, monitor-mediated sharing, and formally verified instantiation protocols will further reduce TCB, improve throughput, and enable secure, efficient dual-enclave deployments in both single- and multi-platform settings (Yu et al., 2020, Lee et al., 2022, Antonino et al., 2023, Park et al., 2021).

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to In-TEE Dual-Enclave Model.