Résumé

  • La RFC 9709 injecte dans HKDF l’encodage DER complet de l’AlgorithmIdentifier interne, paramètres compris, avec la clé de contenu initiale.
  • Toute réécriture de l’algorithme authentifié ou de ses paramètres produit donc une autre clé, et non un oracle CBC exploitable.
  • Le mécanisme protège la confidentialité contre cette transformation ; il ne prouve ni l’expéditeur, ni l’innocuité du contenu, ni l’autorisation d’agir.

Quand la description commande le calcul

Le scénario étudié par le groupe LAMPS ne commence pas par la découverte d’une clé. Un intermédiaire prend un contenu CMS protégé par AES-GCM ou AES-CCM, puis présente certains blocs comme du contenu AES-CBC. Si le détenteur de la clé traite cet objet transformé et laisse filtrer le résultat, il devient un « oracle inverse » : l’attaquant peut vérifier des hypothèses sur un bloc structuré et peu entropique.

Les diapositives de l’IETF 118 nuançaient la portée pratique. Dans S/MIME, le résultat peut n’être qu’un amas de données manifestement incohérent ; un logiciel peut rejeter l’en-tête avant toute divulgation ; les systèmes réellement vulnérables n’étaient pas recensés. Ces obstacles ne sont pourtant pas une propriété cryptographique. Dans une autre application CMS, un aperçu, un champ analysé, un accusé de réception ou un changement d’état peut suffire à confirmer une hypothèse.

La RFC 9709 transforme alors la description en entrée de sécurité. Le destinataire annonce id-alg-cek-hkdf-sha256 dans ses capacités S/MIME, sans paramètres. Si l’émetteur choisit la protection, l’algorithme extérieur de chiffrement du contenu porte cet OID. Son paramètre obligatoire contient l’AlgorithmIdentifier intérieur réel : algorithme de chiffrement et paramètres associés.

Les deux extrémités dérivent ensuite une clé de travail, CEK-prime, avec HKDF-SHA-256. La CEK initiale sert de matière secrète d’entrée ; le sel est la chaîne ASCII fixe « The Cryptographic Message Syntax » ; le champ info reçoit l’encodage DER intégral de l’identifiant intérieur — balise de séquence, longueur, OID et paramètres encodés. La sortie conserve la longueur de la clé initiale, dans la limite HKDF-SHA-256 de 8 160 octets.

La précision octet par octet constitue la défense. Remplacer GCM par CBC, modifier un vecteur d’initialisation ou changer un paramètre encodé conduit à une clé différente. Le texte chiffré préparé pour la clé originale ne devient plus une expérience utile sous l’interprétation choisie par l’attaquant. Supprimer entièrement l’OID extérieur conduit le destinataire à employer la CEK initiale plutôt que CEK-prime : le message devient inaccessible, mais son contenu protégé n’est pas révélé. La conséquence est un déni d’accès, pas un gain de confidentialité pour l’adversaire.

Décomposer le verdict

Une trace opérationnelle devrait distinguer au moins sept faits : capacité annoncée par le destinataire ; choix effectif de l’OID extérieur ; algorithme intérieur et paramètres transportés ; octets DER réellement injectés dans la dérivation ; résultat du déchiffrement authentifié et de la vérification des données associées ; éventuelle sortie de texte clair ou de signaux hors de la frontière de confiance ; règle aval ayant permis le stockage, l’affichage ou l’action.

Réduire cette chaîne à « déchiffrement réussi » efface la différence entre incompatibilité et manipulation. À l’inverse, un objet correctement analysé n’est pas pour autant authentique. La RFC 9709 sépare des clés ; elle ne fournit ni signature, ni réputation de l’expéditeur, ni analyse de contenu, ni autorisation métier.

Le texte attire aussi l’attention sur les attributs authentifiés. Un attribut de condensat non chiffré peut aider à confirmer une supposition sur le clair. Du contenu non sollicité mais chiffré peut contourner des contrôles qui inspectent le pourriel ou l’hameçonnage. Une liste d’expéditeurs approuvés peut compléter la politique, mais répond à une question différente de la liaison de l’algorithme.

Une règle commune étroite

Le choix de SHA-256 est fixe, sans négociation de KDF ; une future fonction de hachage recevrait un nouvel OID. Le noyau commun reste ainsi déterministe : reconnaître l’enveloppe, conserver l’encodage intérieur exact, dériver, puis authentifier ou déchiffrer selon l’algorithme intérieur.

La discipline ordinaire des clés demeure nécessaire. Les CEK doivent être aléatoires et protégées. Les structures CMS de la RFC 5652, les données enveloppées authentifiées de la RFC 5083, les conventions AEAD de la RFC 5084, HKDF dans la RFC 5869, les capacités S/MIME de la RFC 8551 et les conseils d’aléa de la RFC 4086 restent des dépendances distinctes. Une clé faible, un terminal compromis ou une identité mensongère ne devient pas fiable par l’ajout de la RFC 9709.

Lors de cette vérification, la recherche d’errata du RFC Editor ne signalait aucun erratum pour la RFC 9709. Le registre SMI de l’IANA publiait les identifiants attribués. Ces éléments constatent l’état de coordination, pas la réalité des déploiements.

Sources