Key Management System (KMS) : une pierre angulaire du chiffrement

Qu’est-ce qu’un Key Management System ?

Un Key Management System est comme son nom l’indique un logiciel de gestion de clés de chiffrement. Plus particulièrement il a pour rôle de générer, d’échanger, d’importer, de stocker, d’utiliser, de détruire, et de remplacer les clés. Il permet également de gérer les certificats SSL/TLS. Il comprend des protocoles cryptographiques, des politiques de sécurité et de gestion ainsi que plusieurs composants techniques pour chiffrer/déchiffrer les données. Il est l’un des composants d’une infrastructure à clés publiques (Public Key Infrastructure – PKI). Un KMS peut également être trouvé sous la dénomination EKMS (Enterprise Key Management System) ou CKMS (Crypto Key Management System).

Le Key Management System a pour rôle de maintenir l’état des trousseaux de clés, les clés, authentifier des certificats et leurs différentes versions. Évidemment, les clés sont associées à plusieurs utilisateurs via une politique d’accès gérée très souvent par un IAM. Le KMS contient généralement un outil de recherche pour retrouver les clés et dispose de fonctionnalités de haute disponibilité, de sauvegarde, de restauration et des logs dédiés aux audits de sécurité.

Ce logiciel est embarqué sur un serveur « durci » ou une carte PCIe. Là, on peut commencer à parler de Hardware Security Module (HSM) ou boîte noire transactionnelle en français : il s’agit d’un système de traitement cryptographique sécurisé, embarquant un processeur spécialisé.
Les HSM répondent à différents standards de sécurité internationaux dont la norme de conformité FIPS 140-2, PCI DSS, certaines normes ISO, des critères communs type EAL4+ et des API comme KMIP (Key Management Interoperability Protocol), CryptoAPI, Java/JCE, PKSCS#11 et. Les HSM sont conçus eux aussi pour générer et stocker les clés de chiffrement.

De par les normes et les technologies employées, un HSM est réputé pour être particulièrement robuste face aux cyberattaques. En cas de problème, il aura tendance à détruire les clés et empêcher, en principe, l’accès aux données. De plus, la mise en place d’un quorum d’administrateurs permet de s’assurer qu’une personne seule ne puisse accéder aux secrets. Pour y accéder, il faudra réunir le quorum au complet. Les clés stockées sont elles-mêmes chiffrées par mesure de sécurité supplémentaire.

Comment fonctionne un KMS ?

Vous avez bien lu, le KMS et le HSM sont tous deux capables de générer des clés via des algorithmes AES, RSA, ECDSA ou encore ECC. Seulement le premier offre un chiffrement logiciel et le second matériel. L’implémentation matérielle permet non seulement d’obtenir des performances plus élevées sur l’exploitation d’algorithmes cryptographiques complexes, mais également de renforcer la sécurité des clés elles-mêmes contre d’éventuels indélicats. Un KMS peut jouer le rôle d’interface pour un HSM et ainsi offrir les deux formes de chiffrement.

En principe, Un KMS supporte autant le chiffrement symétrique – c’est-à-dire qu’une même clé servira pour chiffrer et déchiffrer le message – que le chiffrement asymétrique (chiffrement à clés publiques). Deux clés sont alors utilisées : une clé publique, permettant de chiffrer le message, et une clé privée, indispensable pour le déchiffrer. La première technique est davantage utilisée pour chiffrer des données au repos, tandis que la seconde est généralement utilisée pour le faire en transit.

Pour faire simple, un KMS est installé sur un HSM. Il gère des certificats d’autorité, des clés de chiffrements de données (Data Encryption Key – DEK) et des clés de chiffrements… de clés (Key Encryption Key – KEK ou parfois nommé clé racine). L’utilisateur qui souhaite accéder à des données chiffrées déclenche une requête de la base de données vers l’API du KMS pour retrouver une DEK.

Les certificats permettent à l’API et au KMS de s’identifier mutuellement. Si la demande est validée, une session TLS est démarrée, la KEK déchiffre la DEK, l’envoie à l’API via le flux TLS. L’API transmet la clé déchiffrée dans la base de données. De préférence, elle est stockée en cache dans une partie sécurisée de la mémoire vive associée.

Pour le chiffrement asymétrique, le cheminement est un peu différent. Le destinataire et l’émetteur créent deux clés, une privée et l’autre publique. Le destinataire partage sa clé publique après le passage des certificats. L’émetteur utilise la clé publique (DEK) pour chiffrer le fichier ou le message à envoyer. La clé privée du destinataire (KEK) lui permet de déchiffrer la clé publique et lire le message.

Une variante existe : le chiffrement encapsulé. Dans ce cadre, la clé publique dite enveloppe, protège une clé symétrique éphémère (DEK) qui chiffre le message. Cette enveloppe est générée à partir d’une KEK, une clé privée conservée dans l’environnement KSM – HSM, et un algorithme de type AES ou RSA. Dans ce scénario tout utilisateur ayant la clé publique peut chiffrer les données.

Key Management Service : la variante cloud

Un Key Management Service est une version managée dans le cloud d’un Key Management System. Ce logiciel est virtualisé et placé dans une instance distincte de celles des données à chiffrer. Il peut être associé à un HSM mutualisé ou dédié installé chez le cloudiste, ou permettre l’importation de clés générées depuis le HSM personnel d’une entreprise. C’est le principe du Bring Your Own Keys (BYOK).

Un KMS dépend lui aussi d’une API afin de gérer les clés de chiffrement pour les données en transit et au repos. Son interface repose sur un CLI proposé par le fournisseur de cloud. Ensuite, il dépend d’un périmètre de sécurité délimité par un VPC. Chaque fournisseur observe sa politique au regard du KMS. Il peut être un service proposé aux clients. Le fournisseur peut aussi utiliser un tel système pour protéger ses propres services sans en donner l’accès aux clients. Certains combinent les deux approches et décident ce que le client peut gérer lui-même.