Dans un précédent article, Eva vous parlait de Cloud de confiance et des différentes offres disponibles ou annoncées (surtout annoncées) pour le marché français en ce début 2022. Nous avions conclu cet article en évoquant Sovereign Keys, une solution “made-in Devoteam Revolve” pour protéger les données des clients AWS et offrir des garanties de souveraineté complémentaires à celles du fournisseur.

Nous proposons maintenant de discuter plus en détails la solution Sovereign Keys au fil de 4 nouveaux articles : pour commencer nous poserons le cadre et les différents éléments de contexte permettant de comprendre à quel besoin Sovereign Keys répond, puis nous ferons une première passe sur son principe de fonctionnement.

Sovereign Keys est disponible en version Open Source : GitHub Sovereign Keys

Dans un deuxième article, nous verrons comment marche vraiment Sovereign Keys. Nous irons au-delà des schémas très généralistes du premier article pour comprendre exactement quelles sont les garanties techniques et les faiblesses résiduelles de la solution.

Dans le troisième et le quatrième article de la série, nous nous concentrerons sur deux problèmes emblématiques inhérents à ce type de solution et nous comprendrons en quoi ce sont des limites indépassables plutôt que les faiblesses d’une solution particulière (???LE QUATRIÈME ARTICLE VA VOUS ÉTONNER !!???).

Disclaimer : cette série d’articles est destinée à un public au moins familier avec le vocabulaire spécifique des technologies de sécurité informatique. Si des termes comme chiffrement, signature, disponibilité, confidentialité, authentification […] vous sont étrangers dans ce contexte, cette série vous paraîtra sans doute abscon. Je suppose également que vous avez le vocabulaire des services d’infrastructure d’AWS (EC2, EBS, etc..).

Un mot sur le concept de souveraineté

Avant de plonger dans le vif du sujet, je trouve intéressant de rappeler que la souveraineté, dans le contexte du Cloud, se décline en deux grandes questions:

• Comment empêcher mon Cloud provider d’accéder à mes données ? Confidentialité.
• Comment éviter que mon Cloud provider puisse m’empêcher d’accéder à mes données ? Disponibilité.

Si la première question est abondamment discutée, la seconde est souvent complètement oubliée. Au fond, c’est assez étonnant : pour la plupart des entreprises, la perte totale d’accès à ses données est fondamentalement plus grave que la perte partielle de leur confidentialité.

Une explication possible est que nous acceptons plus facilement comme inéluctable le fait que confier nos données à un tiers lui permet techniquement de nous interdire d’y ré-accéder : rien de plus facile, il lui suffit de fermer notre souscription par exemple.

En outre, une perte de disponibilité est facile à détecter et prouver, tandis qu’une rupture de confidentialité semble plus difficile à détecter et encore plus à prouver.

À la fin, il semble que pour cet aspect “disponibilité” de la souveraineté, nous sommes enclins à faire confiance à nos lois pour nous protéger ; tandis que pour l’aspect “confidentialité”, non.

Est-ce à dire que si c’est inéluctable et détectable on accepte plus facilement de s’en remettre à la Loi pour nous protéger ? À méditer.

Sur le plan technique, la solution pour se prémunir d’une perte de disponibilité est triviale à concevoir (bien que souvent compliquée à mettre en pratique) : il faut disposer de copies de nos données hors de contrôle du tiers. Il n’y a aucune autre alternative.

Et comme Sovereign Keys est une solution tournée vers la protection de la Confidentialité des données, je ne discuterai pas plus de l’aspect Disponibilité dans la suite.

Rappel du contexte de Sovereign Keys

Avant de plonger dans les profondeurs du terrier du lapin blanc, rappelons la “big picture”.

Nous sommes dans un contexte AWS. Nous avons une instance EC2 qui traite de la donnée stockée sur un de ses volumes EBS. Nous posons comme un fait (à tort ou à raison, ce n’est pas la question) qu’AWS est techniquement capable de lire les données stockées sur les volumes EBS des instances EC2, même s’ils sont chiffrés par AWS KMS. Nous souhaitons, malgré ce fait, empêcher AWS d’accéder à nos données. Comment faire ? Est-ce même possible ?

À ce moment- là, on pense assez naturellement à un chiffrement complémentaire des données. En particulier, on pense à un chiffrement symétrique reposant sur AES256.

