Contexte et enjeux
Le chiffrement au repos constitue aujourd’hui un pilier fondamental de la protection des données sensibles, en particulier dans les systèmes manipulant des documents critiques, des données financières ou des informations à forte valeur réglementaire. Dans ces architectures, la sécurité ne repose pas uniquement sur les algorithmes de chiffrement utilisés, mais également sur la manière dont les clés sont générées, échangées, protégées et stockées.
Modèle de chiffrement au repos : hiérarchie DEK / KEK
Notre mécanisme de chiffrement au repos s’appuie sur une hiérarchie de clés, qui permet de limiter l’impact d’une compromission, de faciliter la rotation des clés et de garantir la confidentialité des données sur le long terme.
Ce modèle repose sur deux niveaux principaux :
- DEK (Data Encryption Key) : clé symétrique utilisée pour chiffrer les données
- KEK (Key Encryption Key) : clé symétrique utilisée pour protéger la DEK
Le diagramme de séquence ci-dessous décrit le cycle complet de chiffrement d’un fichier, depuis sa réception jusqu’à son stockage sécurisé, en s’appuyant sur une hiérarchie de clés DEK/KEK et sur un HSM.
Le processus débute côté serveur par la génération d’une KEK (Key Encryption Key). Cette clé, destinée exclusivement à protéger d’autres clés, est immédiatement externalisée et stockée dans un HSM (Hardware Security Module) via un keystore sécurisé. À ce stade, la KEK n’est jamais exposée en clair en dehors du périmètre sécurisé du HSM.
Ensuite, lorsqu’un utilisateur envoie un fichier au serveur, celui-ci déclenche la génération d’une DEK (Data Encryption Key). Cette clé symétrique est utilisée localement pour chiffrer le fichier. Le chiffrement des données est donc réalisé côté serveur, généralement avec un algorithme symétrique performant (ex : AES).
Une fois le fichier chiffré, la DEK elle-même doit être protégée. Pour cela, le serveur transmet la DEK au HSM afin qu’elle soit chiffrée à l’aide de la KEK précédemment générée. Cette opération est critique :
- La DEK est envoyée pour chiffrement,
- La KEK reste strictement confinée dans le HSM,
- Aucune clé sensible n’est exposée en clair à l’extérieur du module sécurisé.
Le HSM retourne ensuite au serveur la DEK chiffrée.
Enfin, le serveur procède au stockage :
- Du fichier chiffré avec la DEK,
- De la DEK chiffrée avec la KEK.
Ce modèle garantit que :
- Les données ne sont jamais stockées en clair,
- La clé de chiffrement des données (DEK) est elle-même protégée,
- La clé racine (KEK) reste isolée dans un environnement hautement sécurisé.
La figure ci-dessus illustre la relation entre le serveur applicatif et le HSM, ainsi que le canal de communication sécurisé utilisé entre ces deux composants. Les échanges transitent via une connexion TLS, garantissant la confidentialité et l’intégrité des données en transit.
Dans ce contexte, la DEK, qui est une clé symétrique utilisée pour chiffrer les données, doit être transmise au HSM afin d’être protégée (chiffrée) par la KEK. Cette opération repose généralement sur un mécanisme d’enveloppe cryptographique (key wrapping), utilisant des primitives asymétriques ou des mécanismes internes au HSM.
Le schéma met également en évidence un scénario d’attaque de type MITM (Man-In-The-Middle), dans lequel un attaquant intercepte les communications réseau entre le serveur applicatif et le HSM. Dans un tel cas, l’attaquant peut capturer les échanges chiffrés, y compris la KEK et la DEK en transit.
Aujourd’hui, la sécurité de ce modèle repose sur la robustesse des algorithmes asymétriques utilisés dans TLS (tels que RSA ou ECC). En pratique, même avec des moyens de calcul classiques extrêmement puissants, il est considéré comme (computationally infeasible) de casser des clés de taille standard (RSA 2048 bits ou ECC 256 bits).
Dans un modèle purement théorique, si un attaquant tentait de déchiffrer cette clé capturée en s’appuyant sur les algorithmes mathématiques connus à ce jour, notamment ceux exploitant la factorisation ou le logarithme discret, le temps requis serait prohibitif. En l’absence de rupture algorithmique, la complexité de ces problèmes rend leur résolution pratiquement impossible avec des moyens classiques.
À titre d’ordre de grandeur, casser une clé RSA 2048 bits ou une clé basée sur ECC 256 bits nécessiterait un temps de calcul largement supérieur à l’âge de l’univers avec les capacités de calcul actuelles. Même en mobilisant des ressources de calcul massives et distribuées, le coût computationnel reste hors de portée.
Concernant l’algorithme de Shor, bien qu’il offre en théorie une complexité polynomiale pour ces problèmes, son exécution reste conditionnée à des prérequis physiques et computationnels extrêmement contraignants. En pratique, sans entrer dans la question des architectures matérielles, il n’existe aujourd’hui aucun moyen opérationnel permettant de réduire ce temps de calcul à une échelle exploitable.
Cependant, ce niveau de sécurité repose sur une hypothèse fondamentale : l’absence d’ordinateurs quantiques à grande échelle. En théorie, un ordinateur quantique suffisamment avancé pourrait exploiter des algorithmes comme l’algorithme de Shor pour factoriser rapidement les grands entiers ou résoudre le problème du logarithme discret, compromettant ainsi les mécanismes de chiffrement asymétrique actuels.
Problématique : sécurisation des échanges de clés
Dans cette architecture, deux flux critiques apparaissent :
- Envoi au début de la KEK au HSM
- Échange de la DEK entre le serveur et le HSM
Même si ces échanges sont protégés par TLS, ils reposent aujourd’hui sur des mécanismes asymétriques classiques (ECDHE, RSA), qui sont vulnérables à des attaques quantiques à moyen terme.
Le principal risque est celui du scénario HNDL (Harvest Now, Decrypt Later) :
- Un attaquant intercepte aujourd’hui les échanges
- Il les stocke
- Il les déchiffre dans le futur avec un ordinateur quantique
Dans ce cas, la confidentialité des KEK/DEK échangées est compromise, ce qui entraîne mécaniquement la compromission des données chiffrées.
Recommandations de l’ANSSI
La FAQ publiée en octobre 2025 par l’ANSSI recommande explicitement d’inventorier l’ensemble des usages cryptographiques afin d’anticiper la transition vers la cryptographie post-quantique. Elle souligne également qu’à l’horizon 2030, l’acquisition de solutions n’intégrant pas de mécanismes résistants au quantique ne pourra plus être considérée comme raisonnable.
Dans ce contexte, la prise en compte du risque quantique ne doit pas être traitée comme une évolution isolée, mais intégrée dès aujourd’hui dans les cycles de conception et de renouvellement des systèmes d’information.
Contrainte actuelle des HSM
Un point structurant de cette problématique réside dans les limitations actuelles des solutions de gestion de clés, qu’il s’agisse de HSM.
À ce jour, les solutions HSM du marché ne proposent pas encore de support opérationnel, standardisé et largement déployé pour les mécanismes d’échange de clés post-quantiques ou hybrides, et continuent de s’appuyer principalement sur des primitives asymétriques classiques telles que RSA ou ECDH.
Cette contrainte impose une limitation importante : même si l’application est capable d’intégrer des mécanismes post-quantiques, le canal d’échange avec le HSM reste dépendant d’une cryptographie classique vulnérable à long terme.
En conséquence, la sécurisation des échanges DEK/KEK ne peut pas être entièrement déléguée aux HSM dans leur état actuel, ce qui nécessite l’introduction d’un mécanisme intermédiaire capable de porter cette évolution.
Il est raisonnable d’anticiper que ces limitations seront progressivement levées à mesure que les fournisseurs intègreront des mécanismes post-quantiques, mais cette transition prendra du temps et dépendra des cycles industriels.
Approche proposée : introduction d’un CryptoProxy et X-Wing
Afin de renforcer la sécurité des échanges de clés, nous introduisons un composant intermédiaire appelé CryptoProxy, positionné entre le serveur applicatif et le HSM qui est capable d’encapsuler et décapsuler une clé avec X-Wing.
Architecture cible
Dans ce modèle :
- Le serveur applicatif ne communique plus directement avec le HSM
- Le CryptoProxy devient le point de terminaison cryptographique
- Le CryptoProxy s’installe dans un réseau interne avec le HSM
- Le CryptoProxy et le HSM restent isolés dans une zone hautement sécurisée
- Le CryptoProxy sécurise le transport de la KEK et de la DEK
Pour cela, nous renforçons le mécanisme classique d’échange de clés par un KEM hybride.
Diagramme de scénario
Alignement avec les recommandations
Ce design s’aligne avec :
- Les recommandations de l’ANSSI
- Les travaux du NIST
- Les drafts de l’IETF sur les mécanismes hybrides (X-Wing)
Il concilie :
- Sécurité immédiate (cryptographie classique)
- Résilience long terme (post-quantique)
Il nous fait gagner :
- Aucune exposition directe du HSM
- Alignement avec les exigences post-quantiques
- Protection des données archivées
Conclusion
La sécurisation du chiffrement au repos ne peut plus se limiter à la protection des données elles-mêmes. Dans les architectures reposant sur une hiérarchie DEK/KEK et sur des HSM, le point critique réside désormais dans la sécurisation des flux de clés, en particulier face au risque Harvest Now, Decrypt Later.
Dans l’état actuel du marché, les HSM ne proposent pas encore de support opérationnel pour des mécanismes d’échange de clés post-quantiques ou hybrides. En conséquence, même si les données sont protégées par des primitives robustes, les échanges de clés restent exposés à des attaques différées exploitant des capacités quantiques futures.
L’introduction d’un CryptoProxy, combiné à un mécanisme d’encapsulation hybride de type X-Wing, permet de réduire significativement cette surface d’exposition. Cette approche apporte une protection immédiate des flux de clés les plus exposés, tout en conservant la compatibilité avec les infrastructures existantes.
Il convient néanmoins de souligner que cette architecture ne constitue pas une solution post-quantique complète de bout en bout. Le HSM et les mécanismes internes de gestion de clés restent fondés sur des primitives classiques, et doivent évoluer à terme pour garantir une sécurité pleinement résistante au quantique.
Cette approche doit donc être comprise comme une stratégie de transition pragmatique, permettant d’anticiper les menaces futures sans attendre la maturité complète des solutions post-quantiques dans les équipements matériels de sécurité.
Elle s’inscrit dans une logique d’évolution progressive des systèmes d’information, en alignement avec les recommandations des organismes de référence, et constitue une étape structurante vers une sécurité cryptographique durable.
***
À propos de l’auteur :
Abdelmjid EL KIHEL, Développeur senior chez LetReco
Développeur senior spécialisé dans les systèmes sécurisés et les applications critiques, fort de plus de 15 ans d’expérience. Chez LetReco, je contribue au développement de solutions SaaS de confiance, avec une attention particulière portée à la sécurité, à la fiabilité et à la performance.
Articles sur le même thème :
