Pilule rouge et bleue avec des messages codés

Encapsulation de clés et chiffrement d’enveloppes

Encore un coup du facteur ?

Avatar de l'auteur
Jean Gebarowski

Publié dans

Sécurité

24/11/2023
31

Pilule rouge et bleue avec des messages codés

Dans notre (laborieuse) saga pour protéger nos données contre des personnes ou des organismes mal intentionnés, il peut être utile d’apprendre ou de revoir certaines bonnes pratiques en matière de chiffrement. Il est essentiel de comprendre les choix structurants en ce domaine, afin de pouvoir ensuite choisir en confiance les solutions que nous utiliserons. Nous parlerons donc ici du chiffrement encapsulé, dont on va vite comprendre l’utilité pour nos petits fichiers grâce à notre ami Flock.

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.

Flock qui met des documents dans des coffres avec une clé unique

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).

Flock qui ouvre un coffre avec un document

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).

Flock à des une clé bleue pour ouvrir tous les coffres, Sébastien à une clé pour un coffre rouge

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)

31

Écrit par Jean Gebarowski

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

KEM et DEK/KEK... On vous explique

Chiffrement symétrique simple

Le trousseau de clés

Et si on protégeait les clés ?

Chiffrement asymétrique

Encapsulation ou chiffrement d’enveloppe

Et maintenant : comment ouvrir les coffres ?

Variante de la variante

Le bonus du Zero Knowledge

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (31)


Typhlos Abonné
Le 24/11/2023 à 17h 43
Article intéressant, merci !

Cependant, je ne suis pas tout à fait d'accord avec le tout dernier paragraphe : l'ajout d'un sel n'empêche pas les attaques par bruteforce, il empêche les attaques par rainbow table.

Le principe d'une attaque par rainbow table est qu'on précalcule toutes les KEK dérivées d'un très grand nombre de mots de passe (ou pour un hash de mot de passe), comme ça, quand on récupère une KEK, il suffit juste de regarder quelle mot de passe est associé à cette KEK dans notre rainbow table.

L'ajout d'un sel permet de rendre la rainbow table inopérante puisqu'il faut recalculer toute la rainbow table en ajoutant ce sel.

Les attaques par bruteforce sont elles mitigées (il n'est pas possible de l'empêcher entièrement) par le fait que les algorithmes de dérivation sont longs à calculer (par rapport à la vitesse d'exécution d'un processeur) et empêchent donc de faire un grand nombre de tentatives par secondes.
Modifié le 24/11/2023 à 18h18
Jean_G Abonné
Le 24/11/2023 à 18h 03
Oui, c'est tout à fait exact, mais hélas je n'arrive plus à retrouver l'émoticône Maître Capello sur le nouveau site. Je vais demander une formation au (rédac) chef.
Glandos Abonné
Le 25/11/2023 à 10h 23
Et même aujourd'hui, les algorithmes de dérivation évitent de se focaliser sur la difficulté en calcul, car les GPU ou carrément les ASIC sont trop optimisés. Du coup, argon2 et ses dérivés proposent carrément un coût en mémoire en plus. C'est d'ailleurs argon2 qui est recommandé aujourd'hui.
fred42 Abonné
Le 24/11/2023 à 17h 48
J'aimais déjà les articles de Jean,mais agrémentés des dessins de Flock, c'est encore mieux. Quant au #42, c'est du bonus ! :D
Mihashi Abonné
Le 25/11/2023 à 12h 00
Par contre, il manque le coffre #37 qui va de pair avec le #13… 😜
Refhi Abonné
Le 24/11/2023 à 17h 48
Merci pour cette vulgarisation de qualité. J'ai tout compris ! (je crois)

Par contre le doute subsiste : est-ce que Flock a été ému par la lettre de cette délicate et attentionnée "Urssaf" dont le nom transpire tendresse et affection ? (ou affliction, peut-être).
Le 24/11/2023 à 20h 05
A CHAQUE mail intitulé "l'Urssaf a laissé un message IMPORTANT pour vous dans votre interface", mon cœur bat la chamade.
Et puis en fait tout va bien 😁
Pseudooo Abonné
Le 25/11/2023 à 13h 13

Flock_dessins

