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:
  1. Arbeiter → Koordination: Abfrage und Anspruch des Auftrags (einmal schreiben, erster gewinnt), Veröffentlichung des öffentlichen Schlüssels des Arbeiters.
  2. Gerät ← Koordination: Abfrage, Abruf des öffentlichen Schlüssels des Arbeiters, Ableitung des gemeinsamen Geheimnisses, Verschlüsselung der Nutzlast.
— §2.1, Datenfluss (pro Auftrag)
Die Seite des Geräts in dieser Vereinbarung wird mit gleicher Präzision festgelegt:
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 Arbeiters
Beim 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.
Diagram source
flowchart TB
    subgraph BEFORE["Vorher: wie veröffentlicht"]
        direction LR
        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 LR
        B2{"Signatur gültig?"} -->|Ja| B3["Verifizierter Arbeiter-Schlüssel"]
        B2 -->|Nein| B4["Ablehnen, erneut versuchen"]
        B3 --> B5["Nur echter Arbeiter liest"]
    end
    A6 ~~~ B2
Die Schwere ergibt sich daraus, was das Modell trägt. Diese Architektur existiert, um genau die Daten zu halten, die die Menschen am wenigsten bereit sind lesen zu lassen, und sie gelingt im schwierigeren Teil dieses Problems: ein abgeschlossenes Job kann von niemandem, einschließlich des Betreibers, entschlüsselt werden. Die Lücke liegt in dem einen Schritt, in dem das Gerät festlegen muss, mit wem es spricht.

Die 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, Referenzimplementierung
Diese Überlegung ist solide und der Mechanismus tut, was er sagt. Es deckt einen der beiden symmetrischen Fälle ab.
BedrohungBehandelt durch die einmalige Anspruchs‑Schreiboperation
Ein zweiter Arbeiter überschreibt einen bestehenden AnspruchJa — der Schreibvorgang wird abgelehnt
Eine unbefugte Partei schreibt den Anspruch zuerstNein — der erste Schreibvorgang gewinnt
First-wins ist ein Rennen. Die Regel garantiert, dass der Gewinner den Auftrag behält und sagt nichts darüber, wer der Gewinner ist.
Eine weitere Behauptung ist es wert, zitiert zu werden, weil die Erkenntnis sie widerspricht:
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 Richtungs­schlüssel
Der 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.

Zwei Design-Eigenschaften verstärken die Konsequenz

Ergebnisse kehren zum Gerät unter einem zweiten Vertrag zurück, den derselbe Gegner vermittelt, sodass ein abgefangener Auftrag abgeschlossen wird und von der Seite des Benutzers gewöhnlich aussieht.
Die bewusste Abwesenheit eines dauerhaften Auftrags und Ergebnis-Ledgers — die gleiche Abwesenheit, die Nicht-Vermögensverwaltung schafft und die regulatorische Oberfläche verkleinert — entfernt den Großteil dessen, was ein Ermittler später verwenden würde, um zu rekonstruieren, welche Aufträge betroffen waren. Koordinationsaufzeichnungen verfallen in der Reihenfolge einer Stunde. Die Eigenschaft, die die Daten im gewöhnlichen Fall schützt, verdünnt das forensische Protokoll im gegnerischen Fall.

Die Lücke ist der Schatten, den die beste Entscheidung des Modells wirft

Die Architektur trennt Daten, die ein Betreiber legitimerweise halten darf, von Daten, die er niemals halten darf. Kontaktdaten sind, wer eine Person ist und wie man sie erreicht. Vertrauliche Daten sind, was sie über sich selbst preisgeben. Konventionelle Systeme speichern beides in einer Datenbank, was die Umwandlung einer Kontotabelle in ein Aufzeichnung des privaten Lebens einer Person bedeutet. Die strukturelle Antwort ist eine einzige Zeile: halte den Kontakt, sei nicht in der Lage, den Vertraulichen zu halten.
Das Entfernen des zentralen Orchestrators dient diesem Zweck direkt. Eine Komponente, die Aufträge an Arbeiter zuweist, lernt zwangsläufig, wer was tut, und dieses Wissen ist das präzise Asset, das das Modell nicht halten will. Seine Entfernung hat auch die Komponente entfernt, die normalerweise die Identität eines Arbeiters bezeugen würde, und jeder verbleibende Weg zur Authentifizierung des Arbeiters wurde unabhängig abgelehnt, jeder aus einem verteidigungsfähigen Grund.
Das Ergebnis ist ein Design, das über Custody mit echter Strenge nachdenkt und Custody‑Logik an der einzigen Stelle anwendet, an der die Form des Problems Authentifizierung ist. Das Vertrauensmodell fragt, was jede Komponente hält, und beantwortet korrekt. Die dort benötigte Frage ist, was jede Komponente ersetzen kann. Dies sind zwei unabhängige Vertrauensprobleme, und die Lösung eines hat das andere nie gelöst.

