Vertrauliche Ausführung (TEE): technische Referenz

Diese Seite richtet sich an IT-Sicherheitsverantwortliche, Datenschutzbeauftragte, Prüfer und Administratoren, die wissen wollen, wie die vertrauliche Ausführung funktioniert und was genau sich davon nachprüfen lässt. Die Einführung für alle anderen steht unter Vertrauliche Verarbeitung (TEE).

Die Modelle laufen beim Inferenzanbieter Privatemode von Edgeless Systems in einer vertraulichen Ausführungsumgebung. Die Angaben zur Hardware, zur Attestierung und zur Verschlüsselung auf dieser Seite folgen der öffentlichen Dokumentation des Anbieters und seinem veröffentlichten Quellcode. Die Angaben zum Zwischenspeicher, zum Nachweis je Interaktion und zur Verankerung in der Blockchain beschreiben, was SOFI selbst tut.

Vertrauensgrenzen

Vier Systeme sind beteiligt. Die entscheidende Frage ist, an welchen Stellen Inhalte im Klartext vorliegen und wer diese Stellen kontrolliert.

Grün hinterlegt sind die Komponenten, die in einer Confidential VM (CVM) laufen. Ihre Umgebung, also Hypervisor, Betriebssystem des Hosts und das Personal des Rechenzentrumsbetreibers, gilt als nicht vertrauenswürdig und wird durch die Hardware ausgeschlossen.

Stelle	Klartext?	Kontrolle	Absicherung
Browser oder App	ja	Kanzlei	Gerätesicherheit der Kanzlei, TLS
SOFI-Anwendung	ja, flüchtig beim Zusammensetzen der Anfrage und beim Durchreichen der Antwort	SOFI	EU-Rechenzentrum, Mandantentrennung in der Datenbank, keine Inhalte in Protokollen, Verträge
Vertraulicher Client	ja, flüchtig beim Ver- und Entschlüsseln	SOFI	läuft im SOFI-Cluster, nicht beim Anbieter
Netz zwischen SOFI und Anbieter	nein	Dritte	AES-GCM Ende zu Ende, zusätzlich TLS
Coordinator, Secret Service	nein, sie sehen nie eine Anfrage	Anbieter, aber attestiert	CVM, Attestierung
AI-Worker	ja, nur im verschlüsselten Speicher der CVM und im GPU-Speicher	attestiert, für den Anbieter unzugänglich	CVM, GPU im vertraulichen Modus, Attestierung, Laufzeitrichtlinie
Infrastruktur des Anbieters	nein	Anbieter und dessen Rechenzentrumsbetreiber	Speicherverschlüsselung der CPU, nie im Besitz der Schlüssel

Das ist die ehrliche Grenze der Technik: die Hardware schützt vor dem Inferenzanbieter, vor dem Modellanbieter und vor dem Betreiber der Rechenzentren. Vor SOFI selbst schützt sie nicht, denn die Anwendung muss die Anfrage zusammensetzen, bevor sie verschlüsselt wird. Für diese Stelle gelten die organisatorischen und vertraglichen Maßnahmen unter Sicherheit und Datenschutz. Für die Nachvollziehbarkeit sorgen die Nachweise weiter unten.

In Arbeit: Verschlüsselung ab dem Endgerät (Zero Knowledge)

Diese Stelle ist die letzte Lücke in der Kette. SOFI baut die vertrauliche Ausführung deshalb so aus, dass die Anfrage bereits im Browser oder in der App für die attestierte Umgebung verschlüsselt wird. Der vertrauliche Client wandert dafür aus dem Cluster von SOFI auf das Endgerät: Attestierung und Schlüsselaustausch finden dort statt. Die Anwendung reicht nur noch Chiffretext durch und sieht keinen Inhalt mehr, auch nicht flüchtig. Damit gilt die Zusicherung der Hardware auch gegenüber SOFI selbst. Voraussichtlicher Release: viertes Quartal 2026. Bis dahin beschreibt diese Seite den heutigen Stand.

Hardware

Jede Komponente des Anbieters läuft in einer Confidential VM auf AMD SEV-SNP oder Intel TDX. Der Prozessor verschlüsselt den Arbeitsspeicher der VM mit Schlüsseln, die er selbst erzeugt und nie herausgibt. Der Hypervisor und alle anderen VMs sehen nur Chiffretext. Beide Technologien schützen zusätzlich die Integrität: die VM liest, was sie geschrieben hat. Ein Austausch von Speicherseiten durch den Host fällt auf.

Technologie	Speicherverschlüsselung	Prozessoren
AMD SEV-SNP	AES-256	EPYC 9004 (Genoa) und 9005 (Turin)
Intel TDX	AES-128	Xeon 4. und 5. Generation
Intel TDX	AES-256	ab Xeon 6. Generation

