Résumé

  • RFC 5295 isole cryptographiquement les racines d’usage et de domaine issues d’un EMSK, mais cette isolation disparaît si les noms, caches, durées, interfaces d’appel et destinataires se confondent.
  • Une preuve exploitable doit suivre la clé sans révéler sa valeur : usage, label, contexte, domaine, génération parente, appelant, échéance, transport et résultat du protocole enfant.

Le bon secret dans la mauvaise case

Lors d’une migration, un service de mobilité produisit la racine attendue pour le nouveau domaine. Le récepteur sélectionna néanmoins une entrée antérieure : son index de cache connaissait l’abonné, pas le nom de clé ni la génération EMSK. Les octets étaient corrects séparément. La décision de sélection ne l’était pas.

RFC 5295 réserve l’EMSK à la dérivation de racines. Une USRK dépend de l’EMSK, d’un label, d’un octet nul, de données optionnelles et d’une longueur. L’octet nul empêche qu’un label préfixe d’un autre crée une ambiguïté. La fonction est déterministe.

Cette exactitude ne remplit pas les colonnes oubliées par le système.

Le label est un contrôle, pas une note

Chaque usage doit posséder une définition et un label distinct coordonné. Le label est sensible à la casse. Les données optionnelles apportent du contexte. Un nom de USRK peut être dérivé de l’identifiant de session EAP avec les mêmes coordonnées.

Si deux équipes emploient des variantes de label, normalisent différemment le contexte ou stockent les racines sous un identifiant trop large, la séparation mathématique finit dans un espace de noms commun. Il faut conserver les octets exacts du label, le hachage des données optionnelles, la longueur, la version KDF, le nom EMSK et le nom de clé obtenu.

Le domaine délimite ce qui peut être dérivé

Une DSRK est une racine destinée à un domaine de gestion de clés. Le label de domaine entre dans la dérivation ; des DSUSRK plus étroites en descendent. Le domaine rassemble les systèmes autorisés à dériver, utiliser ou redistribuer la matière. La portée d’un enfant reste incluse dans celle du parent.

Un domaine autorisé à une seule fonction devrait recevoir la DSUSRK correspondante, non une DSRK qui ouvre toute la branche. La commodité de distribution ne constitue pas une restriction technique. Une hiérarchie de moindre privilège ne vaut que si le secret remis est lui-même étroit.

Renouveler ne signifie pas retirer

La durée d’une racine ne peut dépasser celle de l’EMSK. À expiration du parent, les racines doivent sortir de l’usage. Un nouvel échange EAP appelle de nouvelles racines dès que possible, mais le remplacement des enfants dépend de leur définition d’usage.

Créer une nouvelle génération ne prouve donc pas la disparition de l’ancienne. Les copies distantes, caches et enfants ont besoin d’un inventaire, d’une échéance et d’un événement de retrait observé. Sans ces éléments, une rotation réussie peut coexister avec une autorité résiduelle.

L’API peut annuler l’isolation

L’EMSK doit rester au plus près de son point de dérivation. L’implémentation expose plutôt une interface de racines et peut limiter les clés accessibles à chaque appelant. Une couche inférieure ne doit pas supposer qu’elle possède l’EMSK.

Une API peut toutefois remettre la bonne racine au mauvais composant. Le défaut n’est pas dans la fonction cryptographique mais dans la politique d’appel. Le reçu doit nommer l’appelant, l’usage demandé, le domaine, la décision et le nom retourné, jamais le secret.

Les applications supérieures ne devraient pas non plus faire reposer leur sécurité uniquement sur l’authentification d’accès. Ce raccourci lie leur cycle de vie à une technologie de couche basse et complique les chemins sans EAP.

Transporter le contexte avec le secret

Lorsqu’une racine est distribuée, confidentialité et intégrité sont obligatoires ; expéditeur et destinataire doivent être authentifiés et autorisés. L’identité de la clé et ses contraintes, dont sa durée, accompagnent la valeur. RFC 5295 ne définit pas le mécanisme de transport.

Un canal parfaitement chiffré peut donc livrer un secret impossible à interpréter correctement. Le reçu de distribution doit inclure les identités des deux extrémités, le canal protégé, le nom de clé, le domaine, l’usage, la génération, l’échéance et l’accusé d’installation.

La racine n’améliore pas son parent

La robustesse effective d’une dérivation ne dépasse jamais celle de l’EMSK ou de la clé maîtresse de la méthode EAP. Multiplier les branches ne crée pas d’entropie. Une racine qui alimente de nombreux enfants peut exiger de l’aléa frais dans leur dérivation.

L’architecture doit donc être évaluée sur la chaîne entière : parent, nom, délégation, stockage, rotation et emploi observé.

Sources