Geprüft in Ihrem Browser.
Versiegelt für die Enklave.

Kurz gesagt

Undergrove betreibt Open-Weight-Modelle in Hardware-Enklaven, die Tinfoil betreibt. Einiges davon prüft Ihr Browser selbst, einiges ist Tinfoils Aussage, und einiges hängt an uns. Hier steht, was was ist.

Nichts davon wurde bisher unabhängig geprüft.

01 · Attestierung

Der Chip bürgt für den Code.

Eine Hardware-Enklave ist ein Teil eines Servers, in den sein eigener Host nicht hineinsehen kann: Der Prozessor verschlüsselt den Speicher der Enklave und hält die Software des Hosts heraus. Für sich genommen wäre das nur ein Versprechen. Prüfbar wird es durch Attestierung. Beim Start der Enklave misst der Prozessor den geladenen Code und signiert einen Bericht über diese Messung mit einem Schlüssel, für den der Chiphersteller bürgt. Der Bericht nennt auch den öffentlichen Schlüssel, mit dem die Enklave entschlüsseln wird.

Vor Ihrer ersten Nachricht holt der Arbeitsbereich diesen Bericht für Tinfoils Router-Enklave über unseren Server ab und lässt Tinfoils quelloffenen Prüfer in Ihrem Browser darauf laufen. Dass er über uns kommt, ändert nichts: Wir können die Signatur des Chips nicht fälschen, und ein Bericht, der die Prüfung nicht besteht, stoppt alles.

Die Prüfungen des Prüfers, der Reihe nach

1. Das Release finden, das Tinfoil für diesen Code veröffentlicht hat.
2. Den Hardware-Attestierungsbericht der Enklave gegen die Signaturschlüssel des Chipherstellers prüfen.
3. Die signierte Build-Aufzeichnung des Releases prüfen (Sigstore, von GitHub).
4. Vergleichen: Der in der Enklave gemessene Code muss genau dieses Release sein.
5. Prüfen, dass der Verschlüsselungsschlüssel derjenige ist, den die Attestierung der Enklave nennt.

Wir können die Signatur des Chips nicht fälschen, und ein Bericht, der die Prüfung nicht besteht, stoppt alles.

Ein geprüfter Bericht wird bis zu zehn Minuten wiederverwendet, in diesem Tab oder einem anderen Tab dieser Website, und nur, wenn es genau derselbe ist, gemessen an seinem SHA-256. Der Arbeitsbereich zeigt jede Prüfung unter „Geprüft“, und die Architekturseite zeigt den Code, der sie ausführt.

02 · Versiegeln

Nur die Enklave kann es öffnen.

Ist die Enklave geprüft, wird jede Live-Anfrage in Ihrem Tab versiegelt, bevor sie ihn verlässt. Ihr Inhalt wird mit EHBP, Tinfoils Protokoll zum Verschlüsseln von HTTP-Inhalten, für den Schlüssel verschlüsselt, den die Attestierung genannt hat. EHBP nutzt HPKE, einen Standard zum Verschlüsseln für den öffentlichen Schlüssel eines anderen: Ihr Tab erzeugt für die Anfrage ein neues Schlüsselpaar, kombiniert es mit dem Schlüssel der Enklave zu einem gemeinsamen Geheimnis und verschlüsselt mit AES-256-GCM.

Die neue öffentliche Hälfte reist neben dem Chiffretext mit, als gekapselter Schlüssel. Nur der private Schlüssel der Enklave, der die Enklave nie verlässt, kann daraus wieder das Geheimnis machen. Die Antwort kommt auf dieselbe Weise zurück, in versiegelten Blöcken, die Ihr Tab beim Eintreffen öffnet.

03 · Das Relay

Bytes, die es nicht lesen kann.

Versiegelte Anfragen gehen an unser Relay, eine Funktion auf Vercel, statt direkt an Tinfoil. Es prüft, wer fragt und ob das Kontingent reicht, und setzt Undergroves Tinfoil-Schlüssel auf die Anfrage, damit Sie kein Konto bei Tinfoil brauchen. Es lehnt alles ab, was nicht an einen von Tinfoils eigenen Hosts gerichtet ist oder keinen gekapselten Schlüssel trägt.

Es kann Ihre Wörter nicht zählen, also schätzt es die Kosten jeder Anfrage aus der Größe des Chiffretexts, eher zu hoch. Es behält keine Kopie, und seine Logs enthalten nur Routennamen, Statuscodes und Zeiten.

04 · Belege

Zwei Enklaven und ein Beleg für jede Antwort.

Die Router-Enklave, die Ihr Browser geprüft hat, führt das Modell nicht aus. Sie öffnet Ihre Anfrage und gibt sie an die Enklave weiter, in der das Modell mit seinen GPUs läuft. Diese prüft der Router selbst, nach seinem veröffentlichten Code, und nennt sie in einem Antwort-Header.