Die Modelle rechnen auf NVIDIA H100 und B200. Beide beherrschen einen vertraulichen Modus, in dem die GPU einer CVM zugewiesen wird und die Verbindung zwischen CVM und GPU geschützt ist. Der GPU-Speicher gehört damit zur vertraulichen Umgebung; der Host kann ihn nicht lesen. Solange eine GPU nicht attestiert ist, bleibt sie für die Inferenz gesperrt (siehe GPU-Nachweis).

Der Anbieter führt eine öffentliche Liste bekannter Hardware-Schwachstellen mit dem Stand ihrer Behebung. Ob ein Firmware- oder Mikrocode-Stand eingespielt ist, wird nicht behauptet, sondern über die Attestierung geprüft: das Manifest nennt Mindestversionen. Ein Attestierungsbericht mit älterem Stand wird verworfen.

Attestierungskette

Attestierung beantwortet die Frage, ob am anderen Ende wirklich eine abgeschirmte Umgebung mit genau der erwarteten Software steht. Jede Vertrauensentscheidung folgt demselben Muster: hardwaresignierte Nachweise einsammeln, gegen veröffentlichte Referenzwerte prüfen und nur bei exakter Übereinstimmung Vertrauen gewähren, also Zertifikate ausstellen, Schlüssel freigeben oder eine GPU aktivieren.

Was ein Attestierungsbericht belegt

Der Prozessor stellt auf Anfrage einen signierten Bericht über die CVM aus. Der Signaturschlüssel ist aus einem Geheimnis abgeleitet, das bei der Fertigung in den Chip eingebrannt wurde. Sein Zertifikat führt zur PKI des Herstellers. Weder der Infrastrukturbetreiber noch Edgeless Systems können einen solchen Bericht fälschen. Der Bericht trägt drei Arten von Feldern:

Feld (SEV-SNP)	Feld (TDX)	Inhalt	Geprüft gegen
MEASUREMENT	MRTD, RTMR 0 bis 3	Startmessung über Firmware, Kernel, Initramfs und Kernel-Kommandozeile, darin der dm-verity-Wurzelhash des schreibgeschützten Dateisystems	Referenzmessung im Manifest
HOST_DATA	MRCONFIGID	Hash der Laufzeitrichtlinie, beim Start gesetzt und danach unveränderlich	Richtlinien-Hashes im Manifest
REPORT_DATA	REPORTDATA	64 Byte, vom Prüfer gewählt: Hash aus Sitzungsschlüssel und frischer Nonce	Bindung an genau diese Attestierungssitzung
CHIP_ID	Platform Instance ID	Kennung des physischen Prozessors	Liste der zugelassenen Maschinen im Manifest
TCB, Mikrocode	TCB	Sicherheitsversionen von Firmware und Mikrocode	Mindestversionen im Manifest
PLATFORM_INFO, POLICY	XFAM, TD_ATTRIBUTES	Plattformkonfiguration, etwa Debug aus, keine Migration	Vorgaben im Manifest

Die Startmessung allein sagt nur, welches Betriebssystem gebootet hat. Welche Container darin laufen, legt die Laufzeitrichtlinie fest: sie pinnt jedes Container-Image über seinen Digest, dazu Kommando, Argumente, Umgebungsvariablen und Mounts. Sie beschränkt außerdem, welche Aufrufe der Host in den Gast hinein machen darf. Ihr Hash wird beim Start in den Bericht geschrieben. Ein veränderter Container besteht die Attestierung damit nicht.

Die Maschinenliste ist die Antwort auf physische Angriffe wie TEE.fail: selbst wer eine andere SEV-SNP- oder TDX-Maschine kompromittiert, kann mit ihr keine Berichte erzeugen, die der Client akzeptiert, weil deren Chip-Kennung nicht in der Liste steht.

Das Manifest

Das Manifest ist eine JSON-Datei, die die gesamte serverseitige Installation beschreibt: welche Arbeitslasten auf welcher Hardware in welcher Konfiguration laufen dürfen. Es hat zwei Teile:

• Policies. Eine Zuordnung von jedem Richtlinien-Hash zur Identität der Arbeitslast, die er zulässt. Ein Eintrag je attestiertem Pod: Coordinator, Secret Service, je ein AI-Worker pro Modell.
• ReferenceValues. Je Prozessortyp die erwartete Startmessung, die Mindestversionen von Firmware und TCB, die geforderte Plattformkonfiguration und die Liste der zugelassenen Maschinen.

Das Manifest der Produktivumgebung ist öffentlich abrufbar. Alle vertrauenswürdigen Komponenten sind quelloffen und mit Nix reproduzierbar gebaut; veröffentlichte Skripte rechnen jeden Image-Digest nach und erzeugen das Manifest aus der Deploymentbeschreibung neu. Wer das tut, braucht Edgeless Systems auch als Herausgeber der Referenzwerte nicht mehr zu vertrauen.

