KEM et DEK/KEK... On vous explique

Reprenons les bases. Le chiffrement symétrique demande la même clé pour chiffrer et déchiffrer. Le chiffrement asymétrique demande une clé pour chiffrer, et une autre pour déchiffrer. Pour ceux qui ne le savent pas encore, le chiffrement asymétrique est très lent comparativement au chiffrement symétrique (1000 fois plus lent selon la police, 10 000 fois selon les manifestants). Point intéressant, le chiffrement symétrique est résistant à la tempête quantique, ce qui est un sacré avantage.

Pour revenir à la vitesse, l’encapsulation de clé est un mécanisme déjà largement utilisé en HTTPS : le certificat TLS (dans les premières versions du protocole) ne sert en réalité qu’à chiffrer de façon asymétrique une clé de chiffrement symétrique. Ainsi, à l’établissement de la session TLS, une clé symétrique (un secret) est générée aléatoirement. C’est elle qui servira (une fois la session établie) à chiffrer tous les échanges (le trafic) courants. Et pour transmettre cette clé de façon sûre et secrète au destinataire, on utilise le chiffrement asymétrique (via le certificat présenté). On peut se le permettre car le secret à transmettre ne fait que quelques centaines ou quelques milliers de bits, alors qu’on est susceptible d’échanger des Go de données via http, où le chiffrement symétrique est bien plus efficace. On parle alors de KEM (Key Encapsulation Mechanism). Ce mécanisme est essentiel puisqu’il a permis la sécurisation des flux et l’essor d’Internet !

Pour sécuriser des fichiers, on va utiliser une variante, mais sur le même principe : on va protéger des clés secrètes en les mettant dans une enveloppe protectrice. Voyons cela de plus près en l’appliquant à ce qui nous intéresse (nos petits fichiers) et surtout en comparant les options possibles, au préalable. Puis nous regarderons ce qu’apporte le concept de KEK/DEK (Key Encryption Key/Data Encryption Key).

Chiffrement symétrique simple

La première idée qu’on peut avoir pour protéger ses fichiers est de les chiffrer tous avec une seule et même clé qu’on serait le seul à connaître. Prenons pour cela une image, avec notre ami Flock, qui veut protéger ses fichiers : il va mettre chacun des fichiers (représentés ici par des feuilles) dans un coffre distinct, en mettant le même cadenas partout. Flock est le seul à avoir la clé, et tout va bien.

Or Flock est très sociable et il aime bien partager ses fichiers avec un de ses petits camarades de la rédaction. Mais uniquement le coffre #13 et le #42, pas les autres. Vous voyez le problème : c’est la même clé qui ouvre tous les coffres. Donc si Flock prête sa clé, ou en donne une copie, le destinataire pourra ouvrir toutes les boîtes. En outre, on se dit instinctivement que chiffrer tous ses fichiers avec la même clé, c’est mal. Sans entrer dans les détails, cela faciliterait un travail de cryptanalyse puisque tous vos fichiers seraient chiffrés de la même manière.

Le trousseau de clés

Qu’à cela ne tienne : Flock pourrait mettre un cadenas différent sur chaque coffre, et ainsi ne donner que les (copies des) clés des coffres concernés : la clé #13 et la #42. C’est bien, mais s’il a plein de fichiers, Flock devra se balader avec un trousseau de clés énorme, et donner à l’autre utilisateur autant de copies de clés que de fichiers (de coffres) partagés. On imagine bien que Flock a bien d’autres choses à faire qu’à gérer des clés : il n’aurait plus le temps de nous faire ses jolis dessins. Sans compter le casse-tête pour s’envoyer les clés en toute sécurité !

Autre cas de figure possible : le correspondant de Flock part sans laisser d’adresse avec ses clés (et la caisse). Comment être sûr que ce voleur ne reviendra pas ouvrir en douce les coffres de Flock ? On verrait bien la solution de changer les cadenas des coffres #13 et #42, avec de nouvelles clés. Mais que faire si le nombre de coffres est conséquent ? Pire : si jamais il partage quelques fichiers avec une troisième personne, il va falloir qu’il contacte ce troisième personnage pour lui changer ses clés (puisqu’il a changé les cadenas) ! Rappelez-vous que chaque utilisateur doit posséder le trousseau complet des clés des coffres partagés, puisqu’elles sont toutes différentes d’un coffre à l’autre !

Et si on protégeait les clés ?

Procédons autrement. Conservons le principe d’un cadenas et d’une clé spécifique à chaque coffre : sinon, le partage est impossible. Pour la clarté, on va appeler ces clés des clés de chiffrement des données, ou Data Encryption Key (DEK). Il existe une méthode qui va permettre de nous affranchir de la gestion de ces nombreuses DEK : le chiffrement d’enveloppe (facile).

Chiffrement asymétrique

Faisons un bref retour sur le chiffrement asymétrique, en conservant la métaphore des cadenas (qui a ses limites). Le principe de ce chiffrement est qu’un utilisateur possède une clé unique (bleue) mais qu’il puisse distribuer autant de cadenas bleus qu’il le souhaite. Quelqu’un qui voudrait envoyer un mot d’amour – message que seul Flock puisse lire – pourrait écrire son message, le mettre dans un coffre, le fermer avec un cadenas bleu (qu’il trouve en accès libre, ça serait l’équivalent de la clé publique d’un certificat). Tout le monde serait capable de réaliser cette opération, mais seul le possesseur de la clé bleue pourrait ouvrir le coffre (Flock, pour lire son mot d’amour message).

