Je construis des systèmes depuis 25 ans, et j'adore construire des choses intentionnellement conçues et opérationnellement légères, ne portant que la quantité de vecteur qui mérite son poids.
Dans cette approche, minimiser ce que je conserve des données d'un utilisateur a toujours eu du sens pour moi, pour des raisons qui vont au-delà de l'obvious. La souveraineté de leurs données compte. En dessous se trouve quelque chose de plus simple : les choses appartiennent là où elles doivent être. La plupart de ce que je construis est du traitement, et une architecture de traitement n'a aucun business à fonctionner comme autre chose. Conserver un enregistrement dont on n'a jamais besoin est un vecteur qui ne rapporte rien. Traiter cela comme une optimisation, plutôt que comme un exercice de conformité, est ce qui maintient le design honnête — et un système construit ainsi a tendance à rester en règle avec la réglementation de lui-même, car il ne reste presque rien à réguler.
Alors que Mary l'annonce de Camacho traversait mon fil d'actualité sur X, je lisais son architecture comme je lis ma propre. Elle avait publié le cœur de celle-ci dans le registre public sous une licence Creative Commons, au niveau de détail qu'un ingénieur aurait besoin pour la reconstruire, et elle était directe sur l'art antérieur sur lequel elle se base.
En travaillant à travers la séquence, j'ai placé une entité adversaire dans le serveur et suivi ce qu'elle pouvait atteindre. Elle pouvait dépasser le travailleur.
Presque tout le travail qui a suivi s'est déroulé comme une conversation vocale — sur 30 notes vocales, en pensant à haute voix et en testant la préoccupation sous différents angles jusqu'à ce qu'elle tient ou s'effondre.

Ce que j’ai remarqué : l’appareil chiffre pour celui qui écrit d’abord l’enregistrement de réclamation

La divulgation précise l’ordre des opérations directement. Le travailleur revendique le travail et publie sa clé, et ce n’est qu’alors que l’appareil chiffre :
  1. Travailleur → coordination : poll et revendique le travail (write-once, first-wins), publiant la clé publique du travailleur.
  2. Appareil ← coordination : poll, récupérer la clé publique du travailleur, dériver le secret partagé, chiffrer la charge utile.
— §2.1, Flux de données (par travail)
Le côté de l’appareil de cet accord est spécifié avec la même précision :
L’appareil, en apprenant la clé publique du travailleur, effectue son propre échange X25519 et une encapsulation ML-KEM contre la clé du travailleur, produisant sa propre contribution publique (clé publique X25519 ‖ texte chiffré ML-KEM) et le secret partagé.
— §4.2, Liaison au cycle de vie du travailleur
En apprenant. À travers 19 pages il n’y a pas de signature sur la clé publique éphémère du travailleur, pas de certificat, pas d’attestation que l’appareil évalue, et pas de secret pré-partagé. L’absence est délibérée et présentée comme une force : le modèle bloque le décryptage sans document d’attestation, citation TPM, ou artefact de démarrage mesuré, et il ne conserve aucun secret pré-provisionné du travailleur.
Ainsi l’appareil chiffre sa charge utile vers la clé publique qui se trouve dans l’enregistrement de réclamation, sans moyen de distinguer la clé d’un travailleur légitime de celle de n’importe qui d’autre. Toute partie capable d’écrire une réclamation en premier devient la partie vers laquelle l’appareil chiffre, et la charge utile confiée se déchiffre dans leurs mains.
Diagram source
flowchart TB
    subgraph BEFORE["Avant : tel que publié"]
        direction LR
        A2{« Qui revendique en premier ? »} -->|Travailleur réel| A3["Clé authentique"]
        A2 -->|Tout autre écrivain| A4["Clé attaquante"]
        A3 --> A5["L’appareil la chiffre"]
        A4 --> A5
        A5 --> A6["Le détenteur de la clé peut lire"]
    end
    subgraph AFTER["Après : clé signée"]
        direction LR
        B2{« Signature valide ? »} -->|Oui| B3["Clé de travail vérifiée"]
        B2 -->|Non| B4["Refuser, réessayer"]
        B3 --> B5["Seul le vrai travailleur lit"]
    end
    A6 ~~~ B2