Jede Änderung an Code, Konfiguration, Modellen oder Hardware braucht ein neues Manifest. Ein neues Manifest bedeutet eine neue Mesh-CA. Der Client bemerkt das beim nächsten Schlüsselaustausch und attestiert neu. Er kennt zwei Betriebsarten: mit festgepinntem Manifest verweigert er jede Abweichung; in der Standardbetriebsart übernimmt er das jeweils veröffentlichte Manifest, prüft die Installation dagegen und protokolliert jede Übernahme in ein lokales, nur anhängendes Journal. In keiner Betriebsart kann der Anbieter das laufende System still verändern. Der Client von SOFI läuft heute in der Standardbetriebsart.

Ablauf beim Verbindungsaufbau

Beim Start jeder Komponente auf der Seite des Anbieters:

Beim Start des vertraulichen Clients bei SOFI:

Nach diesem Ablauf beweist ein Zertifikat, das an die gepinnte Mesh-CA anschließt, „attestierte Komponente genau dieser Installation“. Die Attestierung selbst läuft nicht bei jeder Anfrage, sondern beim Aufbau des Vertrauens: Worker attestieren beim Start und bei jedem Neustart gegenüber dem Coordinator, der Client prüft den Coordinator beim Start. Der laufende Verkehr nutzt die ausgestellten Zertifikate.

GPU-Nachweis

Die CPU-Attestierung deckt den Worker ab, nicht die GPU. Dafür läuft im Worker ein eigener Container, der Attestation Agent. Sein Image und seine Argumente sind über die Laufzeitrichtlinie gepinnt; die Prüflogik für die GPU ist damit selbst Teil der CPU-Attestierung.

Der Nachweis ist ein SPDM-Austausch (DMTF DSP0274) über die Attestierungsschnittstelle der GPU, mit einer je GPU frisch erzeugten Nonce, signiert mit dem Geräteschlüssel der GPU, dessen Zertifikatskette zur Geräte-PKI von NVIDIA führt. Der Agent prüft die ECDSA-Signatur, die Nonce, Treiber- und VBIOS-Version gegen die zulässigen Listen und die Messwerte gegen die signierten Referenzmanifeste (RIM) von NVIDIA. Drei Zertifikatsketten werden per OCSP auf Widerruf geprüft (Geräteidentität, RIM-Signierer für Treiber und für VBIOS). Erst danach setzt der Agent die GPU über NVML in den Zustand „bereit“; bis dahin ist sie für die Inferenz nicht erreichbar.

Modellgewichte

Die Gewichte sind zu groß für ein Container-Image. Sie liegen auf einem vorgefertigten Datenträger, den ein weiterer Container des Workers schreibgeschützt unter dm-verity einhängt: jeder Block wird beim Lesen gegen einen kryptografischen Wurzelhash geprüft. Der erwartete Wurzelhash ist ein Argument dieses Containers, das Argument ist Teil der Laufzeitrichtlinie, deren Hash steht im Attestierungsbericht und muss zum Manifest passen. Ein Worker mit manipulierten Gewichten besteht die Attestierung nicht.

Kryptografie der Attestierung

Schritt	Verfahren
Signatur des SEV-SNP-Berichts	ECDSA auf NIST P-384 mit SHA-384 durch den VCEK des Chips; Kette über ASK zum ARK (beide RSA-4096)
Signatur des TDX-Quotes	ECDSA auf NIST P-256 durch die Quoting Enclave; Kette über das PCK-Zertifikat zur SGX Provisioning Certification Root CA
Signatur des GPU-Berichts	ECDSA durch den Geräteschlüssel der GPU; Kette zur Geräte-PKI von NVIDIA
Bindung bei attestiertem TLS	TLS 1.3; REPORT_DATA = SHA-512(Sitzungsschlüssel, Nonce); Mesh-Zertifikate mit ECDSA auf NIST P-256
Bindung bei der Coordinator-Prüfung	REPORT_DATA = SHA-256(Nonce, SHA-256(Manifestübergang), SHA-256(Root-CA), SHA-256(Mesh-CA))
Nonce	32 Byte aus einem kryptografischen Zufallsgenerator, für jede Attestierung neu

Weil jeder Bericht über eine frische Nonce signiert ist, lässt sich ein abgefangener Bericht weder in eine neue Sitzung einspielen noch über eine andere Verbindung weiterreichen.

Schlüsselaustausch und Verschlüsselung

