The Ultimate Trust Problem

In standard DevOps, you fear bugs. In crypto infrastructure, you fear the operator themselves.

How do you run a service where even the sysadmins can’t see the data inside?

The answer is Trusted Execution Environments (TEE).

Standard VM:       Hypervisor can read all memory
Standard Server:   Root user can read all memory
TEE Enclave:       Even root/hypervisor can't read enclave memory
```sql

This technology powers everything from Signal's private contact discovery to SUAVE's encrypted block building.

---

## What TEEs Protect

A TEE creates an **enclave**—an isolated execution environment where:

```text
Protected:
├── Memory contents (encrypted by hardware)
├── CPU registers during execution
├── Code integrity (measured at load time)
└── Secrets sealed to specific enclave identity

NOT Protected:
├── Execution timing (side channels)
├── Memory access patterns (cache attacks)
├── Input/output (must be encrypted by app)
└── Availability (host can kill enclave)
```python

The host OS **cannot** read enclave memory, even with root access.

---

## The "Aha!" Moment

Here's the key insight for blockchain applications:

> **A TEE can run a program that the operator cannot modify or inspect, and anyone can verify this fact cryptographically.** This enables "trustless" services run by untrusted parties. A relay can prove it's running honest code without revealing the transactions it's processing.

This is how you build censorship-resistant infrastructure operated by potentially malicious actors.

---

## Intel SGX Architecture

### Enclave Memory Model

```text
┌─────────────────────────────────────────┐
│              Regular Memory              │  ← OS can read/write
├─────────────────────────────────────────┤
│     Enclave Page Cache (EPC)            │  ← Hardware encrypted
│  ┌─────────────────────────────────┐    │
│  │         Enclave                 │    │
│  │  ┌──────────┐  ┌──────────┐     │    │
│  │  │   Code   │  │   Data   │     │    │
│  │  └──────────┘  └──────────┘     │    │
│  │  ┌──────────┐                   │    │
│  │  │  Secrets │ (sealed keys)     │    │
│  │  └──────────┘                   │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘
```python

The Memory Encryption Engine (MEE) encrypts EPC pages with a key that **never leaves the CPU**.

### The MRENCLAVE Identity

Every enclave has a cryptographic identity:

```python
# MRENCLAVE = SHA256 of enclave state at initialization
mrenclave = sha256(
    enclave_code +
    enclave_data +
    memory_layout +
    entry_points
)

# Any change to the code → Different MRENCLAVE
# This is the "fingerprint" of what's running
```diff

---

## Remote Attestation

How do you verify what's running inside a remote enclave?

### The Attestation Flow

```text
┌──────────┐         ┌──────────┐         ┌─────────┐
│  Client  │         │  Enclave │         │ Intel   │
│(Verifier)│         │ (Prover) │         │ IAS/DCAP│
└────┬─────┘         └────┬─────┘         └────┬────┘
     │  1. Challenge       │                    │
     │────────────────────>│                    │
     │                     │                    │
     │                     │ 2. Request Quote   │
     │                     │    (EREPORT)       │
     │                     │                    │
     │  3. Quote           │                    │
     │<────────────────────│                    │
     │                     │                    │
     │  4. Verify Quote    │                    │
     │─────────────────────────────────────────>│
     │                     │                    │
     │  5. Attestation Result                   │
     │<─────────────────────────────────────────│
```text

### Quote Structure

```rust
struct SGXQuote {
    version: u16,
    sign_type: u16,
    epid_group_id: [u8; 4],
    qe_svn: u16,
    pce_svn: u16,
    xeid: u32,
    basename: [u8; 32],
    report_body: ReportBody,
    signature: [u8; 64],
}

struct ReportBody {
    cpu_svn: [u8; 16],
    misc_select: u32,
    attributes: Attributes,
    mr_enclave: [u8; 32],    // Hash of enclave code
    mr_signer: [u8; 32],     // Hash of signing key
    isv_prod_id: u16,
    isv_svn: u16,
    report_data: [u8; 64],   // Custom data (e.g., public key)
}
```text

### Verification Code

```python
def verify_attestation(quote: bytes, expected_mrenclave: bytes) -> bool:
    """Verify an SGX quote matches expected enclave."""

    # 1. Parse quote structure
    parsed = parse_sgx_quote(quote)

    # 2. Verify Intel's signature (ECDSA with Intel's public key)
    if not verify_intel_signature(parsed):
        return False

    # 3. Check MRENCLAVE matches expected code
    if parsed.report_body.mr_enclave != expected_mrenclave:
        return False

    # 4. Check security version numbers
    if parsed.report_body.isv_svn < MINIMUM_SVN:
        return False

    # 5. Extract enclave's public key from report_data
    enclave_pubkey = parsed.report_body.report_data[:32]

    return True