Ihr Browser prüft dann auch diese genannte Enklave, mit demselben Prüfer, gegen das Repository, das Tinfoils Router für dieses Modell festlegt. Was er findet, wird als Beleg mit der Antwort gespeichert: die Enklave, der darin gemessene Code, das passende Release und der Schlüssel, mit dem die Anfrage versiegelt wurde. Ein Beleg ist die eigene Aufzeichnung Ihres Browsers, nicht von uns oder von Tinfoil signiert; die Attestierung dahinter ist von AMD und GitHub signiert, sodass jeder sie erneut prüfen kann.

05 · Die Entwickler-API

Ein anderer Weg, offen gesagt.

Code, der die Entwickler-API aufruft, sendet seine Anfrage über HTTPS an unser Gateway, das sie liest: um sie zu prüfen, Limits anzuwenden und Werkzeuge auszuführen. Es liest sie im Arbeitsspeicher und speichert oder protokolliert sie nie. Dann tut das Gateway, was Ihr Browser im Arbeitsbereich tut: Es prüft die Enklave mit Tinfoils SDK und versiegelt die Anfrage für sie.

Auf diesem Weg vertrauen Sie uns die Anfrage also an, solange das Gateway sie hält. Prüfen können Sie weiterhin die Enklave: Jede Antwort über Tinfoils Route trägt Header, die das vom Gateway geprüfte Attestierungspaket nennen, damit Sie es erneut prüfen können. Die Entwicklerdokumentation zeigt, wie.

06 · Diese Seite

Den Code prüfen, der prüft.

Alles oben läuft in Code, den diese Website an Ihren Browser sendet, also zählt auch dieser Code. Jeder Build schreibt ein Manifest: den SHA-256 jeder Datei, die die Website ausliefert, und den Commit, aus dem er gebaut wurde.

Eine Seite kann nicht ganz für sich selbst bürgen: Eine Prüfung, die in der Seite läuft, ist nur so ehrlich wie die Seite. Die stärkere Prüfung kommt ganz ohne uns aus: Bauen Sie den Commit selbst in der festgelegten Umgebung und vergleichen Sie die Manifeste.

07 · Grenzen

Was das nicht beweist.

• Tinfoils Aussagen bleiben Tinfoils Aussagen. Dass es nicht auf seine Enklaven zugreifen kann, dass nichts darin Neustarts überdauert und dass seine GPUs im Confidential-Computing-Modus laufen, sagt Tinfoil. Ihr Browser prüft, dass die Hardware echt ist und den veröffentlichten Code ausführt.
• Die Hardware gehört zu dem, dem Sie vertrauen. Der Schutz ist so gut wie die Prozessoren, ihre Firmware und die Schlüssel der Chiphersteller, und Hardware-Enklaven hatten schon veröffentlichte Schwachstellen.
• Ein Abschnitt stützt sich auf veröffentlichten Code. Dass Ihre Anfrage vom Router zur Enklave des Modells ging, stützt sich auf den veröffentlichten Code des Routers. Ihr Browser kann die Enklave des Modells nur auf AMD SEV-SNP prüfen; auf Intel TDX wird sie als nicht geprüft vermerkt.
• Das Relay sieht das Äußere. Ihr Konto, Ihre IP-Adresse, Größen, Zeiten und welches Modell geantwortet hat.
• Veröffentlicht ist nicht dasselbe wie geprüft. Der Prüfer zeigt, welcher Code läuft, nicht, dass der Code fehlerfrei ist.
• Noch keine unabhängige Prüfung. Bisher hat kein Auditor dieses Design oder seinen Code begutachtet.

Wer was sehen könnte, Beobachter für Beobachter, steht im Bedrohungsmodell.

08 · Weiterlesen

Jeden Teil bei der Arbeit sehen.

• ArchitekturDie vier Stationen einer Nachricht, was jede sieht, und der Code dahinter.
• Selbst versiegelnTippen Sie eine Nachricht und sehen Sie zu, wie sie Schritt für Schritt für die Enklave versiegelt wird.
• Versuchen Sie, es zu knackenEine verschlüsselte Anfrage, Byte für Byte, wie unser Relay sie gesehen hat.
• BedrohungsmodellWer was sehen könnte: unser Hosting, wir, Tinfoil, das Netzwerk, ein Gericht.
• Diese Seite prüfenDen Hash des Codes bilden, den diese Seite geladen hat, und ihn mit dem Build vergleichen.
• TransparenzZahlen zu verschlüsselten Anfragen und Enklaven-Prüfungen sowie der Commit in Produktion.