Die Attestierung ist die Vorbedingung für jeden Schlüsselaustausch. Erst wenn der Client die Mesh-CA gepinnt hat, vereinbart er mit dem Secret Service den Schlüssel, mit dem Anfragen verschlüsselt werden.

1. Der Client erzeugt ein flüchtiges Schlüsselpaar und schickt den öffentlichen Schlüssel an den Secret Service.
2. Der Secret Service leitet mit HPKE ein gemeinsames Geheimnis ab. Das Schlüsselkapselungsverfahren ist X25519MLKEM768, ein Hybrid aus X25519 und dem post-quanten-sicheren ML-KEM-768 (NIST FIPS 203). Er antwortet mit dem gekapselten Schlüssel und seinem Zertifikat und signiert beides.
3. Der Client prüft das Zertifikat gegen die gepinnte Mesh-CA sowie die Signatur und leitet dasselbe Geheimnis ab.
4. Der Secret Service gibt den Schlüssel ausschließlich an Worker heraus, die der Coordinator attestiert hat, über gegenseitig authentifiziertes TLS mit Mesh-Zertifikaten.

Anfragen und Antworten werden mit AES-256-GCM verschlüsselt, also authentifiziert. Die Verschlüsselung geschieht im Client bei SOFI, die Entschlüsselung im Inference-Proxy innerhalb der Worker-CVM; die Antwort nimmt denselben Weg zurück. Diese Schicht liegt über der Speicherverschlüsselung der CVM und über dem TLS der Transportstrecke.

Nicht verschlüsselt sind die Felder, die der Anbieter zum Routen und Abrechnen braucht. In der Anfrage sind das model, stream, stream_options, max_tokens, max_completion_tokens und n; in der Antwort id und usage. Der Anbieter sieht also, welches Modell wann mit wie vielen Tokens angefragt wurde, aber nie den Inhalt.

Gegen „jetzt speichern, später entschlüsseln“ ist die Strecke ausgelegt: der Schlüsselaustausch ist hybrid post-quanten-sicher. AES-256 gilt auch gegenüber Quantenrechnern als ausreichend.

Der Client im Betrieb von SOFI

Der vertrauliche Client ist der Vertrauensanker der gesamten Kette. Er läuft nicht beim Anbieter, sondern im Cluster von SOFI in einem Rechenzentrum in der EU. Im Einzelnen:

• Abbild über Digest gepinnt. Welche Version läuft, steht in der Versionsverwaltung; ein Neustart kann keine andere Fassung ziehen.
• Minimale Rechte. Kein Root, schreibgeschütztes Wurzeldateisystem, alle Capabilities entfernt, Standard-Seccomp-Profil.
• Zugangsschlüssel als Datei. Der Schlüssel zum Anbieter wird aus einem Secret als Datei eingehängt, nicht als Argument übergeben, damit er in keiner Prozessliste steht.
• Netzwerkrichtlinie. Nur die Anwendung darf den Client erreichen. Nur auf seinem Port. Die Anwendung selbst hat keinen direkten Weg zum Anbieter; jede Anfrage muss durch den Client, also durch Attestierung und Verschlüsselung.
• Zwei Instanzen für Verfügbarkeit; beide attestieren unabhängig.

Auch die Vorverarbeitung bleibt in der Enklave. Bilder werden von einem bildfähigen Modell in der vertraulichen Umgebung zu Text gemacht, bevor das Antwortmodell sie sieht; rohe Bildbytes verlassen die Enklave nie. Die Vorprüfung und Anonymisierung im Modus Hybrid rechnet ebenfalls dort, siehe Was die Enklave nie verlässt.

Zwischenspeicher (Prompt-Cache)

Ein Sprachmodell berechnet für jedes Token einer Anfrage Schlüssel- und Wertvektoren (KV-Cache). Beginnen zwei Anfragen mit demselben Präfix, etwa derselben Anweisung und demselben Gesprächsverlauf, lässt sich diese Rechnung wiederverwenden. Das senkt die Zeit bis zum ersten Token und die Kosten. Dieser Zwischenspeicher ist aber kein harmloses Zwischenergebnis: aus einem KV-Cache lässt sich der Eingabetext weitgehend rekonstruieren. Er ist deshalb wie der Prompt selbst zu behandeln.

Wo er liegt

Der Zwischenspeicher liegt im GPU-Speicher und im verschlüsselten Arbeitsspeicher der Worker-CVM. Er verlässt die vertrauliche Umgebung nicht und ist damit durch dieselben Mechanismen geschützt wie die Anfrage selbst. Einträge sind flüchtig: der Worker verdrängt sie, sobald er Speicher braucht (LRU). Es gibt keine Ablage auf einem Datenträger und keine feste Aufbewahrung.

Der Zeitkanal

