Résumé

  • Le projet individuel HCGA, daté du 27 octobre, dérive de la clé publique les bits situés entre le préfixe global contrôlé par l’opérateur et le /64.
  • Avec un préfixe /48, ces bits sont au nombre de 16. La collision possible en environ 2^16 essais oblige l’opérateur à conserver l’identité de la clé admise et à contrôler l’origine des paquets.

Le cadenas tient, mais deux clés peuvent se présenter à la même porte. Dans le projet Hierarchical Cryptographically Generated Addresses, ce n’est pas la clé qui décide laquelle possède le sous-réseau. C’est le registre d’admission du réseau. Ce détail administratif devient la pièce centrale d’une proposition destinée aux charges de travail et aux agents d’un environnement partagé.

La règle existante, RFC 3972, calcule l’identifiant d’interface de l’adresse IPv6 à partir d’une clé publique ; l’infrastructure fournit le préfixe /64. HCGA remonte d’un étage : il propose de calculer les bits de sous-réseau entre le préfixe global et la limite /64 à partir de la clé et d’un modificateur. Le préfixe global demeure administré par l’opérateur. Pour refaire le calcul, un vérificateur a besoin de la clé, des modificateurs et du compteur de collision enregistrés lors de la création.

Le chiffre qui change la gouvernance figure dans la section de sécurité du projet. Un préfixe /48 laisse 16 bits à calculer avant d’atteindre un /64. Une deuxième clé, ou un autre modificateur, peut trouver le même résultat après environ 2^16 tentatives. La collision touche ces bits de sous-réseau. Elle ne casse ni la clé privée ni l’adresse IPv6 complète de 128 bits : l’identifiant d’interface conserve sa propre borne de hachage, beaucoup plus élevée. Mais le /64 pris isolément perd sa prétention à désigner une seule clé.

Le projet confie alors à une architecture environnante l’enregistrement d’une seule clé admise pour chaque /64. Cette architecture doit garder le modificateur et les autres paramètres de génération, et imposer l’exclusivité. Une adresse présentée dans un paquet réclame également une preuve d’origine : signature correspondant à la clé privée ou contrôle de l’adresse source dans le réseau. Un enquêteur situé hors du lien local devra pouvoir retrouver les paramètres ; sans cette conservation, le calcul ne reconstitue pas le titulaire admis.

Le routage ne fournit pas ce registre. L’opérateur annonce son préfixe global par BGP, sous une ROA RPKI, tandis que les /64 restent internes. La ROA établit l’autorisation d’annoncer le bloc large ; elle ne choisit pas la clé admise dans chacun des sous-réseaux. Confondre ces deux autorités donnerait à une preuve de routage une portée qu’elle n’a pas.

Une attribution réussie a son coût. Le projet décrit un /64 stable même quand l’identifiant d’interface change. Cette stabilité facilite le rapprochement des activités d’une même charge de travail. Les adresses temporaires de RFC 8981 poursuivent un autre objectif de confidentialité. Le calcul HCGA ne révèle pas non plus si une clé est protégée par matériel ou seulement par logiciel ; l’architecture RATS offre un cadre d’attestation séparé.

Le Datatracker IETF classe le texte comme projet individuel Standards Track, au stade « I-D Exists ». Le test utile est concret : produire deux clés menant aux mêmes 16 bits sous un /48 de laboratoire, refuser la seconde, puis demander à un vérificateur extérieur de retrouver la première clé, les paramètres et la preuve d’origine du paquet. La porte cryptographique vérifie le registre ; elle ne peut pas le tenir à la place de l’opérateur.