How attestation works

TL;DR

1. Two distinct TEEs run in every Cocoon session: the SDK-facing cocoon-bridge and the upstream Cocoon inference proxy. Both are TDX VMs; each runs its own measured image.

2. Both source trees are open and both images are reproducible — anyone can rebuild either and confirm it produces the published measurement.

3. On every WebSocket session the SDK receives one per-session cocoon-bridge quote that binds the session public key and the running configuration hash to the hardware.

End result: the operator running Shroud cannot read your prompts. They can't substitute either TEE image silently — the verified measurement and the on-chain proxy check together block any substitution.

Step 1 — Two Trusted Execution Environments

Shroud's confidential inference path runs across two Intel TDX VMs:

• cocoon-bridge — the SDK-facing TEE. Handles the WebSocket session, ECDH key exchange, and per-session AES-256-GCM re-encryption between the SDK and the upstream proxy. Open source at github.com/AlphaCompute/cocoon-bridge.

• Cocoon proxy — the inference router that cocoon-bridge forwards decrypted requests to. Runs in its own TDX VM with its own measured boot.

Both TEEs benefit from the same TDX guarantees:

• The hypervisor and host kernel cannot read TEE memory.

• The CPU produces a cryptographic measurement of the boot image (kernel + initrd + cmdline + RTMR-extended runtime data).

• A TEE-resident program can ask the CPU to sign that measurement bound to arbitrary 64 bytes of caller data — the attestation quote.

The two TEEs are connected by RA-TLS: at startup, cocoon-bridge performs a TLS handshake with the Cocoon proxy in which the proxy's self-signed certificate carries its TDX quote in an X.509 extension (OID 1.3.6.1.4.1.12345.1). cocoon-bridge verifies the proxy by computing the proxy image hash from the quote's measurement registers and calling proxy_hash_is_valid() on the TON CocoonRoot smart contract at the address in spec_envs.COCOON_ROOT_CONTRACT. cocoon-bridge refuses to start if that check fails. The SDK confirms this transitively by reading the hardware-bound spec_envs from the attestation bundle.

The auth/billing gateway (shroud-go) runs outside any TEE and is treated as untrusted by both the SDK and cocoon-bridge. It caches attestation artifacts but every cryptographic check happens between the SDK and the TEEs.

Step 2 — Measured boot

When a cocoon-bridge VM boots, the CPU records what was loaded into each measurement register. The bridge's identity is recovered from those registers in the per-session quote and compared register-by-register against the values predicted by the signed release manifest (Step 4). Any change to the kernel, initrd, root filesystem, cmdline, or measured runtime configuration produces a different set of measurements.

At boot, shroud-init also binds the running spec_hash — a SHA-256 over the measured environment variables — into the measurement registers, making the configuration part of the hardware-signed quote. See Wire protocol for the exact construction.

Step 3 — Reproducible enclave image

A measurement is only useful if you can tie it to a specific piece of source code. Shroud's TEE images are produced by a deterministic, fully offline build:

• Source code lives at github.com/AlphaCompute/cocoon-bridge.

• The build is driven by mkosi v26 with a pinned Debian snapshot (20251105T150124Z), SOURCE_DATE_EPOCH=0, and a fixed MachineId.

• Rust toolchain (1.88.0), Intel SGX DCAP repo (v1.23), OVMF firmware, and every crate dependency are pre-fetched and checksum-verified before the build starts; the build itself runs with no network access (cargo build --release --features dcap,ton-onchain --offline --locked).

• --remap-path-prefix strips build-host paths from the binary so the only state that varies between builds is bytes the source itself controls.

• The output is an erofs root filesystem with a veritysetup hash tree using a pinned UUID and salt, plus a one-line image.hash artifact and an image.cmdline containing roothash=<hash>.

What this means for a verifier: clone the repo, run scripts/build-image prod, then sha256sum the resulting rootfs. The hash will match the image.hash committed alongside each release. There is no transparency log or trusted third party in this loop — the source is open and the build is deterministic, so two independent builders produce byte-identical images.

Step 4 — SDK verification

shroud-go acts as an untrusted byte cache that the SDK uses to fetch three artifacts: the attestation bundle (spec_envs, spec_hash, and related configuration), Intel PCS collateral for DCAP verification, and the Sigstore-signed release manifest keyed by spec_envs.SHROUD_GIT_COMMIT. shroud-go cannot forge any of these — every artifact is verified by the SDK against an external trust root (Intel for the quote, GitHub OIDC + Sigstore for the manifest, the SDK's own recomputation for spec_hash).

When a Cocoon SDK opens a WebSocket session, the session response includes a config_id — the lookup key the SDK uses to fetch the attestation bundle from shroud-go. The SDK then verifies, in order:

1. DCAP-verify the per-session quote. Intel DCAP confirms the quote was signed by genuine TDX hardware and that the CPU's TCB level is acceptable.

2. Confirm REPORT_DATA binds the session key and spec_hash. The quote's REPORT_DATA encodes both the session public key and the running spec_hash, proving this key was minted inside this specific TEE running this specific configuration. See attestation-baseline.md §1.4 for the exact encoding.

3. Recompute spec_hash from the bundle. The SDK independently recomputes spec_hash from the spec_envs and spec_files in the attestation bundle and confirms it matches what the quote committed to.

4. Fetch and verify the release manifest. The SDK fetches a Sigstore-signed release manifest from shroud-go (GET /v1/attestation/release-manifest/{git_commit}, keyed by spec_envs.SHROUD_GIT_COMMIT), verifies the cosign bundle against the pinned GitHub OIDC identity for cocoon-bridge releases, and compares the quote's measurement registers against the manifest's predicted values register-by-register.

5. Inspect spec_envs. The SDK asserts ATTESTATION_PROVIDER == "tdx", COCOON_IS_TEST == "false", and TDX_VERIFICATION_MODE == "dcap". Optionally, COCOON_ROOT_CONTRACT can be checked against a known production address.

If any of those checks fail the SDK refuses the connection — the AttestationError (TS) or the corresponding Inference() error (Go) is raised before any prompt leaves the client.

See attestation-baseline.md §5.2 for the exact byte-level steps.

Trust roots

Three independent trust roots back the SDK's verification:

shroud-go is not a trust root. It is a byte cache — any substitution it attempted would fail the SDK's independent verification against these three external roots.

Related

• Verification paths — three workflows for three audiences.

• Threat model — what this protects against and what it doesn't.

• Confidential inference — Cocoon architecture.

• Wire protocol — the byte-level details.