Résumé

  • RFC 3185 permettait à la clé de chiffrement du contenu d’un premier objet CMS de fournir la clé d’enveloppement d’objets suivants, économisant des opérations asymétriques au prix d’un état durable.
  • Si le premier objet avait remis la clé à l’ensemble S1, un second objet adressé seulement à un sous-ensemble restait déchiffrable par tout S1. L’omission d’un nom n’effaçait pas la clé déjà possédée.

La révocation est un acte sur une capacité, pas seulement une modification de liste. C’est le point historique le plus net de Reuse of CMS Content Encryption Keys, publié en octobre 2001 sur la voie des normes et aujourd’hui présenté par le RFC Editor comme Proposed Standard.

Le problème de départ était économique. CMS EnvelopedData savait chiffrer un contenu et distribuer sa clé par des mécanismes symétriques ou asymétriques. Or l’établissement asymétrique coûtait cher. Un client pouvait vouloir protéger séparément plusieurs champs d’une même transaction ; deux serveurs pouvaient échanger très fréquemment. RFC 3185 proposait alors de réemployer le secret déjà établi.

Le document ne prétendait pas définir un protocole complet. Il qualifiait lui-même le dispositif de « trick » à insérer dans un contexte plus large, lequel devait régler la perte de l’état, la durée de conservation et les erreurs. L’API cryptographique devait permettre au niveau CMS d’accéder au matériau nécessaire. Les algorithmes de chiffrement de contenu et d’enveloppement de clé devaient avoir des formats et des forces compatibles. Ce n’était pas une gestion générale de clés de groupe.

Le premier objet, MSG1, portait dans ses attributs non protégés une valeur CEKReference. Cette valeur identifiait sa clé de chiffrement de contenu, la CEK. Un objet ultérieur, MSG2, reprenait l’identifiant comme KEKIdentifier. Le destinataire retrouvait la CEK conservée et en dérivait la clé d’enveloppement, ou KEK, utilisée pour obtenir la nouvelle CEK.

La référence n’était pas la clé. La connaître ne donnait pas le secret. Lorsque les formats concordaient, la dérivation renversait les octets de la CEK précédente, afin d’éviter une construction précise fondée sur un couple texte clair–texte chiffré connu. Si les formats différaient, une option employait PBKDF2 avec la CEK comme entrée plutôt qu’un mot de passe. Ces choix appartiennent au contexte de 2001 ; les RFC ultérieures sur CMS, PBKDF2 ou l’enveloppement AES ne prouvent ni déploiement ni modernisation implicite du mécanisme.

Le passage décisif concernait les destinataires. Si MSG1 avait été envoyé à S1 et MSG2 seulement à un sous-ensemble de S1, tous les membres de S1 restaient capables de déchiffrer MSG2. Le champ récent disait qui le nouvel objet déclarait comme destinataire. L’histoire de distribution disait qui possédait réellement la matière permettant de calculer la KEK. Ces deux populations pouvaient diverger.

On peut appeler cette conséquence persistance de l’ensemble destinataire, à condition de préciser qu’il s’agit d’une analyse éditoriale, non d’un terme du RFC. Elle ne vaut pas pour tout CMS. Elle résulte ici de la réutilisation volontaire de la CEK de MSG1. Un tiers qui ne possède que l’identifiant n’acquiert aucun pouvoir.

CEKMaxDecrypts tentait d’encadrer la durée. L’émetteur pouvait annoncer combien de messages ultérieurs réutiliseraient la clé. Il devait respecter ce nombre ; le destinataire le traitait comme une indication, gardant la référence et la CEK jusqu’aux réceptions attendues ou jusqu’à une limite locale. En l’absence d’attribut, une seule réutilisation était supposée.

Mais ce compteur n’était pas une commande d’effacement à distance. Il ne prouvait pas que tous les destinataires avaient reçu les mêmes objets, incrémenté le même compteur, supprimé chaque copie ou effacé un support hors ligne. Une valeur énorme, ou des messages promis qui n’arrivaient jamais, pouvait même pousser le destinataire à conserver trop longtemps son état. Le RFC recommandait donc des plafonds et délais locaux.

Deux autres limites étaient explicites. Le chiffrement n’authentifiait pas l’émetteur : quiconque pouvait fabriquer un EnvelopedData avec une référence connue. Reconnaître la référence ne prouvait pas l’identité ni l’autorisation de l’auteur. La bonne référence ne protégeait pas davantage contre la répétition ou l’insertion. Authenticité, intégrité, fraîcheur et ordre exigeaient des preuves séparées.

Le succès du déchiffrement restait lui aussi étroit. Il indiquait qu’un acteur avait retrouvé du matériau et des paramètres permettant de produire un texte clair accepté par les contrôles exécutés. Il ne prouvait pas que le message était neuf, qu’il provenait du bon émetteur, que les anciens membres ne pouvaient plus le lire, que le texte clair avait été gardé en sûreté ou que l’application avait réussi.

Le RFC autorisait une chaîne roulante : la KEK du message n dérivait de la CEK du message n−1, tandis qu’une nouvelle CEK aléatoire pouvait servir au message suivant. Il avertissait qu’une dérivation circulaire de la CEK depuis sa propre KEK pouvait fixer accidentellement la clé. Il fallait donc conserver la provenance de chaque dérivation et vérifier l’indépendance de la nouvelle clé.

Même l’échec devait être typé. Attribut inconnu, état expiré, référence absente, incompatibilité d’algorithme, mauvaise clé et paramètre altéré ne sont pas le même incident. Les réduire à « échec du déchiffrement » rend impossible le diagnostic de l’autorité et de la garde.

RFC 3185 rappelle ainsi qu’une liste est une représentation présente, tandis qu’une clé distribuée est une capacité historique. Pour savoir qui pouvait lire MSG2, il faut reconstruire la remise de MSG1, la conservation des CEK, la dérivation, l’expiration locale et les observations de déchiffrement. L’enveloppe récente, seule, ne suffit pas.