Ein Treffer im Zwischenspeicher ist schneller als ein Fehltreffer. Ohne Trennung könnte ein Angreifer mit Zugang zu demselben Dienst geratene Präfixe schicken und an der Antwortzeit ablesen, ob jemand anderes sie zuvor gesendet hat. So ließe sich ein fremder Prompt Block für Block erraten. Dieser Angriff braucht keinen Zugriff auf den Speicher des Workers; die Hardware schützt nicht davor. Er braucht eine eigene Gegenmaßnahme.

Salzung

vLLM teilt den Prompt in Token-Blöcke und bildet je vollem Block einen Cache-Schlüssel mit SHA-256. Der Schlüssel des ersten Blocks enthält ein geheimes Salz (cache_salt). Jeder weitere Schlüssel enthält den Schlüssel des vorigen Blocks. Das Salz zieht sich damit durch den gesamten Präfix.

Ein Treffer setzt denselben Präfix und dasselbe Salz voraus. Wer ein anderes Salz sendet, sieht für jede Vermutung nur Fehltreffer. Das Salz wird im verschlüsselten Teil der Anfrage übertragen und ist außerhalb der CVM nicht sichtbar.

Wie SOFI das Salz bildet

SOFI bestimmt den Geltungsbereich des Zwischenspeichers so eng wie möglich: je Benutzerin oder Benutzer, nicht je Organisation. Das ist strenger als üblich. Der Grund ist die Mandantengrenze innerhalb einer Kanzlei: zwei Mitglieder derselben Organisation dürfen nicht einmal über den Zeitkanal erfahren, was das jeweils andere gesendet hat.

Die Regeln im Einzelnen:

• Aus von Haus aus, fehlerhaft heißt aus. Der Zwischenspeicher ist ein Schalter, der ausgeschaltet startet. Fehlt das Geheimnis oder ist es kürzer als 32 Byte, wird kein Salz gebildet. Ohne Salz speichert der Anbieter nichts zwischen; das ist gemessen, nicht angenommen.
• Ableitung. Das Salz ist HMAC-SHA-256 über das Tripel aus Organisation, Nutzerkennung und aufgelöstem Modellnamen, mit einem Geheimnis, das nur der Server kennt. Es ist aus Kennungen nicht erratbar, wird nie protokolliert und nie an den Browser gegeben. Ein Client kann es nicht beeinflussen; das Anfrageschema kennt kein solches Feld.
• Das Modell steht im Schlüssel. Tauscht der Anbieter ein Modell still gegen ein neueres aus, wechselt das Salz mit. Der Zwischenspeicher trennt dann sauber, statt mit einem fremden Präfix dauerhaft ins Leere zu laufen.
• Nur nachweislich salzfähige Modelle. Ein Modell bekommt erst ein deterministisches Salz, wenn es entweder ausdrücklich freigegeben ist oder eine regelmäßige Sonde gemessen hat, dass es das Salz beachtet. Die Sonde schickt jedem Modell denselben langen Präfix dreimal: mit gleichem Salz, mit fremdem Salz und ohne Salz. Liest ein fremdes oder ein fehlendes Salz einen Eintrag, wird das Modell sofort gesperrt. Das ist ein Vertraulichkeitsbefund, kein Leistungsthema.
• Kein Bereich, kein Wiederverwenden. Aufrufe ohne Geltungsbereich, etwa die Bildvorverarbeitung eines rohen Belegs oder der Vertraulichkeitsklassifikator vor der Anonymisierung, bekommen ein frisches Zufallssalz mit 256 Bit. Der Eintrag wird geschrieben und nie wieder gelesen. Absichtlich wird nicht „gar kein Salz“ gesendet, weil ein gemeinsamer Behälter für ungesalzene Anfragen der schlimmere Fall wäre.
• Kein Vorwärmen, keine verlängerte Lebensdauer. Einträge entstehen nur aus einer tatsächlichen Anfrage. Eine längere Aufbewahrung, wie sie manche Anbieter anbieten, ist im Code verriegelt.
• Der Treffer wird nicht beziffert. Die Attestierungsliste zeigt den Anteil aus dem Zwischenspeicher als Einstufung (keine, teilweise, überwiegend), nicht als Zahl. Eine exakte Trefferzahl wäre ein präziseres Orakel als der Zeitkanal.

Die berufsrechtliche Einordnung: der Zwischenspeicher enthält nur, was ohnehin an den Dienstleister übermittelt wurde, dient nur derselben Anfrage und der unmittelbaren Nachfrage, schafft keine neue Stelle, an der ein Mensch Inhalte sehen könnte, verfällt von selbst und ist je Person getrennt. Unter diesen Bedingungen ist er kein eigenständiges Bedienen des Geheimnisses nach § 62a Abs. 4 StBerG, sondern die Art, in der die beauftragte Verarbeitung erbracht wird. Anlage 3 des Auftragsverarbeitungsvertrags benennt ihn.

