Résumé

  • La recommandation UIT-T X.1711 normalise l’architecture commune et le déroulement général des protocoles de distribution quantique de clés ; elle n’en choisit aucun.
  • Son propre périmètre exclut les preuves de sécurité propres à chaque protocole, la mise en œuvre des modules et leur sécurité pratique, alors que la communication de l’UIT la présente comme référence pour la certification.

Le communiqué ressemble à un raccourci pour les achats. L’UIT présente X.1711 comme la première norme internationale sur les protocoles de distribution quantique de clés, une référence pour la certification de sécurité et une aide au choix d’un module certifié. La recommandation est plus précise. Elle fournit un plan commun. Elle ne choisit pas l’itinéraire, n’inspecte pas le véhicule et ne délivre pas le certificat.

Approuvée le 16 mars 2026 et en vigueur, X.1711 couvre le cadre des modules QKD reliés par un lien quantique dans la couche quantique d’un réseau. Elle décrit l’architecture et le fonctionnement général d’un protocole. Sa note de périmètre trace ensuite une frontière nette : protocoles particuliers, preuves de sécurité, implémentations des modules et sécurité de l’implémentation restent à l’extérieur.

Cette phrase porte une grande partie de l’histoire. La recommandation montre où les fonctions se raccordent sans dire quel protocole un acheteur doit juger fiable. Son corps distingue l’étape de communication quantique, qui produit des données brutes partagées, de la distillation de clé, qui transforme ces données en clé finale. Cette seconde étape comprend des opérations très concrètes : sélectionner les données utiles, estimer les paramètres du canal, corriger les erreurs, vérifier que les deux extrémités ont la même donnée, puis appliquer l’amplification de confidentialité.

L’estimation des paramètres est le point de décision. Si les mesures du canal ne permettent pas de produire une clé selon les conditions du protocole, la procédure s’interrompt et les deux extrémités produisent une clé de longueur nulle. Le mot « quantique » ne transforme pas chaque échange en clé. Il reste une mesure, un seuil et une branche « arrêt ».

Le canal classique apporte un autre rappel utile. Il transporte les échanges nécessaires à la sélection des données, à l’estimation, à la correction et à l’amplification. X.1711 exige l’intégrité et l’authentification de l’origine de ces messages ; leur confidentialité n’est pas nécessaire. Un attaquant peut lire ces échanges. Toute modification doit être détectée et provoquer l’arrêt du protocole. Les signaux quantiques n’authentifient pas gratuitement les interlocuteurs du canal classique.

Le document présente des exemples de protocoles BB84 à états leurres et à modulation gaussienne, ainsi que des annexes sur les modèles d’attaque, les preuves et la sécurité de mise en œuvre. Ces annexes ne font pas partie intégrante de la recommandation. L’annexe VI décrit les imperfections des appareils et les canaux auxiliaires ; elle explique que la caractérisation et les tests comptent pour la certification. C’est une carte du problème, pas un plan de certification.

La différence entre une norme utile aux acheteurs et une norme qui peut valider du matériel tient à ces pièces manquantes. X.1711 offre un vocabulaire et une séquence communs pour discuter du comportement d’un protocole. La communication de l’UIT va plus loin, jusqu’à la certification et au choix d’un produit. La recommandation ne nomme ni laboratoire, ni profil de réussite, ni configuration obligatoire du module, ni registre public des équipements certifiés. Sa note place la sécurité de mise en œuvre hors périmètre.

L’acheteur a besoin du reçu derrière le badge : quelle version du matériel a été testée, quel protocole et quelle preuve de sécurité étaient visés, comment l’authentification du canal classique a été vérifiée, quels tests de canaux auxiliaires ont été conduits, quel résultat a été accepté et qui l’a signé. « Conforme QKD » sans ces champs, c’est un autocollant avec un doctorat en physique.

Le cadre reste utile. Une architecture commune donne aux ingénieurs réseau et aux groupes de normalisation un terrain partagé pour discuter des interfaces et des conditions d’échec. Mais la certification d’un module doit être portée par un autre reçu : procédure de test, configuration, critères de réussite, organisme émetteur et liste à jour des modules testés. X.1711 pose la carte sur la table. Il manque encore l’adresse du bureau des certificats.

Sources