RHETRA / Guides / Attestierung

KI-Attestierung & Confidential Computing, verständlich erklärt

Remote-Attestierung lässt eine CPU beweisen — mit einer Signatur, die Sie selbst verifizieren können —, welcher Code Ihre KI ausführt, in Speicher, den der Betreiber nicht lesen kann. Diese Technologie macht aus „vertrauen Sie uns, es läuft on-premise" eine prüfbare mathematische Aussage — und sie ist das Fundament unter jedem ernsthaften Souveränitätsversprechen. So funktioniert sie, ohne Whitepaper-Nebel.

1 · Das Problem: Betreibern muss man vertrauen

In klassischer Infrastruktur gehört dem Betreiber des Hosts faktisch, was darauf liegt. Ein Hypervisor kann den Speicher jedes Gasts lesen; ein Rechenzentrums-Admin mit den richtigen Rechten kann jeden Prozess dumpen. Verträge und Zertifizierungen regeln das — aber sie sind Versprechen. Für eine Bank oder ein Ministerium, das KI auf sensiblen Daten einsetzt, ist „der Betreiber verspricht, nicht hinzusehen" ein schwaches Fundament. Genau darum sagt der Standort eines Servers so wenig: Standort ist eine Postleitzahl, keine Eigenschaft des Systems.

2 · Verschlüsselter Speicher: der Betreiber fällt raus

Confidential Computing ändert das Vertrauensmodell in Hardware. Technologien wie AMD SEV-SNP und Intel TDX lassen eine VM in Speicher laufen, den die CPU mit Schlüsseln verschlüsselt, die der Host nie sieht. Der Hypervisor plant die VM weiterhin ein — liest aber nur Chiffretext. Das „Secure Nested Paging" von SEV-SNP schützt zusätzlich die Speicherzuordnung der VM gegen Manipulation durch einen bösartigen Hypervisor.

Ergebnis: Der Betreiber — Cloud-Provider, Rechenzentrums-Personal, selbst ein kompromittiertes Host-Betriebssystem — wird technisch aus der Vertrauensgleichung entfernt, nicht vertraglich.

3 · Attestierung: beweisen, was läuft

Verschlüsselter Speicher allein lässt eine Frage offen: verschlüsselt oder nicht — was läuft da eigentlich drin? Attestierung beantwortet sie:

• Beim Start misst die CPU den Code, der in die Confidential VM geladen wird — ein kryptografischer Hash über jedes Byte.
• Auf Anfrage erzeugt sie einen Attestierungsreport mit dieser Messung plus Plattformzustand (Firmware-Versionen, Sicherheitskonfiguration).
• Der Report ist mit einem in die CPU eingebrannten Schlüssel signiert, der bis zu den Root-Keys des Herstellers kettet (bei AMD: die VCEK/ASK/ARK-Kette).

Ist die Software reproduzierbar gebaut, kann jeder sie nachbauen, Hashes vergleichen und wissen — nicht glauben —, dass der auditierte Quellcode das laufende Binary ist.

4 · So verifizieren Sie einen Report selbst

• 1. Attestierungsreport vom laufenden System abrufen (ein API-Call).
• 2. Öffentliche Zertifikate des CPU-Herstellers laden (AMD publiziert sie online).
• 3. Signaturkette prüfen: Report → Chip-Key → Hersteller-Root. Open-Source-Tooling existiert; Mitwirkung des Anbieters ist nicht nötig.
• 4. Messung gegen den erwarteten Build-Hash vergleichen.

Vier Schritte, Standard-Kryptografie, kein Vertrauen in Betreiber oder Software-Anbieter. Das ist die Checkliste hinter unserer These „Souverän ist ein Beweis, keine Postleitzahl" — und exakt das, was ein Anbieter in einer Live-Session vorführen können sollte.

5 · Post-Quantum-Signaturen: Nachweise, die halten

Attestierung beweist die Laufzeitumgebung jetzt. Audit-Trails müssen über Jahre verifizierbar bleiben — durch Audits, Streitfälle, Aufsichtsprüfungen. Klassische RSA/ECC-Signaturen haben ein Verfallsdatum: Ein kryptografisch relevanter Quantencomputer bricht sie — und ermöglichte damit die rückwirkende Fälschung „historischer" Nachweise. NIST hat Post-Quantum-Signaturen genau für diesen Horizont standardisiert: ML-DSA (FIPS 204), die standardisierte Form von Dilithium.

Deshalb signiert das RHETRA-KRONOS-Gateway jede Policy-Entscheidung schon heute mit Dilithium5 und läuft in SEV-SNP-attestiertem Speicher: Entscheidungen, die jetzt beweisbar sind und beweisbar bleiben. Wie das konkrete Aufsichtspflichten erfüllt, steht im EU-AI-Act-Guide.