Ho costruito sistemi per 25 anni, e adoro costruire cose che sono intenzionalmente progettate e operative, portando solo quanto un vettore meriti.
In quell'approccio, minimizzare ciò che memorizzo dei dati di un utente ha sempre avuto senso per me, per motivi che vanno oltre quello ovvio. La sovranità dei loro dati conta. Sotto di essa c'è qualcosa di più semplice: le cose appartengono dove dovrebbero appartenere. La maggior parte di ciò che costruisco è elaborazione, e un'architettura di elaborazione non ha senso operare come qualcos'altro. Tenere un record che non serviva è un vettore che non guadagna nulla. Trattarlo come un'ottimizzazione, piuttosto che come un esercizio di conformità, è ciò che mantiene il design onesto — e un sistema costruito così tende a rimanere in buona posizione con la regolamentazione da solo, perché rimane molto poco da regolare.
Quindi quando l'annuncio di Mary Camacho è apparso nel mio feed su X, ho letto la sua architettura come faccio la mia. Aveva pubblicato il suo nucleo nel registro pubblico sotto una licenza Creative Commons, al livello di dettaglio che un ingegnere avrebbe bisogno per ricostruirlo, e era diretto sul precedente lavoro su cui si basa.
Analizzando la sequenza, ho inserito un'entità avversaria nel server e ho seguito ciò che poteva raggiungere. Era in grado di superare il lavoratore.
Quasi tutto il lavoro che seguì si svolse come una conversazione vocale — su 30 note vocali, pensando ad alta voce e testando la preoccupazione da diverse angolazioni finché non si mantenne o si disintegrò.

Ciò che ho notato: il dispositivo si cripta per chi scrive il record di rivendicazione per primo

La divulgazione specifica l'ordine delle operazioni direttamente. Il lavoratore rivendica il lavoro e pubblica la sua chiave, e solo allora il dispositivo si cripta:
  1. Lavoratore → coordinamento: poll e rivendica il lavoro (scrittura una volta, primo vince), pubblicando la chiave pubblica del lavoratore.
  2. Dispositivo ← coordinamento: poll, recupera la chiave pubblica del lavoratore, deriva il segreto condiviso, cripta il payload.
— §2.1, Flusso di dati (per lavoro)
Il lato del dispositivo di quell'accordo è specificato con la stessa precisione:
Il dispositivo, al momento di apprendere la chiave pubblica del lavoratore, esegue il proprio scambio X25519 e un'encapsulazione ML-KEM contro la chiave del lavoratore, producendo il proprio contributo pubblico (chiave pubblica X25519 ‖ ciphertext ML-KEM) e il segreto condiviso.
— §4.2, Vincolo al ciclo di vita del lavoratore
Al momento dell'apprendimento. Attraverso 19 pagine non c'è una firma sulla chiave pubblica effimera del lavoratore, nessun certificato, nessuna attestazione che il dispositivo valuta, e nessun segreto pre-condiviso. L'assenza è deliberata e presentata come una forza: il modello blocca la decrittazione senza alcun documento di attestazione, citazione TPM, o artefatto di boot misurato, e non conserva alcun segreto pre-provisionato del lavoratore.
Quindi il dispositivo cripta il suo payload con qualsiasi chiave pubblica sia presente nel record di rivendicazione, senza mezzi per distinguere la chiave di un lavoratore legittimo da quella di chiunque altro. Chiunque sia in grado di scrivere una rivendicazione per primo diventa la parte a cui il dispositivo cripta, e il payload confidenziale si decripta nelle loro mani.
Diagram source
flowchart TB
    subgraph BEFORE["Prima: come pubblicato"]
        direction LR
        A2{"Chi reclama per primo?"} -->|Lavoratore reale| A3["Chiave genuina"]
        A2 -->|Qualsiasi altro scrittore| A4["Chiave dell’attaccante"]
        A3 --> A5["Il dispositivo la cripta"]
        A4 --> A5
        A5 --> A6["Il possessore della chiave può leggere"]
    end
    subgraph AFTER["Dopo: chiave firmata"]
        direction LR
        B2{"Firma valida?"} -->|Sì| B3["Chiave del lavoratore verificata"]
        B2 -->|No| B4["Rifiuta, riprova"]
        B3 --> B5["Solo il vero lavoratore legge"]
    end
    A6 ~~~ B2