Mais comme nous devons traiter la donnée, il va bien falloir la déchiffrer et donc balader des clés de chiffrement.

De plus, on souhaite garder les possibilités d’automatisation qu’offre le Cloud ; il n’est donc pas question d’avoir à rentrer manuellement des clés, mots de passe ou autres secrets sur nos instances EC2. On souhaite que le chiffrement de nos données sur les volumes des instances soit le plus transparent possible.

AWS Key Management Service (KMS) est une solution qui répond aux besoins précédents, mais c’est une solution managée par AWS et il est évident qu’AWS est techniquement capable de déchiffrer les données protégées par AWS KMS, comme établie précédemment dans notre énoncé.

On en vient finalement à désirer une solution “comme” AWS KMS, mais qui ne soit pas managée par AWS. Alors, comment chiffrer un volume entier de manière transparente ?

Chiffrer un volume avec Sovereign Keys

Pour chiffrer la totalité d’un volume de données sur base d’AES256, pas besoin de réinventer la roue : sous Linux, on peut utiliser dm-crypt/LUKS ; sous Windows, on peut utiliser Bitlocker.

Dans les deux cas, une possibilité pour exploiter le mécanisme est de fournir une passphrase qui protège la clé de chiffrement du volume. Pour simplifier un peu la réflexion, je ne parlerai dans la suite que de LUKS/dm-crypt, dans un mode où nous fournissons directement la clé de chiffrement du volume même si ce n’est pas techniquement exact. De plus, je vais faire de gros abus de langage et toujours parler de “LUKS”, même quand techniquement il faudrait plutôt parler de “dm-crypt”.

Ainsi, Sovereign Keys est le système permettant de créer, protéger et distribuer de manière sécurisée ces fameuses clés de chiffrement de volume qui seront utilisées avec LUKS pour protéger des données sur un volume EBS.

À ce stade, on peut faire un premier schéma :

Pour l’instant, Sovereign Keys est une boîte noire dont nous verrons les rouages dans le prochain article. Elle fournit une clé de chiffrement à LUKS, le système de chiffrement de volume natif de Linux, via un agent spécifique que nous installons sur l’instance EC2 : l’agent SK.

On voit bien que LUKS permet de chiffrer à la volée les données au sein de l’instance EC2. Ainsi, /mnt/data est un point de montage tout à fait classique où l’on lit et écrit des données en clair comme si de rien n’était. LUKS fait un travail permanent de chiffrement/déchiffrement à la volée avec la clé qu’on lui a fourni : lorsque la donnée sort de l’instance pour être réellement écrite sur notre volume EBS, elle est donc chiffrée.

Du côté positif, ce système est totalement transparent pour les applications et services qui s’exécutent dans l’instance. Une fois le volume correctement monté avec LUKS, il n’y a pas une seule ligne de configuration ou de code applicatif à changer. C’est très élégant et très satisfaisant. De plus, l’instance ne dépend de Sovereign Keys qu’à son démarrage, pour récupérer sa clé. Une fois la clé de chiffrement récupérée et configurée par l’agent SK, LUKS vit sa vie et fait son travail sans avoir besoin de contacter la boîte noire” Sovereign Keys, et ce jusqu’au prochain redémarrage de l’instance EC2.

Du côté des limites, on peut signaler une légère surconsommation sur le CPU pour faire le chiffrement/déchiffrement à la volée : de l’ordre de 1% (ça dépend, bien entendu, du CPU, de la taille d’instance, etc…). Par ailleurs, on ne peut pas mettre cela en place pour le volume de l’OS dans un contexte AWS, seuls les volumes additionnels d’une instance peuvent profiter du mécanisme. Enfin, il faut surtout signaler le premier gros point d’attention sécurité : la RAM.

Premier point d’attention : la RAM

La mémoire vive des instances EC2, ou RAM, est un point de sécurité important à considérer pour notre sujet pour deux raisons.

Déjà, pour faire son travail de chiffrement/déchiffrement à la volée, LUKS doit bien stocker la clé de chiffrement quelque part. Comme n’importe quel software, il stocke cette clé en RAM. Par ailleurs, toutes les données que vont traiter vos applications vont être stockées en clair dans la RAM pour faire des calculs dessus.

