Résumé

  • RFC 9529 publie des entrées fixes, les messages EDHOC, les empreintes de transcription, les PRK intermédiaires, les paramètres OSCORE et des exemples invalides afin de comparer exactement une implémentation.
  • Une concordance complète démontre la reproduction de ce chemin de calcul, pas la fraîcheur de l’aléa, la garde des clés, l’exhaustivité des contrôles, l’autorité d’un justificatif ni l’effet d’une session réelle.
  • Une assurance exploitable relie cinq reçus distincts : reproduction du vecteur, couverture négative, entropie et garde des clés, identité et politique, puis résultat de la session.

Le rapport d’intégration ne montrait aucune différence. message_1, TH_2, CIPHERTEXT_3, PRK_exporter et le secret maître OSCORE correspondaient octet pour octet. Le tableau de bord en tira une conclusion compacte : « EDHOC vérifié ».

Sur l’équipement, la même clé privée éphémère revenait pourtant après chaque redémarrage.

Cette scène est illustrative, pas le récit d’un incident attribué. Elle montre la limite d’autorité du test. RFC 9529 fournit des traces annotées d’EDHOC avec entrées, sorties et résultats intermédiaires. Deux implémentations indépendantes les ont vérifiées. Ce sont des preuves exécutables remarquablement utiles : au lieu d’un voyant final, l’équipe peut identifier la première étape qui diverge.

Elles ne peuvent pas mesurer une propriété que le scénario fixe n’a jamais fait varier.

Un échange complexe devient observable

EDHOC vise les environnements contraints, mais sa chaîne de calcul réunit beaucoup d’objets : choix de méthode et de suite, identifiants de connexion, Diffie-Hellman éphémère, justificatifs, empreintes de transcription, entrées de MAC ou de signature, chiffrement authentifié, dérivation et paramètres OSCORE.

La première trace de RFC 9529 authentifie les deux parties par signature, repère leurs certificats X.509 avec x5t, emploie X25519 pour l’échange éphémère et EdDSA pour l’authentification. La seconde utilise l’authentification par DH statique, des CCS désignés par kid, P-256 et une négociation de suite qui passe par une erreur puis un deuxième message_1.

Le document donne TH_2, TH_3 et TH_4, les clés pseudorandom intermédiaires, les constructions de texte clair, de texte chiffré et de données associées, PRK_out, PRK_exporter, le secret et le sel maîtres OSCORE, puis leurs valeurs après KeyUpdate. Une différence finale peut ainsi être ramenée à un encodage CBOR, un justificatif omis, une suite erronée ou un contexte KDF distinct.

La trace affirme exactement ceci : avec ces entrées, le calcul spécifié produit ces octets.

Les secrets publiés servent la reproductibilité

Pour obtenir le même résultat partout, les entrées doivent être fixes. RFC 9529 publie donc les clés privées nécessaires aux exemples. Sa section de sécurité interdit de les considérer comme secrètes ou de les utiliser.

Ce n’est pas une faiblesse du document. Un vecteur a besoin de secrets connus pour rendre Diffie-Hellman, la signature et la dérivation reproductibles. Un produit a besoin de secrets imprévisibles, générés, stockés, utilisés puis effacés sous contrôle. Les mêmes octets ne peuvent tenir les deux rôles.

La réussite du vecteur ne dit donc rien sur la santé du générateur aléatoire, l’indépendance entre deux démarrages, l’extraction d’une clé, l’effacement de la mémoire, l’isolation matérielle ou la séparation de sessions simultanées. Ces propriétés exigent d’autres essais et d’autres propriétaires de preuve.

Un dossier sérieux place le résultat RFC 9529 à côté d’une mesure d’entropie, de la provenance de génération, d’un reçu de garde, d’essais après redémarrage et d’une recherche de répétition des clés publiques éphémères.

La transcription n’est pas l’identité en production

Les empreintes de transcription sont de puissants points de jonction. TH_2 combine la clé éphémère du répondeur et l’empreinte de message_1. Les états suivants ajoutent les textes authentifiés et les justificatifs. Clés dérivées et chiffrés dépendent de cette histoire.

Mais le vecteur fournit lui-même le justificatif et sa clé. Dans une session réelle, il faut résoudre x5t ou kid, appliquer les bonnes règles de validation, rattacher le justificatif à un appareil ou un opérateur, puis décider ce que ce principal est autorisé à demander. Une authentification mathématiquement correcte peut coexister avec une mauvaise association locale ou une permission excessive.