La gravità deriva da ciò che il modello porta. Questa architettura esiste per contenere esattamente i dati che le persone sono meno propense a far leggere, e riesce nella parte più difficile di quel problema: un lavoro completato non può essere decifrato da nessuno, compreso l’operatore. Il divario si trova nel singolo passo in cui il dispositivo deve stabilire con chi sta parlando.

La crittografia è sicura e l'introduzione è non autenticata

L'attaccante non rompe nulla. X25519 e ML-KEM-768 funzionano esattamente come specificato. L'attaccante fornisce una chiave e diventa una parte legittima dell'accordo.
Questo è un accordo di chiave non autenticato, e il suo modo di fallimento è il risultato più antico nel campo. Diffie-Hellman semplice non autentica nessuno e cade in una parte che sostituisce la propria chiave pubblica. I meccanismi di incapsulamento di chiave ereditano la proprietà, motivo per cui RFC 9180 colloca l'autenticità della chiave pubblica del destinatario al di fuori del proprio ambito e presume che l'applicazione circostante la stabilisca tramite certificati, un directory di chiavi o verifica out-of-band. Questo modello è l'applicazione circostante, e il canale che utilizza per distribuire la chiave del destinatario è il componente che il proprio modello di fiducia etichetta come non affidabile.
La divulgazione prevede un attacco adiacente e lo chiude:
L'affermazione è write-once/first-wins quindi un lavoratore successivo non può rapire lo scambio di chiavi di un lavoro.
— §6, Implementazione di riferimento
Tale ragionamento è valido e il meccanismo fa ciò che dice. Copre uno dei due casi simmetrici.
MinacciaGestita dall'affermazione write-once
Un secondo lavoratore sovrascrive un'affermazione esistenteSì — la scrittura è rifiutata
Una parte non autorizzata scrive l'affermazione per primaNo — la prima scrittura vince
First-wins è una corsa. La regola garantisce che il vincitore mantenga il lavoro e non dice nulla su chi sia il vincitore.
Un'altra affermazione vale la pena citare, perché il risultato la contraddice:
Nessun intermediario (gateway, coordinazione, archiviazione, monitor) detiene mai abbastanza materiale chiave da derivare uno dei due segreti. Un attaccante che compromette la coordinazione o l'archiviazione ottiene solo blob opachi e chiavi pubbliche.
— §4.3, chiavi indipendenti per direzione
La prima frase è accurata. La seconda descrive un attaccante che legge. Un attaccante che scrive inserisce una chiave pubblica scelta nel record di rivendicazione prima che il dispositivo faccia polling, e derivare il segreto legittimo diventa inutile per una parte che può organizzarsi per essere la controparte. Chi governa i contenuti di quel record governa chi può leggere il payload, il che rende il livello di coordinamento un componente affidabile per la confidenzialità — la cosa che §3 dice che nessun componente oltre al dispositivo e al worker dovrebbe mai essere.
Un limite onesto sulla rivendicazione: questo non significa che chiunque su internet aperto possa leggere questi dati oggi. In un deployment reale la capacità di scrivere rivendicazioni è dietro networking cloud e credenziali, e la divulgazione descrive un gateway di autenticazione sul percorso del dispositivo. Il problema preciso è che la confidenzialità ora dipende da quel perimetro, mentre la promessa centrale dell'architettura è che essa si mantenga senza fidarsi dei componenti tra il dispositivo e il worker.

Due proprietà di progettazione compongono la conseguenza

I risultati tornano al dispositivo sotto un secondo accordo che lo stesso avversario media, quindi un lavoro intercettato si completa e appare ordinario dal punto di vista dell'utente.
L'assenza deliberata di un lavoro durevole e di un registro dei risultati — la stessa assenza che crea non custodia e riduce la superficie regolamentare — rimuove la maggior parte di ciò che un investigatore userebbe in seguito per ricostruire quali lavori sono stati colpiti. I registri di coordinamento scadono in circa un'ora. La proprietà che protegge i dati nel caso ordinario affina il record forense in quello avversario.

Il divario è l'ombra proiettata dalla migliore decisione del modello

