Beratung: Eine kritische Erkenntnis im PIE Non-Custodial Compute Modell
Das Modell entfernt die Möglichkeit des Operators, etwas zu entschlüsseln, sobald ein Job endet. Das Gerät verschlüsselt weiterhin zu einem unverifizierten öffentlichen Schlüssel, der von der einheitlichen Komponente veröffentlicht wird, die das Modell als unzuverlässig einstuft.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
Ich baue seit 25 Jahren Systeme und liebe es, Dinge zu bauen, die absichtlich entworfen und operationell schlank sind, und nur so viel Vektor tragen, wie es wert ist.In diesem Ansatz hat es immer Sinn gemacht, das, was ich von den Daten eines Nutzers speichere, zu minimieren, aus Gründen, die über das Offensichtliche hinausgehen. Souveränität ihrer Daten ist wichtig. Unter der Oberfläche steckt etwas Einfacheres: Dinge gehören dort, wo sie gehören. Der Großteil dessen, was ich baue, ist Verarbeitung, und eine Verarbeitungsarchitektur hat keine andere Geschäftsfunktion. Ein Datensatz zu halten, den man nie benötigt hat, ist ein Vektor, der nichts wert ist. Das als Optimierung zu behandeln, statt als Compliance-Übung, hält das Design ehrlich – und ein System, das so gebaut ist, landet von selbst in gutem Verhältnis zur Regulierung, weil es sehr wenig zu regulieren gibt.Als Mary Camachos Ankündigung in meinem Feed auf X auftauchte, las ich ihre Architektur so, wie ich meine eigene lese. Sie hatte das Kernstück in das öffentliche Register unter einer Creative Commons Lizenz veröffentlicht, auf dem Detailniveau, das ein Ingenieur benötigen würde, um es neu zu bauen, und sie war direkt über die vorhandene Kunst, auf der es basiert.Durch die Sequenz arbeitend, platzierte ich eine gegnerische Entität im Server und verfolgte, was sie erreichen konnte. Sie konnte den Arbeiter überholen.Fast die gesamte Arbeit, die folgte, geschah als Sprachgespräch – über 30 Sprachnotizen, laut denken und die Bedenken aus verschiedenen Blickwinkeln testen, bis sie entweder hielt oder zusammenbrach.Was mir aufgefallen ist: Das Gerät verschlüsselt für die Person, die zuerst den Anspruchsdatensatz schreibt#
Die Offenlegung gibt die Reihenfolge der Operationen direkt an. Der Arbeiter beansprucht den Auftrag und veröffentlicht seinen Schlüssel, und erst dann verschlüsselt das Gerät:Die Seite des Geräts in dieser Vereinbarung wird mit gleicher Präzision festgelegt:— §2.1, Datenfluss (pro Auftrag)
- Arbeiter → Koordination: Abfrage und Anspruch des Auftrags (einmal schreiben, erster gewinnt), Veröffentlichung des öffentlichen Schlüssels des Arbeiters.
- Gerät ← Koordination: Abfrage, Abruf des öffentlichen Schlüssels des Arbeiters, Ableitung des gemeinsamen Geheimnisses, Verschlüsselung der Nutzlast.
Das Gerät, nachdem es den öffentlichen Schlüssel des Arbeiters erlernt hat, führt seinen eigenen X25519 Austausch durch und eine ML-KEM-Kapselung gegen den Schlüssel des Arbeiters, erzeugt seinen eigenen öffentlichen Beitrag (X25519 öffentlicher Schlüssel ‖ ML-KEM-Verschlüsselung) und das gemeinsame Geheimnis.— §4.2, Bindung an den Lebenszyklus des ArbeitersBeim Erlernen. Über 19 Seiten hinweg gibt es keine Signatur über den flüchtigen öffentlichen Schlüssel des Arbeiters, kein Zertifikat, keine Attestierung, die das Gerät bewertet, und kein vorab geteiltes Geheimnis. Das Fehlen ist absichtlich und wird als Stärke dargestellt: Das Modell sperrt die Entschlüsselung ohne Attestierungsdokument, TPM-Zitat oder gemessenen Boot-Artefakt und speichert kein vorab bereitgestelltes Arbeitergeheimnis.So verschlüsselt das Gerät seine Nutzlast für jeden öffentlichen Schlüssel, der im Anspruchsdatensatz sitzt, ohne Mittel, den legitimen Schlüssel eines Arbeiters von jedem anderen zu unterscheiden. Jede Partei, die zuerst einen Anspruch schreibt, wird die Partei, an die das Gerät verschlüsselt, und die vertrauliche Nutzlast entschlüsselt sich in ihren Händen.
flowchart TB
subgraph BEFORE["Vorher: wie veröffentlicht"]
direction TB
A2{"Wer beansprucht zuerst?"} -->|Reeller Arbeiter| A3["Echtes Schlüssel"]
A2 -->|Jeder andere Schreiber| A4["Angreifer-Schlüssel"]
A3 --> A5["Gerät verschlüsselt es"]
A4 --> A5
A5 --> A6["Schlüsselinhaber kann lesen"]
end
subgraph AFTER["Nachher: unterschriebenes Schlüssel"]
direction TB
B2{"Signatur gültig?"} -->|Ja| B3["Verifizierter Arbeiter-Schlüssel"]
B2 -->|Nein| B4["Ablehnen, erneut versuchen"]
B3 --> B5["Nur echter Arbeiter liest"]
end
A6 ~~~ B2Copy sourceDie Kryptografie ist solide und die Einführung ist unauthentifiziert#
Der Angreifer zerbricht nichts. X25519 und ML-KEM-768 funktionieren beide genau wie spezifiziert. Der Angreifer liefert einen Schlüssel und wird zu einer legitimen Partei des Vertrags.Dies ist eine unauthentifizierte Schlüsselvereinbarung, und ihr Versagen ist das älteste Ergebnis in diesem Bereich. Plain Diffie-Hellman authentifiziert niemanden und fällt zu einer Partei, die ihren eigenen öffentlichen Schlüssel ersetzt. Schlüssel-Kapselungsmechanismen übernehmen diese Eigenschaft, weshalb RFC 9180 die Authentizität des öffentlichen Schlüssels des Empfängers außerhalb seines eigenen Geltungsbereichs platziert und davon ausgeht, dass die umgebende Anwendung sie durch Zertifikate, ein Schlüsselverzeichnis oder eine Out-of-Band-Verifizierung herstellt. Dieses Modell ist die umgebende Anwendung, und der Kanal, den sie verwendet, um den Empfängerschlüssel zu verteilen, ist die Komponente, die ihr eigenes Vertrauensmodell als unzuverlässig einstuft.Die Offenlegung antizipiert einen Nachbarangriff und schließt ihn:Der Anspruch ist einmal schreiben/erster gewinnt, sodass ein späterer Arbeiter den Schlüsselaustausch eines Auftrags nicht übernehmen kann.— §6, ReferenzimplementierungDiese Überlegung ist solide und der Mechanismus tut, was er sagt. Es deckt einen der beiden symmetrischen Fälle ab.
| Bedrohung | Behandelt durch die einmalige Anspruchs‑Schreiboperation |
|---|---|
| Ein zweiter Arbeiter überschreibt einen bestehenden Anspruch | Ja — der Schreibvorgang wird abgelehnt |
| Eine unbefugte Partei schreibt den Anspruch zuerst | Nein — der erste Schreibvorgang gewinnt |
Kein Vermittler (Gateway, Koordination, Speicher, Monitor) hält jemals genügend Schlüsselmaterial, um irgendein Geheimnis abzuleiten. Ein Angreifer, der die Koordination oder den Speicher kompromittiert, erhält nur undurchsichtige Blobs und öffentliche Schlüssel.— §4.3, Unabhängige RichtungsschlüsselDer erste Satz ist korrekt. Der zweite beschreibt einen Angreifer, der liest. Ein Angreifer, der schreibt, platziert einen gewählten öffentlichen Schlüssel in das Anspruchs‑Datensatz, bevor das Gerät abfragt, und das Ableiten des legitimen Geheimnisses wird für eine Partei, die sich als Gegenpartei arrangieren kann, unnötig. Wer die Inhalte dieses Datensatzes regelt, regelt, wer die Nutzlast lesen kann, was die Koordinationsschicht zu einer vertrauenswürdigen Komponente für Vertraulichkeit macht – das Einzige, was §3 sagt, ist, dass keine Komponente außer dem Gerät und dem Arbeiter jemals sein sollte.Eine ehrliche Begrenzung des Anspruchs: Das bedeutet nicht, dass jeder im offenen Internet diese Daten heute lesen kann. In einer realen Bereitstellung befindet sich die Fähigkeit, Ansprüche zu schreiben, hinter Cloud‑Netzwerk und Anmeldeinformationen, und die Offenlegung beschreibt ein authentifizierendes Gateway auf dem Gerätepfad. Das genaue Problem ist, dass die Vertraulichkeit jetzt auf diesem Perimeter beruht, während das zentrale Versprechen der Architektur ist, dass sie ohne Vertrauen in die Komponenten zwischen dem Gerät und dem Arbeiter gehalten wird.