La gravité vient de ce que le modèle porte. Cette architecture existe pour contenir exactement les données que les gens sont le moins disposés à faire lire, et elle réussit à la partie la plus difficile de ce problème : un travail terminé ne peut être décrypté par personne, y compris l’opérateur. L’écart se situe à l’étape où l’appareil doit établir à qui il parle.

La cryptographie est solide et l'introduction est non authentifiée

L'attaquant ne casse rien. X25519 et ML-KEM-768 fonctionnent tous deux exactement comme spécifié. L'attaquant fournit une clé et devient une partie légitime de l'accord.
Il s'agit d'un accord de clé non authentifié, et son mode d'échec est le résultat le plus ancien dans le domaine. Diffie-Hellman simple n'authentifie personne et tombe à une partie qui substitue sa propre clé publique. Les mécanismes d'encapsulation de clé héritent de cette propriété, c'est pourquoi RFC 9180 place l'authenticité de la clé publique du destinataire hors de son propre périmètre et suppose que l'application environnante l'établit via des certificats, un répertoire de clés ou une vérification hors bande. Ce modèle est cette application environnante, et le canal qu'elle utilise pour distribuer la clé du destinataire est le composant que son propre modèle de confiance qualifie non fiable.
La divulgation anticipe une attaque voisine et la ferme :
La réclamation est écriture unique/premier gagne, donc un travailleur ultérieur ne peut pas détourner l'échange de clé d'un travail.
— §6, Implémentation de référence
Ce raisonnement est solide et le mécanisme fait ce qu'il dit. Il couvre l'un des deux cas symétriques.
MenaceGéré par la revendication « write-once »
Un second travailleur écrase une revendication existanteOui — l'écriture est rejetée
Une partie non autorisée écrit la revendication en premierNon — la première écriture gagne
First-wins est une course. La règle garantit que le gagnant conserve le travail et ne dit rien sur l'identité du gagnant.
Une autre affirmation vaut la peine d'être citée, car la constatation la contredit :
Aucun intermédiaire (gateway, coordination, stockage, monitor) ne détient jamais suffisamment de matériel clé pour dériver l'un ou l'autre secret. Un attaquant qui compromet la coordination ou le stockage obtient uniquement des blobs opaques et des clés publiques.
— §4.3, clés indépendantes par direction
La première phrase est précise. La seconde décrit un attaquant qui lit. Un attaquant qui écrit place une clé publique choisie dans l'enregistrement de la revendication avant que l'appareil ne poll, et dériver le secret légitime devient inutile pour une partie qui peut s'organiser pour être la contrepartie. Quiconque gouverne le contenu de cet enregistrement gouverne qui peut lire la charge utile, ce qui fait de la couche de coordination un composant de confiance pour la confidentialité — la seule chose que §3 dit qu'aucun composant autre que l'appareil et le travailleur ne devrait jamais être.
Une borne honnête sur la revendication : cela ne signifie pas que quiconque sur Internet ouvert peut lire ces données aujourd'hui. Dans un déploiement réel, la capacité d'écrire des revendications se trouve derrière le réseau cloud et les identifiants, et la divulgation décrit une passerelle d'authentification sur le chemin de l'appareil. Le problème précis est que la confidentialité repose désormais sur ce périmètre, alors que la promesse centrale de l'architecture est qu'elle tient sans faire confiance aux composants entre l'appareil et le travailleur.

Deux propriétés de conception amplifient la conséquence

Les résultats reviennent vers l’appareil sous un second accord que le même adversaire médie, de sorte qu’un travail intercepté se termine et semble ordinaire du point de vue de l’utilisateur.
L’absence délibérée d’un travail durable et d’un registre de résultats — la même absence qui crée une non‑custodie et réduit la surface réglementaire — élimine la plupart de ce qu’un enquêteur utiliserait plus tard pour reconstituer quels travaux ont été affectés. Les registres de coordination expirent en l’ordre d’une heure. La propriété qui protège les données dans le cas ordinaire affaiblit l’enregistrement judiciaire dans le cas adversarial.

L’écart est l’ombre projetée par la meilleure décision du modèle