Donc si on suppose qu’AWS peut facilement lire la RAM d’une instance EC2, c’est Game Over : ils peuvent récupérer la clé de chiffrement et les données. Hors, une instance EC2 est avant tout une Machine Virtuelle et AWS est administrateur de l’hyperviseur sous-jacent, donc la supposition sur la facilité de lecture de la RAM est complètement légitime.

Note: on suppose qu’on ne peut pas espionner directement le CPU

Alors que faire ? AWS propose deux solutions : Nitro et le chiffrement de la RAM.

Nitro, c’est le nom utilisé par AWS pour désigner son écosystème d’hypervision. C’est un écosystème alliant du hardware et du software spécifiquement créé par AWS pour optimiser leur Cloud. Un des points forts de Nitro, c’est qu’AWS a eu la bonne idée “d’oublier” d’implémenter les fonctionnalités permettant de lire la RAM des instances EC2.

Pour notre sujet, c’est un énorme progrès quand on compare à l’hyperviseur Xen qu’AWS utilisait avant ! Pour profiter de Nitro, il suffit en gros d’utiliser les types d’instance apparus fin 2017 et après, tels que les t3, m5, c5, etc… Pas d’inquiétude de se tromper, par défaut l’agent SK vérifie systématiquement que son instance EC2 hôte est bien basée sur Nitro.

Au cas où Nitro n’est pas considéré comme suffisant (Nitro n’empêche pas les attaques cold boot par exemple), AWS commence aussi à proposer le chiffrement automatique et transparent de la RAM. Le principe est simple : quand le CPU lit et écrit dans la RAM, il fait du chiffrement/déchiffrement à la volée à l’aide d’une clé éphémère générée au boot.

Un peu comme fait LUKS pour le volume de données, mais là c’est le CPU qui est conçu et construit pour faire ce travail avec la RAM de façon transparente et systématique. Comme pour LUKS, aucun besoin de changer les applications : le CPU fait le travail tout seul.

Les processeurs Graviton 2 et Graviton 3 d’AWS ont cette fonctionnalité systématiquement activée, de même que les derniers processeurs Intel, qui équipent les instances m6i/c6i/r6i.

Qu’est-ce que fait gagner Sovereign Keys ?

J’aimerais vous affirmer que Sovereign Keys, ou de manière générale le chiffrement tierce-partie, est la panacée technologique permettant d’assurer la confidentialité des données vis-à-vis du fournisseur Cloud. Mais j’ai pour principe de tenir un discours de vérité et cette série d’articles a entre autres pour but de démontrer qu’une telle solution miracle est inconcevable.

Dans les 2 derniers articles, je discuterai abondamment de deux faiblesses inévitables du chiffrement tierce-partie :

• L’interception de la clé en transit ;
• L’authentification de l’instance EC2.

Et Sovereign Keys ne fait pas exception, mais alors quelle utilité ?

Pour commencer, même si je ne peux pas dire que la récupération des données par le fournisseur est impossible, je peux quand même affirmer que ça la rend vraiment vachement plus difficile, voire impraticable ! C’est déjà ça. Ensuite, on a l’auditabilité.

Un des gros problème avec la Confidentialité dans le Cloud, c’est qu’il est très compliqué de détecter une compromission. Peut-être que quelqu’un a vu vos données, peut-être pas, qu’en savez-vous ? En théorie, on a bien des logs d’accès, mais ils sont générés par le fournisseur lui-même, on peut donc raisonnablement supposer qu’ils sont manipulables.

Et c’est ça que Sovereign Keys apporte : la traçabilité indépendante du fournisseur. 

Avec cette traçabilité indépendante vient la possibilité de prouver qu’un accès illicite a eu lieu avec un degré de confiance raisonnable en corrélant les logs de Sovereign Keys avec les logs côté client (par exemple, vérifier que chaque log Sovereign Keys correspond au démarrage de l’instance EC2).

La boîte noire Sovereign Keys est incontournable pour obtenir l’accès aux données. Les deux faiblesses évoquées précédemment ne changent rien à ce fait : il existe nécessairement une trace de l’accès du côté de la boîte noire. Il faut simplement s’assurer que ces traces sont mises à disposition des clients et qu’elles sont infalsifiables, y compris par AWS. Et il s’avère que c’est relativement “facile”.

Créer des logs infalsifiables : une recette

Lorsqu’on veut des traces infalsifiables, on veut en fait :

