Résumé

  • Dans le RFC 5275, supprimer un membre d’une liste fermée ou administrée ne suffit pas : sans renouvellement des clés, l’ancien membre conserve une capacité de déchiffrement.
  • La preuve d’une exclusion doit suivre toute la chaîne, de la version effective de la liste jusqu’à l’activation des nouvelles clés et au traitement des clés anciennes ou déjà distribuées.

Imaginez un contrôle d’accès où le badge a été rayé du registre, mais où la porte s’ouvre encore. Personne ne contesterait que l’incident demeure. Dans une liste utilisant une clé symétrique partagée, l’écart est moins visible : l’écran d’administration montre un départ, alors qu’une copie de la clé continue d’exister sur une machine que l’organisation ne contrôle plus.

Le RFC 5275, publié par l’IETF en 2008 sur la voie de normalisation, décrit la gestion et la distribution de clés symétriques avec CMS. Son avertissement central est sans détour. Lorsqu’un membre est retiré d’une liste fermée ou administrée, la liste doit recevoir de nouvelles clés. Faute de quoi l’ancien membre, toujours détenteur de la clé de groupe, peut déchiffrer les messages auxquels il accède.

Un propriétaire décide, un agent exécute

L’architecture distingue le propriétaire de la liste, ou GLO, de l’agent de liste, ou GLA. Le premier crée la liste, choisit son régime — libre, administré ou fermé — et peut piloter les décisions d’adhésion et de renouvellement. Le second assure les fonctions de gestion du groupe et des clés. Il signe les objets glKey qui transportent les clés de chiffrement de clés, les KEK.

Cette répartition n’abolit pas le risque d’agence. Le texte précise qu’un GLA corrompu peut causer des dégâts. La confiance accordée à un rôle ne devient pas une preuve de bonne exécution. Il faut donc observer les transitions que ce rôle est censé produire.

Une demande glDeleteMember signée identifie une instruction. Selon le régime de la liste, elle peut venir du propriétaire ou du membre qui souhaite partir. Elle ne prouve pas encore que le bon enregistrement a été supprimé, que le même sujet n’existe pas sous un second identifiant, ni qu’une nouvelle clé est en service. Pour une liste fermée ou administrée, la procédure associe précisément la suppression à une demande glRekey.

Le point de rupture se trouve après la suppression

Une exclusion réellement opérante traverse plusieurs frontières. La demande doit d’abord être authentifiée et appliquée à la bonne liste. Une nouvelle version de la composition doit ensuite devenir effective, sans doublon du membre sortant. Des KEK de remplacement doivent être créées pour ce nouvel ensemble. Elles doivent parvenir aux membres qui restent. Enfin, les émetteurs doivent cesser d’utiliser l’ancienne génération et les destinataires accepter la nouvelle.

Le format glKey donne un identifiant de clé, la KEK enveloppée, l’algorithme et les dates notBefore et notAfter. Lorsque les destinataires ne doivent pas connaître les autres membres, l’agent émet un message distinct pour chacun. L’option glRekeyAllGLKeys permet de demander la réémission de toutes les clés encore valables.

Ce vocabulaire technique révèle une règle de gouvernance : « envoyé » n’est pas « reçu », « reçu » n’est pas « activé », et « activé » n’est pas « ancien secret détruit ». Même un accusé de succès signé par l’agent décrit ce que l’agent affirme avoir accompli. Il ne démontre pas l’état de chaque terminal ni l’effacement de toutes les copies.

Les clés futures constituent une dette de révocation

Le RFC prévoit la distribution anticipée de plusieurs générations. generationCounter indique combien de clés sont remises ou maintenues en circulation ; duration fixe leur durée de validité. Deux clés au minimum sont distribuées au départ afin d’éviter une interruption lorsque la première expire.

Le bénéfice opérationnel est évident. Le passif l’est moins. L’exemple du RFC prend quatorze clés valables un an chacune : la dernière offre alors à l’attaquant au moins treize années pour travailler avant son usage. Une organisation qui prépositionne des secrets achète de la continuité en échange d’un horizon d’exposition plus long.

Lors d’un départ, il ne suffit donc pas de remplacer la clé active. Il faut établir l’inventaire de toutes les clés présentes ou futures déjà accessibles au membre sortant. Le même raisonnement s’étend aux chaînes d’enveloppement : si une KEK protège la suivante, et que l’une des clés de la chaîne est compromise, le RFC exige de considérer toutes les clés ultérieures comme compromises. La portée de la révocation suit les dépendances, pas seulement le numéro de la clé mentionnée dans le ticket.

Une signature ne fournit ni le contexte ni la mémoire

Les membres doivent associer les KEK stockées au nom du GLA qui les a distribuées. Ils peuvent ainsi vérifier qu’un renouvellement ultérieur vient de la même entité. Une signature valide, détachée du nom du groupe, de l’agent attendu, de l’identifiant de clé et de la chronologie, peut être valide mathématiquement tout en appartenant à la mauvaise histoire.

La protection contre le rejeu possède la même fragilité. Les nonces et signingTime n’aident que si les parties conservent un état suffisant pour comparer le nouveau message aux échanges passés. L’horloge peut dériver ; une politique locale définit la tolérance ; un message daté du futur doit être traité explicitement. Sans mémoire, le temps signé est un champ, pas une preuve de fraîcheur.

Les archives restent hors de portée de la liste

Le renouvellement limite l’usage futur d’une ancienne clé. Il n’efface pas un message déjà copié, une sauvegarde, un cache ou une clé exportée. L’exposition résiduelle dépend de la rencontre entre deux stocks : les textes chiffrés que l’ancien membre peut encore obtenir et le matériel cryptographique qu’il conserve.

Il faut donc séparer protection prospective et réparation rétrospective. Une bascule propre peut fermer l’accès aux messages futurs sans prétendre récupérer le passé. Cette précision n’affaiblit pas le contrôle ; elle lui évite une promesse impossible.

Le reçu qui manque à l’écran d’administration

Le RFC 5275 ne spécifie ni journal de transparence moderne, ni attestation universelle des terminaux, ni preuve d’effacement à distance. Il permet néanmoins de déduire la structure minimale d’un reçu d’exclusion.

Ce reçu relierait la demande signée au sujet et à la liste exacts ; nommerait la génération de membres devenue effective ; énumérerait toutes les clés actives, futures et dépendantes entrant dans la portée ; conserverait le résultat de distribution pour chaque membre restant ; fixerait l’instant de bascule ; indiquerait où les anciennes clés ont été désactivées ; et signalerait les copies ou messages dont le sort reste inconnu.

L’objectif n’est pas d’ajouter une couche institutionnelle. C’est de prouver la fonction minimale : après une frontière donnée, seuls les membres de la nouvelle génération peuvent recevoir et utiliser la nouvelle capacité.