AWS KMS : y a t-il vraiment un intérêt à importer ses propres clés de chiffrement ?
Contenu
AWS KMS en quelques mots
AWS Key Management System est un service permettant de réaliser diverses opérations cryptographiques allant de la génération de clés de chiffrement à la gestion du cycle de vie desdites clés en passant par l’import de clés.
Dans AWS KMS, les principaux CSP (Critical Security Parameter) sont les clés principales client (CMK pour Customer Master Key). Celles-ci ne quittent jamais l’infrastructure KMS.
AWS KMS s’appuie sur une infrastructure de modules de sécurité matériels (HSM) hautement disponible et conforme à la norme américaine FIPS 140-2 (*).
Les CMK supportées par AWS KMS sont exclusivement d’une longueur de 256 bits. Les CMK peuvent consister en des clés symétriques ou asymétriques (**). L’algorithme utilisé avec les CMK est AES dans Galois Counter Mode (AES-GCM).
Le service AWS KMS est conçu de sorte à implémenter le chiffrement d’enveloppe.
Le chiffrement d’enveloppe
Une clé CMK ne peut chiffrer et déchiffrer plus de 4 Ko (4 096 octets) de données. Cette limitation est mise en œuvre justement pour restreindre l’usage des clés CMK à des opérations de chiffrement et déchiffrement des clés de données. Ces dernières sont utilisées en dehors de KMS pour (dé)chiffrer des données.
La pratique consistant à chiffrer une clé servant à chiffrer des données à l’aide d’une autre clé porte le nom de chiffrement d’enveloppe.
KMS envelop encryption overview
Les clés de données peuvent être générées en 128 bits ou en 256 bits. AWS KMS permet également de générer des données aléatoires d’une valeur arbitraire maximale de 1 024 bits comme on pourrait le faire avec la commande ‘openssl rand -base64’.
Bien qu’AWS KMS permette de générer des clés de données, le service KMS ne conserve aucune copie – chiffrée ou non – des clés de données.
Mais alors comment faire pour maintenir une correspondance entre des données chiffrées et la clé qui a servi à les chiffrer ? La réponse tient en un mot : les métadonnées. En deux mots, en fait.
Toute donnée chiffrée par le biais d’AWS KMS (API et SDK) se compose à minima de deux parties : l’entête (métadonnée) et le corps (donnée chiffrée ou ciphertext en anglais). C’est précisément au sein de l’entête qu’est stockée – entre autres – la clé de données chiffrée ainsi que l’identifiant unique (ARN) de la CMK sous laquelle la première a été chiffrée.
KMS encrypted message
Le BYOK, c’est quoi
Une pratique assez répandue consiste à importer ses propres clés de chiffrement dans la plate-forme de son hébergeur cloud. Cette pratique est nommée BYOK – vous l’aurez deviner – pour « Bring Your Own Key » ou encore BYOE pour « Bring Your Own Encryption ».
La démarche BYOK est la suivante : la clé est générée au sein d’un HSM privé avant d’être importée dans le service KMS/HSM de son fournisseur cloud. Enfin, la clé est utilisée depuis le KMS du CSP (Cloud Service Provider) pour des opérations cryptographiques dans ladite plate-forme cloud ou même ailleurs.
Les clés importées sont destinées à être associées à une CMK. Ces clés sont exclusivement symétriques et d’une longueur de 256 bits.
Afin de sécuriser l’importation, la clé doit être encapsulée par une clé publique fournie par AWS KMS via l’une des deux méthodes RSA PKCS#1. De sorte que la clé chiffrée ne puisse être déchiffrée que par le service AWS KMS.
Le BYOK est le plus souvent justifié pour ne pas dire imposé au sein des entreprises par des règles de conformité et de propriété (souveraineté) des clés. Mais cela apporte-t-il un gain quelconque en matière de sécurité ? Cela suffit-il à protéger ses données vis-à-vis d’un gouvernement qui en réclamerait l’accès ?
Clé interceptée, quelles conséquences ?
Si le fait d’avoir le contrôle sur la création de ladite clé peut donner l’impression d’avoir le contrôle total du cycle de vie de la clé, cette pratique présente néanmoins deux faiblesses :
- La présence de la clé dans (au moins) deux infrastructures distinctes
- La nécessité de sécuriser le transfert de la clé depuis le HSM privé jusqu’à sa livraison dans le cloud
|
Tout module HSM conforme à la norme FIPS 140-2 n’autorise aucun accès direct aux clés privées (type CMK entre autres) qu’elle renferme. Toutes les opérations cryptographiques ayant recours à ces clés privées sont de facto réalisées exclusivement à l’intérieur du module.
Ainsi, bien que les clés privées (CMK) ne sortent jamais d’un module HSM FIPS 140-2, l’import de clés dans ce type de module est possible. Cette pratique introduit une faille dans le cycle de vie de la clé du fait qu’une copie en texte clair de celle-ci existe en dehors du module.
Toutefois, dans le cas où une CMK importée dans AWS tomberait entre de mauvaises mains, celle-ci ne serait d’aucune utilité à l’usurpateur qui tenterait d’exfiltrer des données par le biais des API.
En effet, toutes les données stockées dans AWS (objets S3 par ex.) de même que les ressources AWS (volumes EBS par ex.) chiffrées selon la méthode server-side encryption avec KMS ne sont accessibles qu’à condition de disposer impérativement des permissions IAM autorisant à la fois l’usage de la CMK mais aussi l’accès à l’asset chiffré. Sans quoi la requête se soldera par une réponse HTTP 403 (AccessDenied).
Grace à leur intégration avec KMS, les services AWS réalisent eux-mêmes les opérations cryptographiques des assets avant de les mettre à disposition de l’utilisateur ou de les stocker dans le cadre du chiffrement au repos.
C’est pourquoi un attaquant détenant simplement une copie en texte clair d’une clé privée AWS KMS servant à chiffrer des objets S3 par exemple ne sera pas en mesure de déchiffrer ces objets par le biais des APIs.
Le BYOK pour une confidentialité à l’épreuve de la justice ?
Quand il est question de divulgation de données privées à des autorités gouvernementales, bien souvent le CLOUD Act est le premier texte de loi qui vient à l’esprit. Cette loi fédérale (US) promulguée le 23 mars 2018 par le Président Donald Trump a pour principal objectif de faciliter l’accès aux forces de l’ordre à des données hébergées hors du sol américain sur des serveurs appartenant à des entreprises basées aux USA.
Cet amendement trouve aussi ses origines dans la volonté du gouvernement des Etats-Unis de proposer une alternative au traité d’entraide international MLAT jugé trop lourd et pas assez rapide.
En faisant fi de la localisation des données, le CLOUD Act est considéré comme un motif sérieux justifiant telle ou telle pratique – dont le BYOK – visant à garantir la confidentialité des données.
Il existe principalement 3 raisons à cette hantise des injonctions des tribunaux et agences américaines :
- L’hégémonie des entreprises américaines dans les services cloud
- La médiatisation des affaires de divulgation et de déchiffrement de données ayant opposé ces institutions à des fournisseurs de services et constructeurs. Notamment celle opposant le gouvernement des États-Unis à Microsoft pour la divulgation d’e-mails stockés en Irlande dans le cadre d’une enquête portant sur un trafic de drogue (2013-2018). Citons aussi celle opposant le FBI à Apple pour le déchiffrement de l’iPhone de l’un des terroristes de la fusillade de San Bernardino (2015-2016).
- La possibilité pour des gouvernements d’accéder aux données hébergées par des entreprises américaines sous réserve d’avoir conclu un accord bilatéral avec l’exécutif américain au travers du CLOUD Act.
Pourtant la France, tout comme de nombreux autres pays dont certains de nos voisins européens, n’est pas en reste vis-à-vis des Etats-Unis concernant la saisie de données stockées en dehors de son territoire. L’article 57-1 du code de procédure pénale instaure depuis le 18 mars 2003 un cadre légal permettant aux forces de l’ordre et à la justice d’accéder à des données hébergées à l’étranger « sous réserve des conditions d’accès prévues par les engagements internationaux en vigueur ».
Si l’arsenal juridique français partage avec le CLOUD Act américain la faculté de perquisitionner des données stockées dans un système informatique situé en dehors du territoire national, il y a cependant des divergences entre les 2 systèmes pénaux notamment sur la question de l’accès à des données chiffrées.
Effectivement, comme le précise le ministère de la Justice US (DOJ) au travers d’un livre blanc ; le CLOUD Act est “encryption neutral”. Concrètement, le CLOUD Act n’exige pas le déchiffrement sans pour autant empêcher les gouvernements d’ordonner le déchiffrement dans la mesure autorisée par leurs lois.
En France, la question du déchiffrement est traitée au travers de l’article 434-15-2 du code pénal dont la première version remonte à 2001. Cet article impose la remise aux autorités judiciaires de clés de chiffrement d’un moyen de cryptologie à quiconque en ayant connaissance sous peine d’une amende pouvant atteindre les 450 000 € et d’une privation de liberté pouvant aller jusqu’à cinq ans d’emprisonnement.
Le mot de la fin
Bien que l’agence américaine NIST impose au travers des standards FIPS des prérequis qui limitent fortement le risque de compromission d’une clé cryptographique, ce risque demeure malgré tout. Ce risque est bien présent avec des clés importées dans un module HSM en passant par l’internet.
Néanmoins, chez un CSP comme AWS, ce risque est fortement mitigé par la sécurisation du transport de la clé et davantage par le système de permissions IAM. Comme on a pu le voir, l’accès à un asset chiffré n’est possible que si le client jouit à la fois de la permission d’accès à l’asset et de la permission de déchiffrement ayant recours à la CMK précédemment utilisée pour le chiffrement.
Sans accès direct aux systèmes de fichiers sous-jacent aux différents services (S3, EBS etc.), le fait de détenir une copie en clair d’une clé CMK n’offre aucun avantage à un attaquant qui essayerait d’exfiltrer des données depuis AWS.
Le BYOK n’apporte donc aucun avantage en cas de compromission de clés. Bien au contraire il en accroît le risque.
En vertu du CLOUD Act, un gouvernement peut dans la mesure où ses propres lois le permettent demander à un CSP de déchiffrer des données perquisitionnées. Par exemple, le Royaume-Uni qui a signé un accord exécutif selon le CLOUD Act avec les USA le 03 octobre 2019 pourrait donc obtenir d’un CSP américain des données stockées en dehors de son territoire et préalablement déchiffrées.
Le plus souvent, dans les affaires de divulgation de données (chiffrées ou non) stockées dans une plate-forme cloud, les injonctions et mandats sont adressés aux CSPs plutôt qu’au souscripteur. La personne physique ou morale titulaire des données n’est parfois même pas informée de la perquisition.
Par conséquent, le fournisseur de services qui, rappelons-le, dispose d’une copie de la clé de chiffrement devient un acteur majeur dans la protection des données de ses clients. Là non plus, le BYOK ne s’avère d’aucun intérêt.
Face à ce constat, seul le chiffrement client-side avec des clés inconnues de son CSP permet d’assurer un niveau de confidentialité théoriquement à l’épreuve de la justice. Pour l’instant…
* FIPS 140-2 « Federal Information Processing Standards ». Ensemble de normes FIPS 140 correspond aux normes de sécurité informatique établies par le National Institute of Standards & Technology (NIST) pour le gouvernement des États-Unis
** Les clés asymétriques ne sont actuellement disponibles que dans les régions suivantes : Virginie du Nord, Oregon, Sydney, Irlande et Tokyo (fevrier 2020).