Nachweis je Interaktion

Die Attestierung des Anbieters belegt die Installation. Sie belegt nicht, dass eine bestimmte Nachricht dort verarbeitet wurde. Deshalb erfasst SOFI zu jeder Antwort einen eigenen Nachweis, aus dem sich später belegen lässt, welches Modell bei welchem Anbieter wann eine konkrete Anfrage beantwortet hat.

Arten

Art	Wann	Was belegt ist
TEE, pro Sitzung	Modelle in der vertraulichen Umgebung des Anbieters	Die Installation war für die Sitzung attestiert. Der Datensatz bindet Anfrage und Antwort über ihre Prüfsummen; einen hardwaresignierten Beleg für genau diese Nachricht gibt es in dieser Architektur nicht.
Vertraglich	Freigeschaltete Modelle außerhalb der Enklave auf einem EU-Endpunkt	Welches Modell, welcher Endpunkt, wie viele Tokens, gebunden an Anfrage und Antwort. Von SOFI mit Ed25519 signiert, ausdrücklich als Selbstattestierung gekennzeichnet. Zusätzlich die Zusagen, die galten: EU-Endpunkt, kein Training, keine Aufbewahrung, Auftragsverarbeitungsvertrag.
TEE, pro Interaktion	Bestand aus der Zeit eines früheren Anbieters	Ein signierter Beleg des Anbieters je Nachricht mit Prüfsummen von Anfrage und Antwort, prüfbar gegen dessen Attestierungsbericht.

Der Datensatz enthält keine Inhalte. Die Anfrage und die Antwort gehen nur als SHA-256 ihrer Auszüge ein. Er lässt sich deshalb an Prüfer weitergeben, drucken oder in einem öffentlichen Register veröffentlichen, ohne Mandanteninhalte preiszugeben. Die Liste der Nachweise durchsucht aus demselben Grund nur Kennungen, nie Titel oder Text.

Die Prüfsumme

Zu jedem Nachweis gehört eine Prüfsumme: der SHA-256 über eine versionierte, kanonische JSON-Serialisierung der unveränderlichen Fakten (sortierte Schlüssel, kompakte Trennzeichen, UTF-8). Sie wird beim Erfassen berechnet und eingefroren, weil sie das Blatt ist, das später veröffentlicht wird.

{
  "v": 1,
  "messageId": "...",
  "conversationId": "...",
  "createdAt": "2026-09-17T09:41:07Z",
  "modelId": "...",
  "provider": "privatemode",
  "kind": "per_session",
  "receiptId": null,
  "evidence": null,
  "userSha256": "<SHA-256 des Anfrageauszugs>",
  "assistantSha256": "<SHA-256 des Antwortauszugs>"
}

Zwei Regeln des Preimages sind wichtig: das wandelbare Prüfergebnis einer späteren Nachprüfung ist ausgeschlossen, damit eine erneute Prüfung die Prüfsumme nicht ändert. Und solange eine Antwort noch fortgesetzt werden kann, wird die Prüfsumme über die endgültige Antwort neu gebildet; ab dem Moment der Verankerung ist sie unveränderlich.

Der Nachweis lebt in einem löschfesten Journal, nicht an der Nachricht. Wird ein Chat gelöscht, bleibt der Nachweis vollständig und prüfbar; er zeigt nur an, dass es zu ihm keinen Chat mehr zu öffnen gibt. Beim Löschen eines Kontos wird der Personenbezug im Journal pseudonymisiert, der Datensatz selbst bleibt als Abrechnungs- und Nachweisbeleg.

Signatur der vertraglichen Nachweise

Vertragliche Nachweise signiert SOFI mit Ed25519 über dasselbe kanonische Preimage. Die Signatur belegt genau dies: SOFI hat diese Fakten zu dieser Interaktion festgehalten. Der Datensatz wurde seither nicht verändert. Nicht mehr. Der öffentliche Schlüssel und die Schlüsselkennung sind über die Anwendung abrufbar, damit sich ein exportierter Nachweis ohne SOFI prüfen lässt. Bei jedem Lesen wird außerdem geprüft, ob die gespeicherten Fakten noch ihren hinterlegten Digest ergeben; ein nachträglich veränderter Datensatz wird als solcher gekennzeichnet, nicht als „verifiziert“.

Verankerung in der Bitcoin-Blockchain

Eine Signatur beweist, dass SOFI einen Nachweis ausgestellt hat. Sie beweist nicht, dass SOFI ihn später nicht neu ausgestellt hat: wer Schlüssel und Datensatz hält, kann jederzeit neu signieren. Eine Signaturprüfung ist dagegen blind. Der öffentliche Anker schließt genau diese Lücke. Die Prüfsumme wird in einem Register festgeschrieben, das auch SOFI nicht nachträglich ändern kann. Das geschieht, bevor es einen Streit darüber gibt.

