Calimero mero-tee
Trusted Execution Environment infrastructure for Calimero. Key management, TDX attestation, confidential VM images, and public verification — all inside hardware enclaves.
Start Here
New to the TEE infrastructure? Follow this path to understand how Calimero nodes run inside hardware enclaves.
System Overview
Understand the components: KMS, node images, and attestation verifier — and how they connect.
Trust Model
Learn the mutual attestation protocol: how nodes verify KMS and KMS verifies nodes.
Key Release Flow
Deep-dive into the challenge-response protocol for releasing storage encryption keys.
System Map
Component Index
mero-kms-phala
Rust HTTP service that validates TDX attestations and releases storage encryption keys via Phala dstack key derivation.
Node Images
Packer + Ansible builds for GCP TDX confidential VM images. Three profiles: debug, debug-read-only, locked-read-only.
Attestation Verifier
React SPA + serverless API for public attestation verification via Intel Trust Authority.
Trust Model
Mutual attestation: nodes verify KMS, KMS verifies nodes. Policy enforcement with MRTD, RTMRs, TCB allowlists.
Key Release Flow
Challenge-response protocol with nonce generation, signature verification, TDX quote validation, and dstack key derivation.
Config & Errors
All environment variables, attestation policy schema, error codes, and JSON response formats.
Key Concepts
TDX Attestation
Intel Trust Domain Extensions (TDX) creates hardware-isolated virtual machines. Attestation produces a cryptographic quote that proves code identity (MRTD), runtime state (RTMR0–3), and hardware TCB level. Remote parties verify quotes against expected measurements to establish trust.
Key Management
Storage encryption keys are never stored on disk. On boot, a node obtains its key from the KMS via a challenge-response protocol. The KMS derives keys using Phala dstack’s deterministic key derivation, ensuring the same key is always produced for the same namespace and node.
Mutual Verification
Trust is bidirectional. Nodes verify the KMS is running in a genuine TDX enclave via POST /attest. The KMS verifies each node’s TDX quote and policy compliance before releasing keys. Neither party trusts the other without hardware-backed proof.
Profile Cohorts
Node images are built with one of three profiles (debug, debug-read-only, locked-read-only). Each profile writes a distinct RTMR3 runtime event, creating cryptographic cohort separation — a debug node cannot impersonate a production node.