# ArcaKey Private AI — TEE Attestation Reference

**Version:** 0.1
**Date:** 2026-04-18
**Status:** Architecture and verification procedure. Live deployment status tracked below.

---

## 1. What this document is

This is the reference for how ArcaKey's TEE attestation works: what evidence is produced per session, how it is verified, how a customer can verify it independently, and how a customer can download the evidence artifact for their own records.

This is not a compliance certification. It is a recipe for verifying, cryptographically, that a given inference session ran inside a hardware-isolated environment you can name.

## 2. Attestation chain

A full attestation chain for an ArcaKey session contains four layers, each signed by the layer below.

1. **Session binding layer** — signed by ArcaKey's session-signing key. Binds `session_id`, `user_id`, `tier`, `timestamp_utc`, `model_id`, and the hash of the NRAS evidence below. This is what the user downloads.
2. **NRAS evidence layer** — signed by the NVIDIA Remote Attestation Service. Binds the H100 GPU identity, driver version, confidential-computing mode flag, the measured hash of the vLLM runtime image at boot, and a nonce supplied by ArcaKey for freshness.
3. **AMD SEV-SNP report layer** — signed by the AMD CPU's security processor. Attests VM memory encryption is active and binds the VM launch measurement.
4. **Root of trust** — NVIDIA's root certificate for NRAS and AMD's VCEK/VLEK for SEV-SNP. Both are published by the silicon vendors and are not under ArcaKey control.

A verifier who trusts NVIDIA's and AMD's roots of trust, and who trusts ArcaKey's session-signing public key (published on the /security page), can verify the entire chain offline.

## 3. Evidence artifact

Every session for a TEE-eligible tier (Executive, Sovereign, Teams Executive, Enterprise) generates a downloadable evidence artifact. A customer can download it from the attestation verifier UI or via the API.

**Artifact format:** signed JSON with detached-signature structure, filename `arcakey-attestation-<session_id>-<timestamp>.json`.

```
{
  "version": "0.1",
  "session": {
    "session_id": "sess_abc123",
    "user_id_hash": "sha256:...",
    "tier": "executive",
    "model_id": "qwen-72b-instruct",
    "started_at": "2026-04-21T14:30:00Z",
    "ended_at": "2026-04-21T14:47:12Z"
  },
  "tee": {
    "provider": "gcp-a3-cvm",
    "region": "northamerica-northeast1",
    "gpu": "nvidia-h100-80gb",
    "cc_mode": true,
    "driver_version": "550.x"
  },
  "nras_evidence": "<base64 signed NRAS report>",
  "snp_report":     "<base64 signed AMD SEV-SNP report>",
  "arcakey_binding_signature": "<base64 Ed25519>",
  "arcakey_binding_pubkey_id": "ak-sign-2026-04"
}
```

The `arcakey_binding_signature` is an Ed25519 signature over the canonical JSON of all preceding fields. The verification public key for `ak-sign-2026-04` is published at `https://arcakey.ai/docs/arcakey-attestation-pubkeys.json` and in this document at §5.

## 4. How to verify

Offline verification of an evidence artifact is a three-step process.

1. **Verify the ArcaKey binding.** Canonicalize the JSON, drop the `arcakey_binding_signature` field, recompute the Ed25519 signature using the public key identified by `arcakey_binding_pubkey_id`. If this fails, the artifact has been tampered with after ArcaKey signed it.
2. **Verify the NRAS evidence.** Use NVIDIA's `nvtrust` verifier, or NVIDIA's REST NRAS verification endpoint, with NVIDIA's published RIM (Reference Integrity Manifests) and OCSP feeds. If this fails, the GPU identity or CC-mode state in the artifact is not attested.
3. **Verify the SEV-SNP report.** Use AMD's published VCEK certificate chain and the `sev-tool` or equivalent verifier. If this fails, VM memory encryption cannot be confirmed.

A customer-supplied verification script is planned for Q3 2026. In the interim, contact `security@arcakey.ai` for help running the three verification steps against a specific artifact you hold.

## 5. Current published verification keys

```
{
  "keys": [
    {
      "id": "ak-sign-2026-04",
      "alg": "Ed25519",
      "public_key_base64": "o5Z4cHQZG0cts3qEBlKhWxsRY0J3d1fLj5l21KWDeCA=",
      "valid_from": "2026-04-19T00:00:00Z",
      "valid_until": "2027-04-19T00:00:00Z"
    }
  ]
}
```

The live runtime mirror of this JSON is served at `/api/vault/attestation/pubkey` — both must agree; rotation updates both.

## 6. Deployment status (as of 2026-04-18)

| Component | Status | Notes |
|---|---|---|
| Attestation verifier HTTP endpoint (`/api/vault/attestation/:sessionId`) | **Shipped** | Returns signed evidence artifact; NRAS evidence is stub-sourced until GCP A3 CC capacity is active |
| Downloadable evidence artifact link from /security | **Shipped** | Sample artifact available; per-session artifact available to authenticated TEE-tier users |
| GCP A3 Confidential VM — TEE-routed inference live | **Provisioning** | Capacity request with GCP sales; provisioned just-in-time |
| NRAS live verification against NVIDIA root | **Provisioning** | Wired; activates when GCP A3 CC capacity is online |
| Azure NCCads H100 v5 failover | **Architected** | Second provider slot for continuity; not yet live |
| Phase 2 end-to-end-to-enclave (Sovereign) | **Scaffold shipped** | Key-exchange API and client binding design in repository; Sovereign activation gated on production rollout |

## 7. Strategic note

The ArcaKey attestation verifier UI exists specifically so that customers can cryptographically verify a session's isolation guarantees themselves, rather than take our word for it. This is a deliberate design choice. If you are evaluating ArcaKey against other boutique-private-AI vendors, this is the artifact to ask each of them for. Most will not have one.

---

**Contact:** `security@arcakey.ai`
**Companion documents:** cryptographic-whitepaper-v0.1.md, threat-model-v0.1.md