Merkle-Stapel

Eine Transaktion je Interaktion würde mit dem Chatvolumen skalieren. Stattdessen wird jede Prüfsumme ein Blatt eines Merkle-Baums. Ein täglicher Lauf faltet alle noch nicht verankerten Blätter zu einer einzigen 32-Byte-Wurzel. Nur die Wurzel wird veröffentlicht; ein Anker deckt beliebig viele Interaktionen ab. Jede Interaktion behält ihren Einschlusspfad: die Geschwister-Hashes auf dem Weg vom Blatt zur Wurzel, mit der Seite, auf der sie anzuhängen sind.

Konstruktionsregeln, die für eine unabhängige Nachrechnung zählen:

• Die Blätter werden vor dem Bau nach ihrem Hash sortiert, damit dieselbe Menge immer dieselbe Wurzel ergibt.
• Ein Knoten ohne Partner wird unverändert hochgereicht, nicht verdoppelt. Das Verdoppeln des letzten Knotens ist die klassische Formbarkeitslücke (CVE-2012-2459), bei der zwei verschiedene Blattmengen dieselbe Wurzel ergeben.
• Gehasht wird mit SHA-256 über die 64 Byte aus den beiden 32-Byte-Kindern.
• Der Lauf faltet Chat-Nachweise und die Nachweise ausgeführter Workflows in dieselbe Wurzel, über alle Organisationen hinweg. Das gibt nichts preis, weil ein Blatt der SHA-256 eines Datensatzes ist, der selbst keinen Inhalt trägt.
• Das Versiegeln der Blätter und das Anlegen des Ankers geschehen in einer Transaktion. Ein Blatt kann nie auf einen Stapel zeigen, dessen Wurzel es nicht abdeckt. Scheitert die Veröffentlichung, werden die Blätter freigegeben und rollen in die nächste Wurzel.

OpenTimestamps

Die Wurzel geht an zwei öffentliche OpenTimestamps-Kalender. Ein Kalender nimmt Digests vieler Einreicher entgegen, fasst sie in einen eigenen Merkle-Baum und schreibt dessen Wurzel in eine Bitcoin-Transaktion, die er selbst bezahlt. Dafür braucht SOFI weder eine Wallet noch einen privaten Schlüssel. Der Preis ist Latenz: die Zusage des Kalenders kommt sofort, die Bestätigung durch einen Bitcoin-Block innerhalb einiger Stunden.

Gespeichert wird je Kalender eine gewöhnliche, abgetrennte .ots-Datei: Magic, Version, die Operation SHA-256, der 32-Byte-Digest und die Zeitstempelbytes des Kalenders. Das ist absichtlich das Standardformat, damit sich der Beleg mit jedem gewöhnlichen OpenTimestamps-Client lesen und aufwerten lässt, unabhängig von SOFI. Der gestempelte Wert ist die Merkle-Wurzel von SOFI, nicht eine Datei auf einem Datenträger.

Der Abgleich, Glied für Glied

Beim Abgleich eines Nachweises mit der Blockchain werden vier Glieder geprüft. Jedes Glied ist wahr, falsch oder nicht prüfbar.

Für das vierte Glied liest SOFI den Blockkopf bei einem öffentlichen Explorer mit Esplora-Schnittstelle (Vorgabe: mempool.space). Zwei Abfragen genügen: der Hash des Blocks zur Höhe, dann der rohe 80-Byte-Kopf zu diesem Hash. Der Kopf wird nicht als JSON-Feld übernommen, sondern selbst gehasht; sein doppelter SHA-256 muss dem Hash entsprechen, den der Explorer für die Höhe genannt hat. Die Merkle-Wurzel des Blocks steht an fester Stelle im Kopf (Byte 36 bis 68, in umgekehrter Bytereihenfolge) und wird mit dem Wert verglichen, den der OpenTimestamps-Beleg verlangt.

Was dieser Abgleich nicht tut: er prüft weder die Arbeitsnachweise (Proof of Work) noch die Kettenkontinuität. Für die Aussage „das ist Block N“ wird dem Explorer vertraut. Wer das nicht will, prüft mit einem eigenen Bitcoin-Knoten, siehe unten. Ein nicht erreichbarer Explorer gilt als nicht prüfbar, nie als Übereinstimmung: „wir konnten nicht nachsehen“ ist nicht „es stimmt“.

Unabhängig nachrechnen

Alles Nötige steht im PDF eines Nachweises, dessen Anhang jeden Wert nennt. Die Schritte ohne SOFI:

