---
title: In-TEE Dual-Enclave Model Overview
url: https://www.emergentmind.com/topics/in-tee-dual-enclave-model
type: topic
---

# In-TEE Dual-Enclave Model Overview

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** [2010.08440] extends this by introducing a per-region permission lattice and a region-sharing state machine:

- **State:** $S = \langle P, R, A, M, V \rangle$ with enclaves $P$, region descriptors $R: \text{UID}\to(\text{OwnerID} \times \text{Size})$, access permissions $A$, memory $M$, and virtual mappings $V$.
- **Permissions:** Power set $P(\{\text{r},\text{w},\text{x},\text{l}\})$; lock ($\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** [2209.15253] employs a *single-sharing* model with immutable “root snapshot” regions. Key definitions:

- **Ownership map:** $o: \mathrm{PA} \to \mathrm{EID}$
- **Shareability predicate:** $\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** [2108.13922] 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.** [2305.09351] 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:

```c
// 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 [2305.09351] 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 [2010.08440, 2209.15253, 2305.09351, 2108.13922].

Source: https://www.emergentmind.com/topics/in-tee-dual-enclave-model