```diff

---

## Sealing: Persistent Secrets

Enclaves can encrypt data that only they can decrypt later:

```c
// Inside enclave: seal data to this specific enclave
sgx_status_t seal_data(
    uint8_t *data,
    uint32_t data_size,
    sgx_sealed_data_t *sealed_blob
) {
    return sgx_seal_data(
        0, NULL,              // Additional authenticated data
        data_size, data,      // Data to seal
        sealed_size,          // Output size
        sealed_blob           // Output sealed blob
    );
}

// Sealed data includes:
// - KEY_ID derived from MRENCLAVE or MRSIGNER
// - IV and MAC for authenticated encryption
// - Encrypted payload
```diff

**Sealing modes:**
- `MRENCLAVE`: Only this exact code can unseal
- `MRSIGNER`: Any code signed by the same key can unseal

---

## Limitations and Attacks

### Side-Channel Attacks

TEEs protect **data at rest and in use**, but leak through timing and access patterns:

```python
# Cache-timing attack example
# Attacker measures time to access cache lines

def timing_attack(victim_enclave):
    # 1. Fill cache with known data
    prime_cache()

    # 2. Trigger victim enclave execution
    trigger_victim()

    # 3. Measure which cache lines were evicted
    for line in cache_lines:
        start = rdtsc()
        access(line)
        elapsed = rdtsc() - start

        if elapsed > THRESHOLD:
            print(f"Enclave accessed line {line}")
```text

**Mitigations:**
- Constant-time code (no data-dependent branches)
- Cache partitioning (Intel CAT)
- Oblivious RAM (hides access patterns)

## Rollback Attacks

The host can restore old sealed state:

```yaml
Attack:
1. Enclave processes transaction T1, seals state S1
2. Enclave processes transaction T2, seals state S2
3. Attacker restores S1
4. Enclave unseals S1, "forgets" T2

Defense:
- Monotonic counters (limited availability)
- External state commitments (blockchain anchoring)
- Threshold schemes (multiple enclaves must agree)
```diff

---

## TEE in Blockchain Applications

### Use Case: Private Transaction Relay

```python
class PrivateRelay:
    """Relay that can't see transaction contents."""

    def __init__(self):
        # Generate keypair inside enclave
        self.enclave_pubkey = generate_in_enclave()

    def submit_transaction(self, encrypted_tx: bytes):
        # Decrypt inside enclave
        # Execute simulation inside enclave
        # Re-encrypt result inside enclave

        # Neither operator nor relay code outside the
        # enclave ever sees the plaintext transaction
        pass

    def get_attestation(self) -> bytes:
        """Prove we're running honest code."""
        return generate_quote(self.enclave_pubkey)
```text

### Use Case: Fair Ordering (SUAVE)

```text
Without TEE:  Builder sees all transactions, can frontrun
With TEE:     Builder's enclave processes encrypted txs
              → Cannot extract MEV without running code
              → Code is attested by Intel
```diff

---

## Practice Exercises

### Exercise 1: Attestation Verification
```python
# Given an SGX quote and expected MRENCLAVE:
quote_hex = "030002..."
expected_mrenclave = "a1b2c3..."

# Write code to:
# 1. Parse the quote
# 2. Verify the MRENCLAVE matches
# 3. Extract the enclave's public key
```text

## Exercise 2: Side-Channel Analysis
```python
Consider this enclave code:

def check_password(input, secret):
    for i in range(len(secret)):
        if input[i] != secret[i]:
            return False
    return True

1. What side-channel vulnerability exists?
2. How would an attacker exploit it?
3. How would you fix it?
```text

### Exercise 3: Reproducible Builds
```text
For SUAVE integration:
1. How do you ensure the code deployed matches GitHub source?
2. How do you handle dependencies?
3. What's the attestation verification flow in CI/CD?

---

Key Takeaways

1. TEEs enable trustless services - Run code operators can’t modify or inspect
2. Remote attestation is cryptographic proof - Verify exactly what’s running
3. Side channels are real - TEEs protect data, not access patterns
4. Key for blockchain - Enables private mempools, fair ordering, encrypted block building

---

What’s Next?

• SUAVE Architecture - How Flashbots uses TEEs for encrypted block building
• Nitro Enclave Sovereign Pod - Production implementation
• Security Architecture for Trading Firms - extended deep dive