Klartext bleibt im TEE-Speicher
TLS endet in der Gateway-TEE. Jede Anfrage ist an den Schlüssel der Anbieter-Enklave versiegelt, sodass der Router nur Chiffrat überträgt und den Schlüssel niemals besitzt.
Unabhängige Verifizierung
Warum das privat ist
Warum 0G deine Private-Compute-Prompts nicht lesen kann – und wie du es selbst überprüfst.
Dies ist die Kurzfassung. Das Verfahren findest du in verifying-the-gateway.md; das Design befindet sich unter design/.
Die kurze Antwort
Der Betreiber kann den Enklavenspeicher nicht lesen
Schlüssel werden im Enklavenspeicher erzeugt und aufbewahrt. Weder der Cloud-Host noch die 0G-Betreiber können die Schlüssel, Prompts oder entschlüsselten Antworten einsehen.
Beide TEEs sind prüfbar
Gateway- und Anbieter-TEEs veröffentlichen hardwaresignierte Messwerte und Release-Builds, sodass jeder genau überprüfen kann, welcher Code ausgeführt wird.
Wohin dein Prompt geht
Der Router leitet jede Anfrage weiter und rechnet sie ab, erhält aber nie den Schlüssel, der zum Öffnen des versiegelten Inhalts erforderlich ist.
Chiffrat · TLS
Dein Browser
Eine normale HTTPS-Sitzung, die in der Gateway-TEE endet.
Klartext · Speicher
Gateway-TEE
Die Anfrage ist an den Schlüssel der verifizierten Anbieter-Enklave versiegelt.
Chiffrat · HPKE
0G-Router
Leitet den versiegelten Inhalt ungeöffnet weiter und besitzt niemals den Entschlüsselungsschlüssel.
Klartext · Speicher
Anbieter-TEE
Das Modell läuft in derselben attestierten Enklave, die die Anfrage entschlüsselt.
Chiffrat · signiert
Antwort
Wird mit einer Enklaven-Signatur versiegelt zurückgegeben, die der Router nicht fälschen kann.
Nach der Antwort ruft das Gateway die Signatur des Anbieters ab – ohne den Prompt-Inhalt. Prompts werden niemals in Logs, Backups oder auf der Festplatte gespeichert.
Warum „in einer TEE“ überprüfbar ist
Der TLS-Schlüssel entsteht im Inneren
Das Eingangsgateway erzeugt seinen privaten Schlüssel innerhalb der vertraulichen VM und bindet das ausgestellte Zertifikat in eine Intel-TDX-Attestierungsquote ein. Stimmen Zertifikat und Attestierungsquote überein, beweist das, dass die TLS-Terminierung innerhalb der Enklave erfolgte.
Intel signiert den Hash des laufenden Builds
Die Attestierungsquote ist an das Deployment-Manifest gebunden, das jeden Container per Digest festschreibt. Jede Codeänderung erzeugt eine andere von der Hardware signierte Messung, die jeder mit einer veröffentlichten Version vergleichen kann.
Zuerst wird der Anbieter verifiziert
Das Gateway verifiziert die Attestierungsquote des Anbieters per DCAP und liest den Verschlüsselungsschlüssel des Anbieters aus diesem verifizierten Nachweis, niemals vom Router. Nicht verifizierte Anbieter und unsignierte Antworten werden abgelehnt.
Selbst überprüfen
Erstellen Sie das Verifizierungsprogramm und führen Sie einen einzigen Befehl gegen eine Gateway-Domain aus. Es validiert die Attestierungsquote von Intel, das Zertifikat, das Ihrer Verbindung ausgestellt wurde, den Code-Hash und die veröffentlichte Version.
$cd 0g-pc-e2ee/client && go build -o pcverify ./cmd/pcverify
$./pcverify -gateway <gateway-domain>
Was wir noch sehen können
Die Verschlüsselung des Inhalts verbirgt nicht alle umgebenden Metadaten. Der Router kann diese Felder lesen und auf ihrer Grundlage abrechnen, aber die Enklaven-Signatur verhindert, dass er sie verändert.
- Das von Ihnen angeforderte Modell, weil der Router es weiterleiten muss.
- Ihre genaue Token-Nutzung, weil der Router sie abrechnet.
- Nachrichtengrößen; der Geheimtext bewahrt die Klartextlänge plus eine Konstante.
- Anfrage- und Antwortzeiten, einschließlich der Zeiten gestreamter Datenblöcke.
Was das nicht beweist
- Erkennung, nicht Verhinderung. Ein unredliches Deployment wird öffentlich nur dann erkennbar, wenn jemand die Verifizierung ausführt.
- Eine bestandene Prüfung gilt nur für die geprüfte Verbindung, nicht automatisch für jede Enklave hinter derselben Domain.
- Das ist verifizierbare Weiterleitung, keine verifizierbare Berechnung. Es beweist, welche Enklave eine Antwort erzeugt hat, nicht die Qualität oder das Verhalten des Modells.
- Verfügbarkeit wird nicht attestiert; ein Deployment kann weiterhin offline genommen werden.
- Das gehostete Gateway fügt eine zweite Enklave hinzu, die den Klartext sieht. Clientseitige Versiegelung ist noch kein unterstützter Einstiegspunkt.
Tiefer eintauchen
Verifizierung des GatewaysJede Prüfung, jeder Exit-Code, jeder manuelle Schritt und jede aktuelle Einschränkung.VertrauensketteJeder Sprung und welche Verbindungen durchgesetzt und welche nur beobachtet werden.Design des Cloud-GatewaysWarum es das Gateway gibt und warum sein Attest vom Ingress stammt.ProtokollspezifikationDas Übertragungsformat zum Versiegeln von Anfragen und zum Nachweisen von Antworten.