• Rendre impossible la modification de traces existantes ;
• Rendre impossible la création de fausses traces ;
• Rendre impossible d’empêcher la création des vraies traces ;
• Rendre impossible la suppression de vraies traces.

Chaque lecteur peut assez facilement se convaincre que j’ai listé de façon exhaustive les possibilités de manipulation des logs de n’importe quel système.

Signer ses traces

La signature électronique est sans doute l’application la plus féconde du chiffrement asymétrique. Ce n’est pas exagéré de dire que sans signature électronique, le Web tel qu’on le connaît aujourd’hui n’existerait pas (c’est la base de fonctionnement des certificats électroniques par exemple). Avec une signature électronique, on peut garantir 2 choses d’un coup :

• L’authenticité d’un document, c’est-à-dire le fait qu’il n’a pas été altéré depuis qu’il a été signé ;
• La non-répudiation d’un document, c’est-à-dire que la signature prouve que le détenteur de la clé de signature est bien l’émetteur du document car lui seul peut créer la signature.

En signant les traces de log Sovereign Keys, nous réglons donc deux points :

• une trace existante ne peut pas être modifiée, cela invaliderait de fait la signature ;
• on ne peut pas créer une fausse trace, le faussaire serait incapable de produire la signature.

Pour affirmer cela, on suppose évidemment que la clé privée permettant de créer les signatures n’est pas compromise, nous verrons cela dans le prochain article.

Numéroter ses traces

Une trace, signée ou pas, s’efface comme n’importe quel autre fichier ou document. On ne peut pas priver AWS de la possibilité technique d’effacer un objet dans S3, par contre on peut séquencer les traces.

En établissant un simple compteur, qui commence à 1 et qui s’incrémente d’exactement 1 à chaque appel reçu par la boite noire Sovereign Keys, un client de Sovereign Keys peut tout simplement vérifier qu’il n’y a pas de “trou” dans la séquence. Si un trou apparaît, c’est le signe qu’une trace est manquante. Comme les traces sont aussi signées, AWS ne peut pas produire une fausse trace pour combler le trou ou modifier une trace compromettante.

Un simple compteur permet de s’assurer qu’il est trivial de détecter une disparition de trace.

Envoyer la trace avant la réponse

On pourrait imaginer la situation suivante: la boite noire Sovereign Keys envoie une clé de chiffrement à la suite d’un appel d’une instance EC2 d’un client légitime puis, dans la microseconde suivante, une défaillance matérielle empêche l’émission de la trace ou la mise à jour du compteur. On se retrouve alors dans une situation fâcheuse : comment distinguer un accident de ce genre (et ça peut arriver !) et une manipulation de la part du provider ?

Pour Sovereign Keys, nous avons choisi une solution simple : l’envoi de la trace, la mise à jour du compteur et la transmission de la réponse sont faits séquentiellement, dans cet ordre. Autrement dit, un accident peut mener à l’émission d’une trace alors qu’il n’y a pas réellement eu transmission de clé. Mais l’inverse est tout simplement impossible. Un accident peut éventuellement mener à un doublon (deux logs avec le même indice) et dans ce cas seul le log le plus récent (ils sont datés) correspond réellement à une transmission de clé. Mais un accident ne peut pas mener à sauter un indice.

Par conséquent, si on observe un trou dans les logs, c’est forcément une manipulation. En configurant le bucket recevant les traces avec une feature comme Object Lock par exemple, on peut même prouver que c’est une manipulation qui vient forcément d’AWS (Object Lock rend impossible la suppression de fichiers dans S3, volontairement ou non, par qui que ce soit d’autre).

Au final…

Au final, Sovereign Keys permet de rendre impraticable l’extraction des données par AWS. Je démontrerai dans la suite qu’il reste forcément des faiblesses exploitables, mais au moins elles sont détectables et leur exploitation est démontrable.

Dans ce cas, la possibilité d’une compromission de la Confidentialité par le fournisseur Cloud devient inéluctable et détectable, comme pour la Disponibilité. Est-ce que ça ne devrait pas faire remonter notre niveau de confiance en la protection apportée par la Loi ?

Dans le prochain article (disponible ici), nous plongerons dans une description beaucoup plus avancée du fonctionnement de la “boite noire” Sovereign Keys. Mes amis nerds seront comblés.