Architecture DEK/KEK : structurer ses clés de chiffrement pour un audit

Qu'est-ce que l'architecture DEK/KEK ?

C'est un chiffrement à deux étages. Une clé de données chiffre la donnée, et une clé maîtresse chiffre cette clé de données. La donnée n'est jamais protégée directement par la clé maîtresse : elle l'est par une clé jetable, elle-même mise sous enveloppe. Ce découplage est la base de tout service de chiffrement sérieux, parce qu'il isole la clé la plus précieuse du flux courant.

La clé de données est une DEK, la clé maîtresse une KEK, et l'ensemble forme l'enveloppe cryptographique. Le NIST décrit ce modèle et le recommande pour concilier durée de vie des clés et durée de rétention des données, dans sa publication SP 800-57 Part 1 Révision 5 (NIST, Recommendation for Key Management). Une KEK longue durée enveloppe des DEK rotées fréquemment.

Pourquoi ne pas chiffrer directement avec la clé maîtresse ?

Parce que ce serait mettre tous les œufs dans le même panier. Si une seule clé chiffre toutes les données, sa rotation impose de re-chiffrer l'intégralité du corpus, et sa compromission expose tout. En interposant une clé de données par opération, on limite l'impact d'une fuite à une seule donnée, et on garde la clé maîtresse hors du flux de traitement, dans un module protégé.

Ce cloisonnement est aussi ce qui permet d'auditer proprement. Chaque usage de la KEK pour envelopper ou dérouler une DEK est un événement traçable. Le NIST insiste dans SP 800-57 sur le fait que la sécurité des données chiffrées ne dépasse jamais la protection accordée aux clés qui les protègent, ce qui justifie d'isoler la clé maîtresse dans un module dédié plutôt que de l'exposer à chaque opération.

Comment MAFATE implémente-t-il l'enveloppe cryptographique ?

En AES-256-GCM, avec une DEK aléatoire générée à chaque opération et enveloppée par une KEK conservée dans un module PKCS#11. Le texte en clair n'est jamais persisté. Chaque appel de chiffrement produit une donnée protégée et une DEK enveloppée, stockée avec elle, que seule la KEK peut dérouler au moment du déchiffrement.

L'AES-256 en mode GCM figure parmi les mécanismes recommandés par l'ANSSI dans son guide des mécanismes cryptographiques, version 3.00 du 20 mars 2026 (ANSSI, guide des mécanismes cryptographiques PG-083). Le mode AES-256-GCM assure à la fois la confidentialité et l'authenticité de la donnée. Le détail du fonctionnement est documenté côté intégration (documentation, comment ça marche).

Où la clé maîtresse est-elle conservée ?

Dans un module dédié qui ne la restitue jamais en clair. La KEK ne quitte pas le module : les DEK y entrent pour être enveloppées ou déroulées, et ressortent chiffrées. Ce principe, garder la clé maîtresse hors de la mémoire applicative, est ce qui distingue un vrai service de gestion de clés d'un simple stockage de secrets.

MAFATE conserve la KEK dans un HSM logiciel PKCS#11 aujourd'hui, avec une migration vers un HSM matériel FIPS 140-2 planifiée. Ce point est traité honnêtement, sans le présenter comme acquis, dans un autre article de ce dossier. La gestion du cycle de vie des clés, côté KMS, couvre la création, la rotation et la désactivation (documentation, concepts de clés).

Cette architecture répond-elle aux attentes d'un audit santé ?

Oui, sur la partie chiffrement et gestion des clés. L'enveloppe cryptographique est le schéma que la CNIL et le NIST décrivent comme état de l'art, et c'est celui qu'un auditeur ou un donneur d'ordre reconnaît. Elle ne remplace pas la certification de l'hébergement, qui relève de l'hébergeur au titre du référentiel publié par l'Agence du numérique en santé (ANS, certification HDS), mais elle documente la couche applicative dont l'éditeur est responsable.

La CNIL rappelle dans ses fiches de 2024 sur le chiffrement dans le cloud que la maîtrise des clés est le point qui détermine réellement l'accès du fournisseur à la donnée (CNIL, pratiques de chiffrement dans le cloud). Le RGPD Article 32, dans le règlement (UE) 2016/679 publié sur EUR-Lex, fonde l'obligation de mesures adaptées, dont le chiffrement fait partie.

Que retenir de l'architecture DEK/KEK ?

Qu'elle sépare la clé qui chiffre la donnée de la clé qui protège les clés, et que cette séparation est ce qui rend la rotation et l'audit possibles sans re-chiffrer tout l'historique. C'est le socle sur lequel reposent la rotation des clés et le journal d'audit, traités dans les articles suivants de ce dossier.

MAFATE fournit cette architecture par API, décrite sur la page solutions santé et sur la page de preuve sécurité. Cet article approfondit une section du pilier de ce dossier et complète l'article sur le chiffrement des champs sensibles. Pour cadrer votre architecture de clés, parlez à un ingénieur.