AWS Re:Invent 2019 - AWS CloudHSM

2eme session du Lundi : Cloud HSM.

Bien que le déploiement d’un cloud HSM est quelque chose que nous rencontrons pas tous les jours, cette session nous permettait de rencontrer 2 ingénieurs de la Crypto Team AWS, spécialistes du chiffrement, en charge du développement de leur service “Cloud HSM”.

Pour ceux qui utilisent AWS, vous avez très certainement manipulé des clés KMS. Celles-ci vous permettent de chiffrer vos données, qu'elles soient stockées dans une base RDS, sur un EBS ou encore un bucket S3. Quasiment tous les services d'AWS s'intégrent avec KMS (DynamoDB, ElasticSearch, etc ...)

CloudHSM est le service managé qui vous permet d'aller encore plus loin en terme de sécurité et répondre aux exigences fortes des entreprises dont les données sont classées “extrêmement confidentielles” ou pour les gouvernements, par exemple la norme FIPS 140-2 Level 3. A noter également qu’il s’agit d’une solution matérielle : vos clés sont générées sur des serveurs physiques (en opposition aux machines EC2 par exemple).

Un HSM (Hardware Security Module)  intervient pour faire du double chiffrement c’est-à-dire chiffrer les clés de chiffrement. C’est le cas si on souhaite l'intégrer avec AWS KMS par exemple.

Le cloud HSM permet de générer  (presque) tout type de clé de chiffrement. On peut parler de clés avec corum ou du SECP256K1 pour le blockchain. Nous ne nous attarderons pas sur ces cas spécifiques. Le but est ici plus de vous présenter ce service difficile d'approche mais aussi de  vous parler des nouveautées 2019 et 2020.

Il est également important de rappeler qu’un HSM dispose de clés matérielles par conséquent nous allons devoir démarrer des serveur physiques et pas de simples machines virtuelles. Comprenez par là que le prix d’entrée sera élevé.

Le double chiffrement est le dernier rempart si une personne malveillante a réussi à accéder à vos données. Cependant, afin de garder un esprit critique je tiens à préciser que l’utilisation d’un Cloud HSM avec KMS ne vous protège pas du redouté “Patriot Act”: à un moment KMS aura votre clé.

Que couvre le service Cloud HSM ?

• Le provisionning de votre cluster ;
• La Haute disponibilité de votre cluster HSM ;
• La maintenance du Cluster ;
• Les sauvegardes.
  

On parle ici de “Cluster”, car il faudra, pour répondre à toutes les exigences des standards de sécurité qu’HSM impose, au moins 2 noeuds qui s’échangent et propagent les clés ainsi que les commandes d’administration que vous lancez et tous les éléments nécessaires au bon fonctionnement.

Comme dans le “modèle de responsabilité”, AWS annonce à ses clients, qu’il sera de leur responsabilité de :

• Gérer les utilisateurs qui accèdent / génèrent des clés à l’intérieur de votre cluster
• d’intégrer la gestion des clés de votre cluster dans votre applicatif.
  

Notez que, pour répondre aux exigences de confidentialité nécessaires pour HSM, AWS ne peut pas “débugger à distance”. Une intégration avec CloudWatch est déjà en place et continue à s’étoffer afin de permettre aux utilisateurs de cloudHSM de comprendre les problématiques.

Concernant l’intégration avec votre applicatif, citons plusieurs standards supportés par cloudHSM :

• PKCS#11 (Cryptographic Token) ;
• OpenSSL ;
• JCE (Java Cryptography Extension).
  

Ci-joint quelques liens pour démarrer sur ces technologies :

https://github.com/aws-samples/aws-cloudhsm-pkcs11-examples

https://github.com/aws-samples/aws-cloudhsm-jce-examples

Interagir avec votre cluster

AWS fournit un toolkit permettant d’interagir avec votre cluster. Il fonctionne selon 2 modes :

• “global” : dans ce cas, les commandes sont propagées à l’intérieur de votre cluster à l’ensemble de vos noeuds. Attention, toutes les commandes ne peuvent pas etre lancées dans ce mode.
• “server” : dans ce cas, vous vous adressez directement à un noeud via son adresse IP. L’IP ne bougera pas et est attribuée au moment de la création du cluster. Il faudra donc penser à synchroniser vous même vos noeuds dans ce cas.
  

Cross Region Réplication

C’est une des fonctionnalités les plus bluffantes de cette offre. Pour des entreprises implantées à travers tout le globe, il est possible de répliquer vos clés à travers plusieurs régions AWS. La procédure est assez similaire pour une base RDS :

• copier le backup de votre cluster HSM dans la nouvelle région
• Créer un nouveau cluster dans cette région
• Synchroniser vos 2 clusters via des “Wrapped Keys” ou en le faisant “manuellement” avec vos scripts que vous aurez très certainement écrits !
  
  

Wrapped Keys vs Sync Keys

HSM vous permet de créer ces 2 types clés. Voici un récapitulatif entre ces types différents .

Wrapped Keys :

• A privilégier si vous devez générer de nombreuses clés ;
• Automatisation possible via du code (C ou Java) ;
• Si vous n’avez pas besoin de connectivité directe entre vos clusters (cas du multi région par exemple) ;
• Ne fonctionne pas pour certaines clés non exportables ;
• Pour utiliser une clé “wrappée”, vous devrez “unwrapper” son contenu. Il faudra prendre vos précautions dans votre code, pour restituer l’intégralité des “méta-données” inhérentes à cette clé, si vous souhaitez qu’elles soient identiques à l’arrivée.
  

Sync Keys :

• A utiliser si vous utilisez des clés non exportables ;
• Elle reste co-localisée à votre cluster HSM ;
• L’import d’une clé de ce type vous permettra d’avoir exactement la même “empreinte” entre 2 clusters (attributs, policies) ;
• La clé ne sera utilisable que sur un clone de votre cluster ;
• Pour l’instant, seul le binaire “cloudhsm_mgmt_util” (mode server uniquement) vous permet de les manipuler.
  

Les nouveautés

Les fonctionnalités implémentées sur l’année 2019 :

• Le “wrapping” pour les clés asymétriques lors des échanges de clés ;
• Compatibilité avec les outils standards de l’écosystème Java : jar signer, keystore et autres outils de “signature” équivalents ;
• Support de la norme Secp256k1 pour les applications block-chains ;
• Dérivation des clés générées via les clés matérielles type HMAC (attribut CKA_DERIVE) ;
• Support des fonctions lambdas ;
• Gestion des backups depuis la console Web.
  
  

Les nouveautés pour 2020 :

• Support pour la signature et l’encryption des clés KMS asymétriques via un custom key store ;
• Gestion des tags à la création et sur les backups et la gestion fine des droits d’accès aux ressources ;
• Gestion des attributs avancés de JCE.
  
  

Conclusion

Parce que l’architecture de votre sécurité peut être une barrière technique mettant à mal le succès de votre projet, rapprochez vous d’experts certifiés pour vous accompagner. Chez Ippon nous mettant en place la sécurité du Cloud chez nos clients. Des clients contraints au plus haut niveau de protection, avec des données de santé ou encore des données financières soumisent au norme RGPD, HDS ou bancaire.

Présent sur le Re:Invent 2019, @Samuel notre expert SecOps pourra répondre à vos questions. Vous pouvez également télécharger son dernier livre blanc La sécurité dans les nuages.https://fr.ippon.tech/la-securite-dans-les-nuages/