La couche de confidentialité de Newton fait une affirmation de sécurité précise : lorsque des données privées sont chiffrées et téléversées, le texte chiffré est cryptographiquement lié à une politique spécifique et à une chaîne spécifique.
Essayez de rejouer cette même enveloppe chiffrée ailleurs — une politique différente, une chaîne différente — et le contrôle d’authentification échoue carrément.
Le déchiffrement est refusé. Je voulais voir exactement ce que « lié à » couvre, et, tout aussi important, ce que cela ne couvre pas.
Voici la formule exacte.
Les données d’authentification supplémentaires ajoutées au chiffrement sont calculées à partir de exactement deux entrées : le client de la politique et l’identifiant de chaîne, hachés ensemble.
Ce hachage devient une partie de ce que l’algorithme de chiffrement authentifie, en plus du texte chiffré lui-même.
Si l’une ou l’autre entrée change — une politique différente, une chaîne différente — toute la balise d’authentification se brise, et l’algorithme refuse de déchiffrer.
C’est une garantie forte, bien cadrée, et c’est exactement le type de protection que vous voudriez contre quelqu’un qui essaierait de récupérer une charge chiffrée valide et de la réutiliser dans un contexte pour lequel elle n’était pas destinée.
Mais l’appel de téléversement qui transporte ce texte chiffré ne transporte pas uniquement le texte chiffré et ces deux valeurs liées.
Il emporte aussi une durée de vie (time-to-live) — une valeur qui détermine combien de temps cet élément de données est censé rester valide ou récupérable avant d’expirer.
Et quand j’ai vérifié ce qui est réellement inclus dans la formule des données authentifiées, le TTL n’y figure pas.
La formule couvre exactement deux éléments : client de politique, identifiant de chaîne. Rien d’autre.
C’est une vraie distinction, pas une simple formalité. Un champ authentifié est celui dans lequel toute altération détruit la preuve cryptographique et est détectée automatiquement.
Un champ non authentifié est un champ que le système se contente de considérer comme fiable tel qu’il est indiqué, parce que rien dans le chiffrement lui-même ne le surveille.
Le client de politique et l’identifiant de chaîne se trouvent dans la première catégorie.
Le TTL, d’après ce qui est documenté, se situe dans la seconde catégorie.
Cela soulève une question précise, testable : si quelqu’un ayant la capacité d’intercepter ou de renvoyer cette requête de téléversement modifiait uniquement le TTL — en laissant totalement inchiffrés le texte chiffré (ciphertext), le client de politique et l’identifiant de chaîne — est-ce que la vérification d’authentification le remarquerait même ?
D’après la formule telle qu’elle est écrite, ce n’est pas le cas.
Le texte chiffré serait toujours déchiffré correctement, parce que rien dans la manipulation du TTL ne touche les deux valeurs que l’algorithme vérifie réellement.
Les données resteraient exactement ce que l’expéditeur d’origine a chiffré. Seule leur durée de conservation aurait discrètement changé.
Cela compte plus que ce qu’on pourrait penser au premier abord, car le TTL n’est pas une simple métadonnée esthétique — c’est un contrôle de sécurité à part entière.
C’est probablement ce qui limite la durée pendant laquelle un morceau de données chiffrées sensibles reste une chose sur laquelle le système agira encore, qu’il récupérera encore, qu’il traitera encore comme actuelle.
Un TTL abrégé pourrait faire expirer trop tôt des données légitimes et provoquer l’échec silencieux de flux de travail qui en dépendent.
Un TTL prolongé pourrait conserver des données sensibles en vie et récupérables bien au-delà du moment où la partie d’origine avait l’intention qu’elles importent.
Aucun des deux ne nécessite de casser le chiffrement.
Aucune des deux n’active le contrôle d’intégrité unique que le système est documenté pour effectuer.
Je veux être précis sur ce que je ne prétends pas.
Je ne sais pas si cet écart est réellement exploitable de bout en bout — cela dépend de choses que la documentation ne couvre pas, comme la question de savoir si la Gateway s’engage indépendamment sur le TTL on-chain au moment du téléversement, d’une manière qui ne puisse plus être modifiée ensuite, si la requête de téléversement elle-même transite sur un canal avec une protection d’intégrité au niveau transport qui détecterait toute altération avant d’atteindre cette couche, ou bien si le TTL est traité comme un conseil (advisory) plutôt que comme un élément critique pour la sécurité.
Chacun de ceux-ci pourrait refermer complètement l’écart, et aucun n’apparaîtrait dans la formule AAD elle-même, parce qu’il s’agirait de protections superposées par-dessus, plutôt que de protections intégrées dedans.
Donc, la question ouverte est la suivante, et elle est exacte : la valeur du TTL est-elle engagée quelque part de manière immuable et vérifiable au moment du téléversement — sur la blockchain, ou à l’intérieur d’une autre structure authentifiée — ou bien est-elle acceptée telle quelle comme un paramètre de l’appel RPC, de la même manière que n’importe quel champ de requête non authentifié est considéré comme fiable ?
La documentation est précise sur ce que le chiffrement lui-même protège.
Il ne dit rien sur ce qui protège la valeur bornée dans le temps qui détermine combien de temps cette protection est censée durer.