# Phase 2 — End-to-End to Enclave

**Version:** 0.1
**Scope:** Sovereign tier activation gate.
**Status:** Scaffold shipped; enclave-side runtime pending.

---

## 1. Why Phase 2 exists

Phase 1 places the session key briefly in the application server's memory so it can be handed to the TEE for decryption. A privileged ArcaKey operator with application-server access therefore has a theoretical window to read plaintext at the moment the key is handed across.

Phase 2 removes that window. The client and the TEE enclave establish a hybrid (X25519 + ML-KEM-768) shared secret directly. The application server is demoted to a relay that moves opaque ciphertext between the two endpoints.

Sovereign tier — whose contractual promise is that ArcaKey itself cannot read the customer's content — activates only when Phase 2 is live.

## 2. Endpoints

| Endpoint | Role |
|---|---|
| `GET /api/vault/enclave/pubkey` | Returns the enclave's ephemeral X25519 + ML-KEM-768 pubkeys, bound to an NRAS report and signed by ArcaKey's binding key. |
| `POST /api/vault/enclave/keyexchange` | Client posts its X25519 pub and an ML-KEM ciphertext encapsulated to the enclave pubkey. Server relays unchanged. Enclave returns a signed `enclave_session_id`. |
| `POST /api/vault/enclave/relay` | Streaming relay of opaque ciphertext between client and enclave. |

## 3. Client responsibilities

1. Verify the NRAS report in the pubkey response against NVIDIA's root of trust.
2. Verify the ArcaKey binding signature.
3. Verify that the hash of the pubkeys matches the NRAS user-data field. This prevents ArcaKey from substituting a different pubkey under the same attestation.
4. Generate an ephemeral X25519 keypair and an ML-KEM-768 ciphertext encapsulated to the enclave's ML-KEM pubkey.
5. Derive the shared secret with `HKDF(SHA-256, X25519_secret || ML-KEM_secret)`.
6. Subsequent traffic is encrypted under this secret with AES-256-GCM and sent through `/api/vault/enclave/relay`.

## 4. Enclave responsibilities

1. At boot, generate ephemeral X25519 and ML-KEM-768 keypairs.
2. Include `SHA-256(x25519_pub || mlkem_pub)` in the NRAS user-data field.
3. Serve `GET /pubkey` with the NRAS report and pubkeys.
4. On `POST /keyexchange`, decapsulate the ML-KEM ciphertext, derive the shared secret, issue a signed `enclave_session_id`, and hold the shared secret in sealed memory.
5. On `POST /relay`, decrypt incoming frames, run inference, and encrypt outgoing frames under the same shared secret.
6. Zeroize session state on relay close.

## 5. What the application server cannot do

- Read the plaintext prompt.
- Read the plaintext response.
- Substitute its own pubkey under the NRAS attestation (the user-data binding prevents this).
- Persist the shared secret (it never exists on the application server).

## 6. Activation gate

`ENCLAVE_E2E_ACTIVATED=true` plus a configured `ENCLAVE_BASE_URL` are both required before the endpoints route traffic. When either is missing, the endpoints return HTTP 503 with `{"error": "phase-2-not-activated"}`. Sovereign application intake is not gated by this flag; Sovereign billed activation is.

## 7. Deferred items

- Client-side verifier for the NRAS user-data binding. Ships alongside the enclave runtime.
- Open-source reference client so Sovereign customers can audit the key-exchange path themselves.
- Preemption handling on the enclave side if the underlying VM is preempted mid-session.

---

**Contact:** `security@arcakey.ai`