1. Blatt nachrechnen. Das kanonische JSON aus den Werten des Anhangs bilden (sortierte Schlüssel, kompakte Trennzeichen, UTF-8), SHA-256 darüber. Das Ergebnis muss die Prüfsumme des Nachweises sein.
2. Zur Wurzel falten. Für jeden Schritt des Einschlusspfads: steht das Geschwister links, SHA-256(Geschwister ‖ akkumuliert), sonst SHA-256(akkumuliert ‖ Geschwister). Das Ergebnis muss die Merkle-Wurzel des Ankers sein.
3. Beleg aufwerten. Die .ots-Datei mit einem gewöhnlichen OpenTimestamps-Client aufwerten (ots upgrade) und lesen (ots info). Der Beleg nennt die Blockhöhe und die Merkle-Wurzel des Blocks, die er verlangt. ots verify erwartet eine Zieldatei und ist hier nicht das richtige Werkzeug, weil gestempelt eine Wurzel ist, keine Datei.
4. Block prüfen. Den Blockkopf zur Höhe bei einem eigenen Bitcoin-Knoten oder einem Explorer des eigenen Vertrauens lesen und die Merkle-Wurzel vergleichen.
5. Signatur prüfen (nur vertragliche Nachweise). Ed25519 über das kanonische JSON, mit dem in der Anwendung veröffentlichten Schlüssel.

Stimmen alle Schritte, ist belegt: dieser Datensatz existierte in genau dieser Form, bevor der genannte Bitcoin-Block gefunden wurde. SOFI hat ihn seither nicht verändert.

Grenzen und Restrisiken

• Die Anwendung sieht heute noch Klartext. Die vertrauliche Ausführung schützt vor dem Inferenzanbieter und dessen Infrastruktur. SOFI muss die Anfrage zusammensetzen und die Antwort durchreichen; dort greifen Rechenzentrum in der EU, Mandantentrennung, der Verzicht auf Inhalte in Protokollen, Zugriffskontrolle und die Verträge im Trust Center. Die Verschlüsselung ab dem Endgerät, die diese Lücke schließt, ist in Arbeit (siehe Vertrauensgrenzen).
• Attestierung je Sitzung. Für Modelle in der vertraulichen Umgebung gibt es keinen hardwaresignierten Beleg je Nachricht. Der Nachweis bindet die Nachricht über SOFI und über die Blockchain, die Hardware bestätigt die Installation.
• Metadaten beim Anbieter. Modellname, Tokenzahlen, Zeitpunkte und Anfragevolumen sind für den Anbieter sichtbar; sie werden zum Routen und Abrechnen gebraucht.
• Standardbetriebsart des Clients. Der Client übernimmt das veröffentlichte Manifest und protokolliert jede Übernahme. Ein festgepinntes Manifest, das jede Änderung verweigert, wäre strenger und würde bei jeder Aktualisierung des Anbieters den Dienst anhalten, bis jemand die Änderung geprüft hat.
• Hardware. Confidential Computing ist so stark wie die Hardware und ihre Firmware. Die bekannten Angriffe sind beim Anbieter gepatcht oder durch die Maschinenliste entschärft; das wird per Attestierung geprüft. Was noch nicht bekannt ist, deckt keine Liste ab.
• Zwischenspeicher. Die Trennung beruht auf einem Geheimnis und auf dem Verhalten des Modells. Beides wird gemessen; ein Modell, das das Salz nicht beachtet, wird gesperrt. Verdrängte Einträge können bis zur Verdrängung im Speicher des Workers bleiben.
• Was die Enklave verlässt. Web-Suche und Sprachausgabe verlassen die Umgebung, mit den Vorkehrungen unter Sicherheit und Datenschutz.
• Verankerung braucht Zeit. Ein Nachweis wird innerhalb eines Tages in eine Wurzel gefaltet und einige Stunden später von Bitcoin bestätigt. Bis dahin ist er signiert und intern prüfbar, aber noch nicht öffentlich verankert; die Anwendung sagt das.
• Explorer als Quelle. Der Abgleich vertraut einem öffentlichen Explorer für die Zuordnung von Blockhöhe zu Blockkopf. Wer das nicht will, prüft mit einem eigenen Knoten.

Quellen

• Privatemode: Sicherheit, Attestierung, Manifest, Attestierungsnachweise, Verschlüsselung, Sicherheit des Prompt-Caches, Post-Quanten-Kryptografie, Hardware-Integrität, Architektur
• Quellcode von Privatemode und das Manifest der Produktivumgebung
• Contrast, das Framework für Attestierung und Laufzeitrichtlinien
• OpenTimestamps und die Esplora-Schnittstelle für Blockköpfe
• NIST FIPS 203 (ML-KEM), DMTF DSP0274 (SPDM), BSI TR-02102-1