L'architettura separa i dati che un operatore può legittimamente detenere da quelli che non deve mai detenere. I dati di contatto sono chi è una persona e come raggiungerla. I dati confidenziali sono ciò che divulgano su se stessi. I sistemi convenzionali archiviano entrambi in un unico database, che è il passo che trasforma una tabella account in un record della vita privata di qualcuno. La risposta strutturale è una singola riga: conservare il contatto, non poter conservare il confidenziale.
Rimuovere l'orchestratore centrale serve direttamente a questo. Un componente che assegna lavori ai lavoratori necessariamente impara chi fa cosa, e quella conoscenza è l'asset preciso che il modello rifiuta di detenere. Rimuoverlo ha anche rimosso il componente che normalmente garantirebbe l'identità di un lavoratore, e ogni percorso rimanente per autenticare il lavoratore è stato rifiutato indipendentemente, ognuno per una ragione difendibile.
Il risultato è un design che ragiona sulla custodia con reale rigore e applica il ragionamento sulla custodia al punto unico dove la forma del problema è autenticazione. Il modello di fiducia chiede cosa ogni componente conserva e risponde correttamente. La domanda necessaria lì è cosa ogni componente può sostituire. Questi sono due problemi di fiducia indipendenti, e risolvere uno non ha mai risolto l'altro.

Una firma sul chiave pubblica effimera del lavoratore la chiude

Il lavoratore genera la sua coppia di chiavi effimere all’avvio esattamente come fa ora. Prima che tale chiave sia pubblicata in un reclamo, è firmata da una chiave operatore a lungo termine la cui metà pubblica viene fornita con l’applicazione. Il dispositivo verifica la firma prima di derivare qualsiasi cosa e rifiuta una chiave non firmata o non valida. Il recupero è già specificato, poiché il tentativo guidato dal client con un nuovo lavoro e un nuovo accordo di chiavi è la via di fallimento standard del modello.
La proprietà decisiva è che una chiave di firma non decripta nulla. La compromissione della chiave di firma dell’operatore permette l’impersonificazione di un lavoratore in futuro e non consente di leggere un singolo lavoro completato, perché quelle chiavi per lavoro sono state distrutte con i loro lavoratori. Non custodia, il vault di chiavi vuoto e l’impossibilità di decriptare retroattivamente sopravvivono intatti. Questo è ciò che rende questo un completamento del design.
Il firmatario rimane libero di non diventare l’orchestratore che il design ha rimosso. Serve solo attestare che una determinata chiave pubblica effimera appartiene a un lavoratore lanciato dall’operatore, e non ha mai bisogno di sapere quale lavoro quel lavoratore affronterà. Il monitor esistente è la casa naturale: già fornisce e raccoglie lavoratori, non detiene dati utente né chiavi, e per progettazione non instrada né assegna lavori.
Il replay merita un controllo, poiché un firmatario senza conoscenza del lavoro non può associare una firma a un identificatore di lavoro. Un attaccante che copia una chiave di lavoratore firmata genuina in un record di reclamo diverso manca comunque della chiave privata corrispondente, quindi il payload rimane illeggibile. Il risultato è un lavoro che nessuno può elaborare — negazione del servizio, con confidenzialità intatta.
Rimangono tre limiti, e la divulgazione ne nomina tutti e tre: il testo in chiaro esiste nella memoria del lavoratore mentre il lavoro è in esecuzione, il timing del lavoro rivela metadati, e la costruzione di derivazione delle chiavi è segnalata per miglioramento dall’autore.

Consulenza

Questo risultato esiste perché l'architettura è stata collocata nei commons. La pubblicazione è ciò che ha reso possibile la valutazione indipendente, ed è per questo che il divario è emerso qui piuttosto che in un rapporto di incidente. Una versione proprietaria di questo sistema avrebbe lo stesso problema senza nessuno in grado di affermarlo.
Apprezzo il contributo, e il modello merita la scrutinio che ha invitato. L'affermazione centrale è valida, e è la forma che voglio che più sistemi adottino, perché un'architettura che non conserva dati confidenziali ha una frazione della superficie regolatoria di una che lo fa.
La raccomandazione è stretta: autenticare la chiave pubblica effimera del lavoratore prima che il dispositivo la cifri. Una firma, verificata sul dispositivo, a costo di nulla che rende il modello degno di essere adottato. Tutto quanto sopra è emerso da una conversazione voce-trascrizione in più di 30 note, verificata contro la divulgazione pubblicata piuttosto che contro un suo riepilogo. Se questi risultati sono validati dal loro lato, sono semplici da attuare.