Normalement, pour chiffrer des données, un algorithme de chiffrement et une clef suffisent.
Mais dans la « vraie vie », les applications utilisent bien souvent plusieurs clefs. Parmi les plus connues il y a la Data Encryption Key ou DEK, et la Key Encryption Key ou KEK.
dans la « vraie vie » on utilise simultanément plusieurs clefs
La clef DEK ou « Data Encryption Key » ou encore « Clef de chiffrement des données » sert à chiffrer les données. Cette clef DEK doit être particulièrement robuste (aléatoire, de bonne taille) et bien protégée car elle donné l’accès aux données.
La clef KEK ou « Key Encryption Key » ou encore « Clef de chiffrement de clef » va servir à chiffrer la clef DEK et non pas les données elles-mêmes. En d’autres termes, les données à protéger sont chiffrées via la clef DEK, elle-même protégée par la clef KEK (Key Encryption Key).
Utiliser deux clefs renforce la sécurité des échanges tout en optimisant les traitements et calculs liés au chiffrement et déchiffrement.
Les clefs DEK et KEK peuvent être de type ou de taille différents et correspondre à des algorithmes de chiffrement pouvant aussi être très différents. Elle donnent ainsi plus de souplesse, et permet de de s’adapter au contexte d’utilisation et aux besoins de l’application. Voici 2 exemples pour bien comprendre.
Exemple 1 : données échangées via un email chiffré (PGP par exemple)
Dans le cas de PGP (Pretty Good Privacy), le contenu du message est chiffré via un algorithme symétrique comme AES, cette clef étant ensuite chiffrée via un algorithme asymétrique comme RSA.
- Phase de chiffrement du message (coté envoyeur)
Afin de chiffrer le message, une clef AES (cette clef c’est la DEK – Data Encryption Key) est générée de façon aléatoire par le programme. Cette clef est unique pour chaque message envoyé. Le chiffrement symétrique va donc porter sur le contenu du message (le corps du mail).
Ensuite, la clef DEK est elle-même chiffrée via la partie publique de la clef RSA du destinataire (cette clef RSA c’est la KEK – Key Encryption Key). Le chiffrement asymétrique va donc porter uniquement sur la DEK (et pas sur le message en entier).
- Phase de déchiffrement du message (coté destinataire)
Pour accéder au contenu du message, le destinataire devra d’abord déchiffrer la clef de chiffrement. Il va utiliser la partie privée de sa clef RSA (c’est la KEK – Key Encryption Key) pour déchiffrer et accéder à la clef qui a été utilisée pour chiffrer le message (c’est la DEK – Data Encryption Key). Il pourra ensuite accéder au contenu du message lui-même en le déchiffrant via la clef DEK obtenue précédemment.
Les puristes auront noté que j’ai passé sous silence la phase de vérification de la signature du message par le destinataire et autres petits détails hors contexte ici.
Exemple 2 : cas d’un conteneur chiffré sur un disque dur local (ou une clef USB)
Dans le cas de données stockées en local (par exemple un espace disque chiffré), l’utilisateur doit pouvoir se souvenir de la clef de chiffrement, car il devra la saisir à chaque fois qu’il souhaite accéder aux données, ou alors qu’il puisse changer cette clef.
- chiffrement de type « symétrique »
Dans le cas de données stockées en local, la DEK est systématiquement une clef associée à un algorithme de chiffrement de type « symétrique ». En effet, comme le volume de données peut être particulièrement important il est hors de question de faire du RSA (ou chiffrement asymétrique) sur plusieurs Mega ou Giga-octets de données !
Les données stockées sur disque sont donc chiffrées via un algorithme symétrique (AES par exemple). Le chiffrement et le déchiffrement des données sont effectués à la volée et de façon transparente pour l’utilisateur. La clef de chiffrement des données (la DEK) est elle-même sécurisée via une autre clef (la KEK).
Il n’est pas nécessaire d’envoyer cette clef de façon sécurisée (comme c’était le cas dans l’exemple de PGP). On peut donc envisager d’utiliser un algorithme symétrique pour la KEK. Le mot de passe que l’utilisateur devra saisir lors du premier accès aux données servira de « base » pour un chiffrement AES (évidemment après avoir subi « quelques transformations » via un PBKDF2 par exemple).
- chiffrement de type « asymétrique »
Il est aussi possible de sécuriser la clef DEK via un chiffrement asymétrique basé sur l’utilisation d’une bi-clef présente sur un dongle USB ou une carte à puce (dans ce cas l’entrée d’un code PIN sera nécessaire).
deux clefs pour plus de sécurité, de performance et de souplesse
L’utilisation de plusieurs clefs de chiffrement organisées en DEK et KEK nous offre les avantages suivantes :
- La clef DEK n’est jamais directement manipulée par l’utilisateur
elle peut donc être longue et complétement aléatoire (il n’est pas nécessaire qu’il s’en souvienne). Autre avantage, la clef n’est pas directement manipulée par l’utilisateur, il y a donc clairement moins de risques d’erreurs.
- Les clefs DEK et KEK peuvent être de natures différentes
il est donc possible de « mixer » les algorithmes entre eux en fonction du contexte de l’application et des contraintes de performance. L’utilisation du chiffrement asymétrique sera limitée au strict minimum car il est moins rapide qu’un algorithme symétrique et demande beaucoup de ressources et reste - La clef KEK peut être changée/renouvelée
car il n’est pas nécessaire de déchiffrer au préalable les données pour les chiffrer de nouveau (tout spécialement dans le cas de données stockées en local).
- Détruire la KEK permet de détruire indirectement les données
En effaçant de façon sécurisée la KEK, on va définitivement perdre l’accès à la clef DEK. Il ne sera donc plus possible d’accéder aux données qui étaient chiffrées avec la DEK. C’est ce que l’on appelle le « crypto-shredding » comme j’ai pu l’expliquer dans l’épisode 20 des 5mins du professeur.
n’hésitez pas à poser des questions !
vous avez des questions ? n'hésitez pas à les poser ! Une idée de sujet pour un futur épisode des 5 minutes du Professeur Audenard ? Je vous écoute !
A très bientôt,
Jean-François (aka Jeff) Audenard. @jeffman78 & @ProfAudenard - #JeSuisCharlie
Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens