Résumé

  • Un projet individuel daté du 27 octobre demande au destinataire BPSec de fixer, pour chaque service exigé et chaque bloc visé, la source de sécurité autorisée et la clé correspondante. La signature d’un autre relais légitime ne remplit pas ce mandat.
  • Pour établir que l’en-tête et le contenu appartiennent au même bundle, le bloc d’intégrité du contenu doit couvrir lui-même le bloc primaire. Deux vérifications séparées ne prouvent pas leur association.

Le relais n’a pas volé sa clé

Le scénario gênant commence avec un acteur autorisé. Dans un réseau à tolérance de délai, un relais peut avoir sa propre clé et le droit d’ajouter une protection à certains échanges. Il peut aussi recevoir un bundle dont un autre nœud a protégé le contenu. Si le relais remplace ce contenu et appose son propre bloc d’intégrité, la cryptographie peut confirmer sans erreur qui a signé le nouveau bloc. Un destinataire trop accommodant y verra la preuve demandée pour le contenu initial. Il aura vérifié une signature et perdu l’auteur.

La faille de raisonnement figure déjà dans la section 8.2.2 de la RFC 9172. Cette norme décrit le remplacement d’un Block Integrity Block, ou BIB, par un nœud légitime qui utilise sa propre clé. La formule « produit par un utilisateur légitime » laisse passer une substitution si elle devient l’unique critère d’acceptation. Le problème n’est donc pas une clé falsifiée. C’est un pouvoir attribué à la mauvaise clé.

Le projet de N. D. S. Gupthaa situe la correction chez le destinataire. Celui-ci doit connaître à l’avance la source de sécurité autorisée pour un service donné sur un bloc donné et la matière cryptographique associée. Il ne peut ensuite compter un BIB ou un Block Confidentiality Block, BCB, comme satisfaction du service que si ce bloc se vérifie sous cette clé attendue. Un autre signataire peut être parfaitement habilité ailleurs ; il ne peut pas s’inviter dans cette ligne de la politique locale.

Le registre de l’IETF classe le texte comme projet individuel, révision 00, sans filière RFC ni approbation de l’IETF. Son objet est une règle proposée au destinataire, pas le compte rendu d’un système installé.

La liste des bons acteurs est une mauvaise carte des pouvoirs

Les règles R1 à R4 du projet imposent une politique plus précise qu’une liste de clés fiables. R1 désigne la source attendue et la clé par service et par bloc. R2 refuse qu’un autre émetteur satisfasse cette exigence, même s’il est légitime dans le même déploiement. R3 déclare le service exigé en échec quand aucune protection conforme n’arrive. R4 ferme la porte au transfert de privilège : le droit d’un relais de protéger un échange ne le rend pas dépositaire du contenu émis par un autre nœud.

Cette distinction rend enfin le mot « confiance » utile. On peut faire confiance à un relais pour transporter un bundle, pour le protéger à un passage déterminé, ou pour attester l’origine d’une catégorie explicitement déléguée. Ce sont trois contrats. Un tableau qui range toutes les clés sous « autorisées » efface les contrats au moment où le destinataire doit les appliquer.

Le champ Security Source reçu dans un bloc est, selon le projet, un indice de recherche non fiable. Il dit qui se présente, pas qui possède le mandat. Si le bloc entrant choisit lui-même l’entrée de politique qui l’évaluera, le contrôle ressemble à un contrôle d’identité où le visiteur rédige sa propre liste d’accès. La comparaison doit partir de l’attente locale, puis aller vers la preuve reçue.

Les clés propres à chaque source constituent la condition matérielle du raisonnement. Lorsque tous les nœuds partagent une seule clé, la RFC 9172 relève qu’un détenteur légitime devient privilégié pour cette clé. Le destinataire ne peut pas reconstituer une séparation des sources que la garde des clés a détruite. Avant de configurer R1, l’exploitant doit donc pouvoir dire qui détient quoi, pour quel flux et sous quelle règle de remplacement.

Deux pièces vraies, un assemblage faux

Le cinquième contrôle porte sur une autre substitution. Un BIB peut protéger le contenu et un second BIB protéger séparément le bloc primaire du bundle. Les deux peuvent provenir authentiquement de la même source, mais de deux bundles différents. Deux verdicts cryptographiques positifs ne disent pas que cet en-tête accompagnait ce contenu. Un classeur contient parfois deux documents signés ; leur voisinage ne constitue pas une signature commune.

R5 exige que le BIB du contenu inclue le bloc primaire dans sa propre portée d’intégrité. La section 3.3.3 de la RFC 9173 définit le bit 0 de cette portée et la valeur par défaut 7 lorsque le paramètre est omis. Un BIB séparé sur le bloc primaire ne remplace pas cette liaison. La RFC 9171 montre pourquoi l’assemblage importe : le bloc primaire porte les données de traitement du bundle, tandis que le bloc de charge utile porte les données applicatives. L’intégrité du couple doit être établie par une preuve commune.

Le verdict doit garder son objet

Le projet annonce une analyse formelle sous Tamarin et un vérificateur de configuration comme artefact à publier, disponible sur demande. Le texte public ne permet pas d’examiner ces artefacts ni un déploiement. Une configuration de destinataire et une trace de substitution publiquement inspectables permettraient de vérifier comment les règles R1 à R5 tiennent dans une exploitation réelle.

Le bénéfice immédiat du projet est déjà intelligible : remplacer le voyant « signature valide » par une question complète. Quelle source était attendue, pour quel service, sur quel bloc, avec quelle clé et quelle portée d’intégrité ? Le relais peut avoir apposé un cachet impeccable. Le destinataire doit encore vérifier qu’il avait le droit de cacheter ce colis-là.

Sources