L’architecture sépare les données qu’un opérateur peut légitimement détenir des données qu’il ne doit jamais détenir. Les données de contact sont qui est une personne et comment la joindre. Les données confiées sont ce qu’ils divulguent à propos d’eux-mêmes. Les systèmes conventionnels les enregistrent tous les deux dans une seule base de données, ce qui transforme une table de comptes en un registre de la vie privée de quelqu’un. La réponse structurelle est une seule ligne : conserver le contact, ne pas pouvoir conserver le confiant.
Retirer l’orchestrateur central sert directement cette fonction. Un composant qui attribue des travaux aux travailleurs apprend nécessairement qui fait quoi, et cette connaissance est l’actif précis que le modèle refuse de détenir. Le retirer a également supprimé le composant qui garantirait normalement l’identité d’un travailleur, et chaque route restante pour authentifier le travailleur a été rejetée indépendamment, chacune pour une raison défendable.
Le résultat est une conception qui raisonne sur la custodie avec un réel rigueur et applique le raisonnement de custodie au seul point où la forme du problème est l’authentification. Le modèle de confiance demande ce que chaque composant dépose et répond correctement. La question nécessaire là est ce que chaque composant peut substituer. Ce sont deux problèmes de confiance indépendants, et résoudre l’un n’a jamais résolu l’autre.

Une signature sur la clé publique éphémère du travailleur la ferme

Le travailleur génère sa paire de clés éphémère au démarrage exactement comme il le fait maintenant. Avant que cette clé ne soit publiée dans une revendication, elle est signée par une clé d'opérateur à long terme dont la partie publique est livrée avec l'application. L'appareil vérifie la signature avant de dériver quoi que ce soit et refuse une clé non signée ou invalide. La récupération est déjà spécifiée, puisque la reprise dirigée par le client avec un nouveau travail et un nouvel accord de clé est le chemin d'échec standard du modèle.
La propriété décisive est que une clé de signature ne déchiffre rien. La compromission de la clé de signature de l'opérateur permet l'usurpation d'un travailleur à l'avenir et n'accorde aucune capacité à lire un seul travail terminé, car ces clés par travail ont été détruites avec leurs travailleurs. Non‑custodie, le coffre à clés vide et l'impossibilité de déchiffrement rétrospectif restent intacts. C'est ce qui rend cette réalisation complète du design.
Le signataire reste à l'écart de devenir l'orchestrateur que le design a supprimé. Il suffit de certifier qu'une clé publique éphémère donnée appartient à un travailleur lancé par l'opérateur, et il n'a jamais besoin de savoir quel travail ce travailleur réclamera. Le moniteur existant est le foyer naturel : il provisionne déjà et récupère les travailleurs, ne détient aucune donnée utilisateur ni aucune clé, et par conception ne routage ni n'affecte pas de travaux.
La rejouabilité mérite une vérification, puisque un signataire sans connaissance du travail ne peut pas lier une signature à un identifiant de travail. Un attaquant qui copie une clé de travailleur signée authentique dans un enregistrement de revendication différent manque toujours la clé privée correspondante, donc la charge utile reste illisible. Le résultat est un travail que personne ne peut traiter — déni de service, avec la confidentialité intacte.
Trois limites restent, et la divulgation nomme les trois : le texte clair existe dans la mémoire du travailleur pendant l'exécution du travail, le timing du travail fuit des métadonnées, et la construction de dérivation de clé est signalée pour amélioration par l'auteur.

Conseils

Cette constatation existe parce que l’architecture a été placée dans les communs. La publication est ce qui a rendu l’évaluation indépendante possible, et c’est pourquoi le fossé est apparu ici plutôt que dans un rapport d’incident. Une version propriétaire de ce système porterait le même problème sans qu’aucune personne ne soit positionnée pour le dire.
J’apprécie la contribution, et le modèle mérite l’examen qu’il a suscité. La revendication centrale tient, et c’est la forme que je souhaite que plus de systèmes adoptent, car une architecture qui ne conserve jamais de données confiées porte une fraction de la surface réglementaire d’une qui le fait.
La recommandation est précise : authentifier la clé publique éphémère du travailleur avant que l’appareil ne chiffre vers elle. Une signature, vérifiée sur l’appareil, à un coût nul qui rend le modèle digne d’adoption. Tout ce qui précède est issu d’une conversation voix‑vers‑texte à travers plus de 30 notes, vérifiée contre la divulgation publiée plutôt que contre un résumé de celle‑ci. Si ces constatations sont validées de leur côté, elles sont simples à mettre en œuvre.