RHETRA / Guides / Attestation

AI attestation & confidential computing, in plain terms

Remote attestation lets a CPU prove — with a signature you can verify yourself — exactly which code is running your AI, inside memory the operator cannot read. It is the technology that turns "trust us, it runs on-premise" into a checkable mathematical claim, and it is the foundation under every serious sovereignty promise. Here is how it works, without the whitepaper fog.

1 · The problem: operators must be trusted

In classical infrastructure, whoever operates the host owns the data on it. A hypervisor can read every guest's memory; a data-centre admin with the right access can dump any process. Contracts and certifications regulate this — but they are promises, and for a bank or ministry using AI on sensitive data, "the operator promises not to look" is a weak foundation. This is also why where a server stands says so little: location is a postcode, not a property of the system.

2 · Encrypted memory: removing the operator

Confidential computing changes the trust model in hardware. Technologies like AMD SEV-SNP and Intel TDX run a VM inside memory that the CPU encrypts with keys the host never sees. The hypervisor still schedules the VM — but reads only ciphertext. SEV-SNP's "Secure Nested Paging" additionally protects the VM's memory mapping against manipulation by a malicious hypervisor.

Result: the operator — cloud provider, data-centre staff, even a compromised host OS — is technically removed from the trust equation, not contractually.

3 · Attestation: proving what runs

Encrypted memory alone leaves a question open: encrypted or not — what is actually running in there? Attestation answers it:

• At launch, the CPU measures the code loaded into the confidential VM — a cryptographic hash of every byte.
• On request, it produces an attestation report containing that measurement plus platform state (firmware versions, security configuration).
• The report is signed by a key fused into the CPU, chaining up to the vendor's root keys (for AMD: the VCEK/ASK/ARK chain).

If the software is built reproducibly, anyone can rebuild it, compare hashes, and know — not believe — that the audited source is the running binary.

4 · How you verify a report yourself

• 1. Obtain the attestation report from the running system (an API call).
• 2. Fetch the CPU vendor's public certificates (AMD publishes them online).
• 3. Verify the signature chain: report → chip key → vendor root. Open-source tooling exists; no vendor cooperation required.
• 4. Compare the measurement against the expected build hash.

Four steps, standard cryptography, no trust in the operator or the software vendor. This is the checklist behind our claim "sovereign is a proof, not a postcode" — and exactly what a supplier should be able to demonstrate in a live session.

5 · Post-quantum signatures: evidence that lasts

Attestation proves the runtime now. Audit trails must stay verifiable for years — through audits, disputes, regulatory review. Classical RSA/ECC signatures have an expiry date: a cryptographically relevant quantum computer breaks them, which would allow retroactive forgery of "historical" evidence. NIST has standardised post-quantum signatures — ML-DSA (FIPS 204), the standardised form of Dilithium — precisely for this horizon.

That is why the RHETRA KRONOS gateway signs every policy decision with Dilithium5 today and runs inside SEV-SNP-attested memory: decisions that are provable now and stay provable later. How that satisfies concrete regulatory duties is covered in the EU AI Act guide.