Encapsulation ou chiffrement d’enveloppe

Revenons à nos coffres, disposant chacun d’un cadenas unique (pour son contenu). Imaginons maintenant qu’on fasse une copie des clés #13 et #42 (une copie par utilisateur), et que chacun des utilisateurs dispose également d’une clé publique et d’une clé privée (donc d’une clé unique par utilisateur et d’une multitude de cadenas que cette clé ouvrirait). Flock aurait le bleu, l’autre utilisateur le rouge.

Pour un utilisateur donné, cette clé privée est appelée KEK (Key Encryption Key) et elle va servir de la façon suivante : pour un coffre donné, ayant sa clé DEK pour chiffrer les données, on va associer un petit coffre supplémentaire pour Flock et un autre pour le second utilisateur. On va mettre une copie de la clé DEK (par exemple la clé #42) dans un des petits coffres et le fermer avec un cadenas bleu. Une autre copie de cette clé #42 sera mise dans un autre petit coffre fermé lui par le cadenas rouge.

On réplique ce mécanisme sur le coffre #13 mais aussi avec tous les autres utilisateurs nécessaires. Pour les autres coffres, non partagés, un seul petit coffre suffit : celui du propriétaire (comme avec le coffre #27).

Et maintenant : comment ouvrir les coffres ?

Pour Flock, il lui suffit d’avoir sa clé bleue : il peut ouvrir tous les coffres où il existe un petit coffre secondaire ayant un cadenas bleu. Dedans, il trouvera la clé (DEK) pour ouvrir le coffre correspondant. Et pour l’autre utilisateur, ayant une clé rouge, il pourra ouvrir tous les coffres auxquels il a droit, et uniquement ceux-ci, en allant chercher la clé correspondante (DEK) dans le petit coffre. Et s’il n’y a pas droit, il n’y a pas de petit coffre à côté !

Variante de la variante

Dans notre exemple, la clé de chiffrement des données (DEK) a été chiffrée avec une clé asymétrique, mais un des avantages de l’encapsulation des clés est de rendre indépendants le chiffrement du fichier et la protection de la clé. Il est donc également possible de choisir une autre méthode de protection de clés, comme par exemple une clé symétrique connue du seul utilisateur (cela dépend des cas d’usages).

Pourquoi utiliser un chiffrement symétrique ? Parce qu’ainsi vous rendez la protection des clés DEK résistante au déchiffrement quantique (quand il existera). Pas mal, non ? Pourquoi alors ne pas l’avoir proposé en premier, me direz-vous ? A cause de l’éternel problème de l’échange de la clé. Si vous protégez vos petits coffres avec du chiffrement symétrique, il faudra que quelqu’un se charge de transférer les clés DEK de façon sûre aux différents destinataires, en utilisant par exemple l’algorithme Diffie-Hellman. C’est tout à fait réalisable mais cela ajoute une couche technique (et donc de complexité) à l’affaire.

Le bonus du Zero Knowledge

Cerise sur le gâteau : on peut se passer de stocker une clé KEK en utilisant un mécanisme appelé dérivation, quand on utilise une clé symétrique ! La dérivation consiste à générer une clé de chiffrement symétrique solide à partir d’un simple mot de passe saisi par l’utilisateur. Cette dérivation est agrémentée de différents éléments cryptographiques pour la construction de la clé de chiffrement (KEK) qui n’est ainsi stockée nulle part : elle est recalculée au démarrage de votre session ou au lancement de l’outil de chiffrement.

Normalement, vous vous demandez ici quel est l’intérêt de saisir un mot de passe à la place d’une clé de chiffrement : si je dois saisir quelque chose, qu’est-ce que j’y gagne ? Expliquons : saisir un élément permet de ne pas le stocker. Mais, pour contrer une cryptanalyse cherchant à retrouver une clé de chiffrement symétrique, il faut impérativement une clé ayant une forme complexe du genre illisible, ce qui la rendra de facto impossible à retenir de mémoire (car une clé AES fait 128 ou 256 bits devant être les plus aléatoires possibles). Une fonction de dérivation comme PBKDF2 permet de créer, à partir d’une entrée simple, une clé complexe (en ajoutant du sel par exemple), un peu comme le fait une fonction de hachage. Vous pouvez ainsi passer de “password” à “2qGf18rU2Dnfm50iuNOj/A==” avec un vecteur d’initialisation à” dJchMyaKo9xmISLRuxFOOw==”. Avouez qu’il est plus simple de retenir “password” que le reste !

L’attaque par force brute est arrêtée par l’usage d’un sel ajouté au mot de passe, et le tour est joué : votre clé de chiffrement KEK a une force suffisante et n’est stockée nulle part : cette solution est appelée Zero Knowledge, car personne n’a connaissance de cette clé importante n’apparaissant nulle part (sauf en mémoire pendant le traitement mais c'est un autre sujet relevant de la sécurité du système d’exploitation)