Eine Signatur über den temporären öffentlichen Schlüssel des Arbeiters schließt ihn ab

Der Arbeiter erzeugt sein temporäres Schlüsselpaar beim Start genau wie jetzt. Bevor dieser Schlüssel in einen Anspruch veröffentlicht wird, wird er von einem langfristigen Betreiber-Schlüssel signiert, dessen öffentlicher Teil mit der Anwendung ausgeliefert wird. Das Gerät überprüft die Signatur, bevor es etwas ableitet, und verweigert einen nicht signierten oder ungültigen Schlüssel. Die Wiederherstellung ist bereits festgelegt, da ein clientgesteuerter Retry mit einem frischen Job und einer frischen Schlüsselvereinbarung der Standardfehlerpfad des Modells ist.
Die entscheidende Eigenschaft ist, dass ein Signaturschlüssel nichts entschlüsselt. Die Kompromittierung des Signaturschlüssels des Betreibers ermöglicht die Vortäuschung eines Arbeiters in der Zukunft und gewährt keine Möglichkeit, einen einzelnen abgeschlossenen Job zu lesen, weil diese pro-Job-Schlüssel mit ihren Arbeitern zerstört wurden. Nicht‑Verwahrung, das leere Schlüsseltresor und die Unmöglichkeit einer retrospektiven Entschlüsselung bleiben intakt. Das ist, was diese Vollendung des Designs ausmacht.
Der Signierer bleibt fern von der Rolle des Orchestrators, die das Design entfernt hat. Er muss nur bestätigen, dass ein bestimmter temporärer öffentlicher Schlüssel zu einem vom Betreiber gestarteten Arbeiter gehört, und er muss nie wissen, welchen Job dieser Arbeiter beanspruchen wird. Der bestehende Monitor ist das natürliche Zuhause: er stellt bereits Arbeiter bereit und sammelt sie wieder, hält keine Benutzerdaten und keine Schlüssel, und entwirft nach Design keine Weiterleitung oder Zuweisung von Jobs.
Replay verdient eine Prüfung, da ein Signierer ohne Jobwissen keine Signatur an einen Job‑Identifier binden kann. Ein Angreifer, der einen echten signierten Arbeiter‑Schlüssel in einen anderen Anspruchsdatensatz kopiert, hat immer noch nicht den entsprechenden privaten Schlüssel, sodass die Nutzlast unlesbar bleibt. Das Ergebnis ist ein Job, den niemand verarbeiten kann – Dienstverweigerung, mit intakter Vertraulichkeit.
Drei Grenzen bleiben, und die Offenlegung nennt alle drei: Klartext existiert im Speicher des Arbeiters, während der Job läuft, Job‑Timing leckt Metadaten, und die Schlüssel‑Ableitungs‑Konstruktion ist vom Autor zur Verbesserung gekennzeichnet.

Beratung

Diese Feststellung existiert, weil die Architektur in die Commons gesetzt wurde. Die Veröffentlichung hat die unabhängige Bewertung möglich gemacht, und deshalb ist die Lücke hier aufgetaucht und nicht in einem Vorfallsbericht. Eine proprietäre Version dieses Systems würde dasselbe Problem haben, ohne dass jemand zuständig ist, um es zu sagen.
Ich schätze den Beitrag, und das Modell verdient die Prüfung, die es eingeladen hat. Die zentrale Behauptung bleibt, und es ist die Form, die ich möchte, dass mehr Systeme annehmen, weil eine Architektur, die niemals vertrauliche Daten hält, einen Bruchteil der regulatorischen Oberfläche einer hat, die es tut.
Die Empfehlung ist eng: authentifiziere den temporären öffentlichen Schlüssel des Arbeitnehmers, bevor das Gerät ihn verschlüsselt. Eine Signatur, die auf dem Gerät verifiziert wird, zu einem Kostenaufwand von nichts, das das Modell wertvoll macht. Alles oben entstand aus einer Sprach-zu-Text-Konversation über mehr als 30 Notizen, geprüft gegen die veröffentlichte Offenlegung statt gegen eine Zusammenfassung davon. Wenn diese Erkenntnisse auf ihrer Seite validiert werden, sind sie leicht umsetzbar.