A CHAQUE mail intitulé "l'Urssaf a laissé un message IMPORTANT pour vous dans votre interface", mon cœur bat la chamade.
Et puis en fait tout va bien 😁
La vie (ou les mails de l'URSSAF), c'est comme une boîte de chocolats.
typhoe Abonné
Le 25/11/2023 à 14h 01

Flock_dessins

A CHAQUE mail intitulé "l'Urssaf a laissé un message IMPORTANT pour vous dans votre interface", mon cœur bat la chamade.
Et puis en fait tout va bien 😁
J'avoue que l'article était très sympa, mais CE dessin était celui qui a fait bondir mon petit coeur à moi aussi... Ahhh, L'URSSAF ! ;-)
Ferd Équipe
Le 24/11/2023 à 19h 05
Eh. C'est pas pour nous la péter, mais le thème sombre est disponible.
C'est tout pour moi.
dvr-x Abonné
Le 24/11/2023 à 19h 31
Ahah trop bien, je valide !! Au top !
Le 24/11/2023 à 19h 36
Tu veux dire LES thèmes sombres ?
Kwacep Abonné
Le 24/11/2023 à 20h 14
Maintenant, il faut demander à flock 2 versions de ces dessins.
En ajoutant une version pour les thèmes sombre. Sinon ça fait trop de blanc d'un coup, c'est un comme un flash d'un radar automatique de notre chèr gouvernement !
-->[]
Mihashi Abonné
Le 25/11/2023 à 12h 04

Kwacep

Maintenant, il faut demander à flock 2 versions de ces dessins.
En ajoutant une version pour les thèmes sombre. Sinon ça fait trop de blanc d'un coup, c'est un comme un flash d'un radar automatique de notre chèr gouvernement !
-->[]
C'est possible de mettre un fond transparent, comme ça pas de souci quel que soit le thème.
Romain_Ph Abonné
Le 24/11/2023 à 21h 04
Super ! c'est génial un article sur le chiffrement et le thème sombre. Tu sais remonter le moral après une dur semaine :)
MsGambit Abonné
Le 24/11/2023 à 21h 44
De la douceur pour mes petits yeux , Merci !
typhoon006 Abonné
Le 24/11/2023 à 22h 58
Très bien le GIGA NOIR
merci !
Mihashi Abonné
Le 25/11/2023 à 12h 03
Cool, enfin 😁
(et au passage, le thème biafine, je l'aurais plutôt nommé collyre 😜)
Le 25/11/2023 à 17h 37
Salut,
D'habitude je suis pas trop 'thème sombre' mais celui-la est génial !!
Merci à toute l'équipe !

Et bravo aussi pour l'article, clair et bien fait :)
Modifié le 25/11/2023 à 17h39
SKN Abonné
Le 25/11/2023 à 22h 12
Top mais je vais faire mon chieur de service : sur mobile il faut un clic de plus qu'avant pour changer de thème.. et vu que le chieur de service met de la biafine le jour et devient drakula la nuit ça fait 2 clics de rrop par jour.. Et malgré la réactivité exemplaire du site ça va me faire perdre plus de temps qu'un numéro 2 chaque année c'est inadmissible! :p
Ah et je pense que c'est work in progress mais les radiobuttons de la sélection sont un peut pété (l'affichage des textes est foireux et le thème actuel n'est pas présélectionné ;) ).
Voilà, juste pour râler en bon français que je suis, j'attends le prochain poing dev avec impatience
Modifié le 25/11/2023 à 22h13
Oliverpool Abonné
Le 24/11/2023 à 20h 36
> le certificat TLS ne sert en réalité qu’à chiffrer de façon asymétrique une clé de chiffrement symétrique

Il me semble que ce n'est pas tout à fait correct (au moins dans les versions récentes de TLS).

Il y a bien une clef symétrique secrète, mais celle-ci ne transite pas sur le réseau. Elle est partiellement générée de chaque côté et "unifiée" avec Diffie-Hellman.
Le certificat TLS est juste utilisé pour signer la partie serveur (pour éviter une attaque MITM).

L'absence de transit réseau permet le "forward secrecy": même si la clé privée du certificat TLS est divulguée plus tard, l'échange qui a eu lieu ne pourra être déchiffré.


Cf mon commentaire sur https://next.ink/774/le-chiffrement-hybride-classique-et-post-quantique-comment-ca-marche/
Jean_G Abonné
Le 24/11/2023 à 22h 37
Ca n'était que pour faire une analogie : TLS 1.3 a en effet changé beaucoup de choses, et le mécanisme d'encapsulation qui était appliqué aux anciennes versions de TLS ne le serait donc plus, merci pour tes éclaircissements ! Pour les curieux : https://datatracker.ietf.org/doc/html/rfc8446#page-24 !
Le 25/11/2023 à 09h 35
Après Alice et Bob, Flick et Flock :)
chipotte Abonné
Le 25/11/2023 à 09h 40
Lire "encapsulage" dans le titre au lieu d'encapsulation m'a beaucoup troublé... Il me semble qu'en informatique c'est le second terme qui est couramment utilisé, même si c'est sûrement par analogie avec l'anglais.
Et par la suite on trouve les 2 termes dans l'article... J'en perds mon latin !
Y a-t-il une différence entre les deux qui m'aurait échappée ? 🤔
Le 25/11/2023 à 10h 05
J'admets que ça m'a fait tiquer également. J'ai fait une recherche pour lever le doute et le terme "encapsulage" existe bel et bien. Juste pas en informatique en fait.
Iroise29 Abonné
Le 25/11/2023 à 10h 43

Gilbert_Gosseyn

J'admets que ça m'a fait tiquer également. J'ai fait une recherche pour lever le doute et le terme "encapsulage" existe bel et bien. Juste pas en informatique en fait.
Ceux qui ont un peu de bouteille sauront faire la différence entre les deux termes 😊
Jean_G Abonné
Le 25/11/2023 à 10h 56

Gilbert_Gosseyn

J'admets que ça m'a fait tiquer également. J'ai fait une recherche pour lever le doute et le terme "encapsulage" existe bel et bien. Juste pas en informatique en fait.
Vous avez raison, mais à force de lire et traduire plusieurs sources, je me suis emmêlé les pinceaux. On corrige dès que les journées de 36 heures auront été inventées (c'est pour dire qu'avec le nouveau site, toute l'équipe est sous l'eau, y a un taf' énorme derrière et ils sont surchargés). C'est l'occasion de les encourager et les féliciter !
Jean_G Abonné
Le 27/11/2023 à 10h 01
Ayé, corrigé.
gg40 Abonné
Le 25/11/2023 à 12h 17
Merci @jean_G pour cette vulgarisation très bien faite !
Pseudooo Abonné
Le 25/11/2023 à 13h 11
Très bel article, esthétiquement d'abord sur le fond ensuite. Complété par les commentaires c'est top
Le 28/11/2023 à 09h 53
Et ça, vous en pensez quoi?
Encrypted Email Service Tuta Denies It's a 'Honeypot' for Five Eyes Intelligence
For years, Tutanota (which recently rebranded to "Tuta") has been a trusted email provider. A former Canadian cop has accused it of being a honeypot.

...