La sortie de l’exportateur n’est pas non plus le résultat applicatif. La dérivation d’un contexte OSCORE ne prouve ni l’acceptation du message suivant, ni le contrôle de rejeu, ni la fraîcheur d’une mesure, ni l’action d’un équipement. Elle fournit un antécédent cryptographique ; l’événement d’exploitation doit avoir son propre reçu.

Les exemples invalides ne ferment pas l’espace d’attaque

La section 4 contient des messages qu’une implémentation conforme ne doit pas produire et doit ou peut rejeter. On y trouve un tableau CBOR à la place d’une séquence, des enveloppes superflues, un nombre d’éléments faux, une clé éphémère codée comme texte et des encodages non déterministes.

Les cas cryptographiques comprennent une longueur de clé incompatible, une coordonnée hors du corps, un point absent de la courbe, un point Curve25519 de petit ordre, un MAC trop court et un encodage sans zéro initial requis.

RFC 9529 qualifie lui-même cette liste de petite. Des invalidités analogues existent dans d’autres champs et messages. Rejeter tous les cas publiés ne prouve pas la sûreté face à toutes les profondeurs, longueurs, transitions ou dépenses de ressources. Fuzzing, tests de propriétés, comparaison différentielle, limites de ressources et revue de code conservent chacun leur fonction.

La formulation contractuelle doit rester exacte : « rejette les traces invalides publiées dans RFC 9529 » est vérifiable ; « résiste aux entrées EDHOC malformées » est une revendication bien plus large.

L’encodage déterministe appartient à l’état cryptographique

Certaines divergences apparemment cryptographiques sont des divergences d’encodage. Le RFC distingue les octets bruts de leur représentation CBOR et rappelle que les éléments d’une séquence ou d’un tableau sont déjà encodés. Il rejette les entiers inutilement longs et les tableaux de longueur indéfinie lorsque l’encodage déterministe s’impose.

Ce n’est pas une question de style. Empreintes, signatures, MAC et KDF consomment des octets. Deux objets qui paraissent identiques dans un débogueur peuvent engendrer des états cryptographiques différents.

Le reçu de conformité doit donc conserver le message brut, la décision d’encodage, la première valeur intermédiaire divergente, la suite et la forme du justificatif. Un journal qui ne retient que l’objet décodé peut supprimer la cause même qu’il faudra expliquer.

L’interopérabilité est probante, dans son périmètre

La vérification par deux implémentations indépendantes réduit le risque qu’une convention privée soit prise pour la norme. Elle vaut davantage qu’un logiciel se testant contre lui-même.

Elle reste un accord sur des exemples choisis. Elle ne certifie pas toutes les suites, méthodes, formes de justificatif, données d’autorisation externes ou erreurs. Le registre EDHOC de l’IANA attribue un sens à des valeurs ; il n’atteste ni leur prise en charge par un produit ni leur activation sûre dans un contexte donné.

La norme et ses traces forment un plancher portable. L’étendue implémentée, la politique activée, le cycle de vie et les pannes observables restent à la charge des fournisseurs et opérateurs.

Cinq reçus au lieu d’un badge

Le premier reçu porte sur la reproduction : trace précise, version, plateforme, compilateur, bibliothèque cryptographique et première divergence éventuelle. Le deuxième décrit les entrées négatives : rejets publiés, étape du rejet, mutations supplémentaires et état après erreur.

Le troisième concerne l’entropie et la garde : santé au démarrage et en continu, répétition entre redémarrages ou clones, provenance des clés, isolation et effacement. Le quatrième porte sur le justificatif : résolution de x5t ou kid, ancre de confiance, règles de validation, principal opérationnel, suites autorisées et permission métier.

Le cinquième documente la réalité : état du pair, décision de rejeu, usage de l’exportateur, création du contexte OSCORE, message applicatif protégé et effet constaté.

La discipline des couches de réalité de Heng Lu s’applique directement. Une spécification n’est pas une implémentation ; un calcul conforme n’est pas une clé fraîche ; un justificatif valide n’est pas une autorisation ; un secret dérivé n’est pas un résultat applicatif. L’assurance vient de leur jonction, non de leur fusion.

Ce que les sources n’établissent pas

Les sources closes ne désignent aucun fournisseur ayant répété ses clés. Elles ne donnent ni taux d’adoption, ni fréquence d’échec de flotte, ni conclusion universelle sur les canaux auxiliaires. L’ouverture reste une hypothèse de contrôle.

Cette limite ne rabaisse pas RFC 9529. Elle explique sa force : rendre un calcul opaque contrôlable. Le vecteur prouve la reproduction. Le déploiement doit fournir les autres reçus.

Sources