Consulenza: Un Risultato Critico nel Modello di Calcolo Non-Custodial PIE
Il modello rimuove la capacità dell'operatore di decifrare qualsiasi cosa una volta che un lavoro termina. Il dispositivo continua a cifrare con una chiave pubblica non verificata pubblicata dal componente che il modello designa come non affidabile.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
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:Il lato del dispositivo di quell'accordo è specificato con la stessa precisione:— §2.1, Flusso di dati (per lavoro)
- Lavoratore → coordinamento: poll e rivendica il lavoro (scrittura una volta, primo vince), pubblicando la chiave pubblica del lavoratore.
- Dispositivo ← coordinamento: poll, recupera la chiave pubblica del lavoratore, deriva il segreto condiviso, cripta il payload.
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 lavoratoreAl 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.
flowchart TB
subgraph BEFORE["Prima: come pubblicato"]
direction TB
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 TB
B2{"Firma valida?"} -->|Sì| B3["Chiave del lavoratore verificata"]
B2 -->|No| B4["Rifiuta, riprova"]
B3 --> B5["Solo il vero lavoratore legge"]
end
A6 ~~~ B2Copy sourceLa 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 riferimentoTale ragionamento è valido e il meccanismo fa ciò che dice. Copre uno dei due casi simmetrici.
| Minaccia | Gestita dall'affermazione write-once |
|---|---|
| Un secondo lavoratore sovrascrive un'affermazione esistente | Sì — la scrittura è rifiutata |
| Una parte non autorizzata scrive l'affermazione per prima | No — la prima scrittura vince |
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 direzioneLa 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.