Les rouages de Geo Key Manager v2 : réinventer le contrôle d'accès pour les systèmes distribués

En décembre 2022, nous avons annoncé la bêta fermée de la nouvelle version de Geo Key Manager. Geo Key Manager v2 (GeoV2) est la prochaine étape de notre parcours visant à fournir à nos clients une manière sûre et flexible de contrôler la diffusion de leurs clés privées en fonction de la localisation géographique. Notre système original, Geo Key Manager v1, a été lancé sous la forme d'un projet de recherche en 2017, mais à mesure que les besoins des clients ont évolué et que notre étendue a progressé, nous avons pris conscience que nous devions apporter des améliorations considérables pour proposer une meilleure expérience utilisateur.

L'un des principaux défis auxquels nous avons été confrontés avec Geo Key Manager v1 (GeoV1) était le manque de flexibilité de nos politiques de contrôle d'accès. Les clients avaient besoin de fonctionnalités plus riches de localisation des données, ce besoin étant souvent motivé par des préoccupations d'ordre réglementaire. Au niveau interne, des événements tels que le conflit en Ukraine ont renforcé la nécessité de pouvoir restreindre rapidement l'accès à des documents sensibles essentiels. La cryptographie sous-jacente de Geo Key Manager v1 reposait sur l'association des méthodes Identity-Based Broadcast Encryption (IBBE, chiffrement de la diffusion fondé sur l'identité) et Identity-Based Revocation (IBR, révocation fondée sur l'identité), simulant un sous-ensemble de la fonctionnalité offerte par la méthode Attribute-Based Encryption (ABE, chiffrement par attributs). Le remplacement de cette approche par un schéma ABE établi a permis de résoudre le manque de flexibilité de nos politiques de contrôle d'accès et a fourni une fondation plus sûre pour notre système.

Contrairement à notre schéma précédent, qui limitait la flexibilité future en figeant dès le commencement l'ensemble impliqué de datacenters et de politiques, l'utilisation d'ABE a rendu le système facilement adaptable aux besoins futurs. Cette approche nous a permis de tirer parti des gains de performance résultant de l'ajout de datacentrers supplémentaires après l'instanciation et a considérablement simplifié le traitement des modifications apportées aux attributs et aux politiques. En outre, GeoV1 se heurtait à des problèmes de performance difficilement explicables, qui contribuaient à une latence récurrente élevée et à un processus manuel de renouvellement des clés particulièrement fastidieux. GeoV2 est notre réponse à ces défis et aux limites de GeoV1.

Bien que cet article de blog se concentre sur notre solution de gestion géographique des clés, les enseignements présentés ici peuvent également être appliqués à d'autres besoins de contrôle d'accès. La mise en œuvre des solutions de contrôle d'accès repose traditionnellement sur l'utilisation d'une autorité centrale à haute disponibilité, afin de contrôler l'accès aux ressources. Comme nous allons le voir, ABE nous permet d'éviter ce point de défaillance unique. Puisqu'il n'existe pas, à notre connaissance, de système de contrôle d'accès à grande échelle fondé sur ABE, nous espérons que notre discussion pourra aider les ingénieurs à envisager l'utilisation d'ABE comme une alternative au contrôle d'accès, avec un recours minimal à une autorité centralisée. Pour faciliter cette approche, nous avons inclus notre implémentation d'ABE dans CIRCL, notre bibliothèque cryptographique open source.

Des tentatives insatisfaisantes d'élaboration d'une solution

Avant de revenir à GeoV2, faisons un petit détour et examinons le problème que nous essayons de résoudre.

Prenons l'exemple suivant : une grande banque européenne souhaite stocker ses clés privées TLS uniquement au sein de l'UE. Cette banque est cliente de Cloudflare, ce qui signifie que nous effectuons des négociations TLS en son nom. La raison pour laquelle nous devons terminer la connexion TLS en son nom est que cela nous permet d'offrir la meilleure protection contre les attaques DDoS, d'améliorer les performances grâce à la mise en cache, de prendre en charge les pare-feu d'applications web, etc.

Pour terminer la connexion TLS, nous devons avoir accès à ses clés privées TLS¹. Le plan de contrôle, qui gère le trafic de l'API, chiffre la clé privée transférée par le client avec une clé publique principale, partagée par toutes les machines, dans le monde entier. Il place ensuite la clé dans Quicksilver, un référentiel clés-valeurs décentralisé au niveau mondial. Cela signifie que chaque machine dans chaque datacenter dans le monde possède une copie locale de la clé privée TLS de ce client. Par conséquent, chaque machine dans chaque datacenter possède une copie de la clé privée de chaque client.

Toutefois, cette banque souhaite que sa clé soit stockée uniquement dans les datacenters de l'UE. Pour satisfaire cette demande, nous disposons de trois possibilités.

La première possibilité consiste à nous assurer que seuls les datacenters présents au sein de l'UE peuvent recevoir cette clé et terminer la négociation. Toutes les autres machines transmettent en proxy les requêtes TLS à un serveur au sein de l'UE, aux fins du traitement. Cela nécessiterait de ne fournir à chaque machine qu'un sous-ensemble de l'ensemble des clés stockées dans Quicksilver ; or, cela va à l'encontre de décisions fondamentales concernant l'architecture de Cloudflare, prises au fil des ans, qui supposent que l'ensemble des données est répliqué sur chaque machine.

Une autre possibilité consiste à stocker les clés dans le datacenter principal, plutôt que dans Quicksilver. Cette approche nous permettrait d'appliquer à chaque fois la politique de contrôle d'accès adéquate, en nous assurant que seules certaines machines puissent accéder à certaines clés. Toutefois, elle irait à l'encontre de l'objectif premier de l'exploitation d'un réseau mondial : réduire la latence et éviter un point de défaillance unique dans le datacenter principal.

Une troisième possibilité consiste à utiliser le chiffrement par clé publique. À la place d'une paire de clés principales, chaque datacenter reçoit une paire de clés spécifique. Le datacenter principal chiffre la clé privée du client avec les clés de chaque datacenter autorisé à l'utiliser. Dans cet exemple, seules les machines situées au sein de l'UE peuvent accéder à la clé. Supposons qu'il y ait 500 datacenters, contenant chacun 50 machines. Sur ces 500 datacenters, supposons que 200 se trouvent au sein de l'UE. Si 100 clés de 1 ko consommaient un total de 100 x 500 x 50 x 1 ko (au niveau mondial), elles consommeront désormais 200 fois ce volume et, dans le pire des cas, jusqu'à 500 fois ce volume. Cette approche introduit un facteur entièrement nouveau, entraînant une augmentation considérable de l'espace nécessaire au stockage des clés sur chaque machine : auparavant, l'espace de stockage était purement fonction du nombre de clés de clients enregistrées ; il est désormais toujours fonction du nombre de clés de clients, toutefois également multiplié par le nombre de datacenters.

Malheureusement, ces trois options sont toutes indésirables, à leur manière. Elles nécessiteraient soit de modifier les postulats fondamentaux que nous avons effectués concernant l'architecture de Cloudflare, soit de renoncer aux avantages de l'utilisation d'un réseau fortement distribué, soit d'augmenter de façon quadratique le stockage consommé par cette fonctionnalité.

Un examen plus approfondi de la troisième option révèle cette possibilité : pourquoi ne pas créer deux paires de clés, au lieu d'une paire unique pour chaque datacenter ? Une paire serait commune à tous les datacenters au sein de l'UE, et une autre paire à tous les datacenters situés situés hors de l'UE. De cette façon, le datacenter principal n'a besoin de chiffrer la clé du client que deux fois, au lieu de la chiffrer pour chaque datacenter au sein de l'UE. C'est une solution pertinente pour la banque de l'UE, mais elle ne se montre pas évolutive si l'on commence à ajouter des politiques supplémentaires. Prenons l'exemple suivant : un datacenter situé à New York pourrait disposer d'une clé pour la politique « country: US », d'une autre clé pour la politique « country: US or region: EU », d'une clé encore pour la politique « not country: RU », et ainsi de suite. Comme vous pouvez déjà le voir, tout cela devient assez fastidieux, et à chaque provisionnement d'un nouveau datacenter, toutes les politiques doivent être réévaluées et les clés appropriées doivent être attribuées.

Geo Key Manager v1 : chiffrement fondé sur l'identité et chiffrement de diffusion

L'invention du chiffrement RSA en 1978 a inauguré l'ère de la cryptographie à clé publique moderne ; toutefois, toute personne ayant utilisé GPG ou étant impliquée dans la gestion d'autorités de certification peut attester de la difficulté que comporte la gestion de l'infrastructure à clé publique qui relie les clés aux identités des utilisateurs. En 1984, Shamir a demandé s'il était possible de créer un système de chiffrement à clé publique dans lequel la clé publique pouvait être une chaîne de tout type. Cette question était motivée par la volonté de simplifier la gestion des e-mails. Au lieu de chiffrer un e-mail adressé à Bob avec la clé publique de Bob, Alice pourrait le chiffrer en fonction de l'identité de Bob, [email protected]. Enfin, en 2001, Boneh et Franklin ont trouvé une solution à ce problème.

Le chiffrement de diffusion (« Broadcast Encryption ») a été proposé pour la première fois en 1993, par Fiat et Naor. Il permet d'envoyer à tous les utilisateurs un même message chiffré, que seuls les utilisateurs possédant la clé correspondante peuvent déchiffrer. Pour reprendre la troisième possibilité que nous avons évoquée plus haut, au lieu d'envelopper la clé du client avec la clé de chaque datacenter situé au sein de l'UE, nous pourrions utiliser le chiffrement par diffusion pour générer un chiffrement unique de la clé du client, que seuls les datacenters situés au sein de l'UE pourraient déchiffrer. Cela résoudrait le problème lié au stockage.

Geo Key Manager v1 recourait conjointement aux méthodes Identity-Based Broadcast Encryption (IBBE, chiffrement de la diffusion fondé sur l'identité) et Identity-Based Revocation (IBR, révocation fondée sur l'identité) pour mettre en œuvre le contrôle d'accès. Succinctement, un ensemble d'identités est désigné pour chaque région et chaque emplacement de datacenter. Ensuite, chaque machine reçoit une clé privée fondée sur l'identité, correspondant à sa région et son emplacement. Une fois ce principe mis en place, trois ensembles permettent de contrôler l'accès à la clé du client : l'ensemble des régions pour lesquelles le chiffrement doit être mis en œuvre, l'ensemble des endroits à exclure dans la région et l'ensemble des endroits à inclure en dehors de la région. Par exemple, la clé du client peut être chiffrée de manière à être disponible dans toutes les régions, excepté dans quelques endroits spécifiques, ainsi que dans quelques endroits situés hors de ces régions. Cet article de blog propose un examen très détaillé de cette approche.

Malheureusement, ce schéma ne permettait pas de répondre aux besoins des clients ; les paramètres utilisés lors de la configuration initiale du chiffrement, tels que la liste des régions, des datacenters et de leurs attributs, étaient intégrés au système et ne pouvaient pas être facilement modifiés. Il était donc impossible d'exclure le Royaume-Uni de la région de l'UE après le Brexit ou de prendre en charge une nouvelle région en raison de l'application, par les clients, d'une nouvelle norme relative à la conformité. L'utilisation d'une liste statique prédéterminée d'endroits rendait également difficile la révocation rapide de l'accès de machines. Par ailleurs, les clés de déchiffrement ne pouvaient pas être attribuées aux nouveaux datacenters provisionnés après la configuration, ce qui les empêchait d'accélérer le traitement des requêtes. Ces limitations ont été à l'origine de l'intégration de la méthode Attribute-Based Encryption (ABE) dans Geo Key Manager.

Chiffrement par attributs

En 2004, Amit Sahai et Brent Waters ont proposé un nouveau système de chiffrement fondé sur des politiques d'accès, appelé Attribute-Based Encryption (ABE, chiffrement par attributs). Fondamentalement, un message est chiffré en fonction d'une politique d'accès, plutôt qu'en fonction d'une identité. Une clé privée est attribuée aux utilisateurs en fonction de leurs attributs, et ils ne peuvent déchiffrer le message que si leurs attributs sont conformes à la politique. Cette approche permet un contrôle d'accès plus flexible et précis que les méthodes de chiffrement traditionnelles.

La politique peut être liée soit à la clé, soit au message chiffré, ce qui produit deux variantes d'ABE : le chiffrement par attributs de politiques d'accès sur la clé (« Key-policy Attribute-based Encryption », KP-ABE) et le chiffrement par attributs de politiques d'accès sur le message chiffré (« Ciphertext-policy Attribute-based Encryption », CP-ABE). Il existe des compromis entre ces deux variantes, mais elles sont fonctionnellement équivalentes, puisqu'elles sont duales l'une de l'autre. Concentrons-nous sur le chiffrement CP-ABE, qui correspond davantage au contrôle d'accès mis en œuvre dans le monde réel. Imaginons un hôpital dans lequel un médecin possède les attributs « role: doctor » et « region: US », tandis qu'une infirmière possède les attributs « role: nurse » et « region: EU ». Un document chiffré conformément à la politique « role: doctor or region: EU » peut être déchiffré à la fois par le médecin (« doctor ») et l'infirmière (« nurse »). En d'autres termes, la méthode ABE s'apparente à une serrure magique, qui s'ouvre uniquement pour les personnes possédant les attributs demandés.

Il existe de nombreux schémas ABE différents, possédant différentes propriétés. Le schéma que nous choisissons doit satisfaire à certaines exigences :

1. Négation Nous voulons prendre en charge les formules booléennes constituées de AND, OR et NOT, c'est-à-dire les formulées booléennes non monotones. Si la quasi-totalité des schémas permettent de traiter AND et OR, la prise en charge de NOT est plus rare. La négation facilite la création de listes de blocage de certains pays ou machines.
2. Répétition d'attributs Prenons l'exemple de la politique suivante : « organization: executive or (organization: weapons and clearance: top-secret) ». L'attribut « organization » est répété deux fois dans la politique. Les schémas prenant en charge la répétition offrent une expressivité et une flexibilité considérables aux fins de la composition de politiques.
3. Sécurité contre certaines attaques par message chiffré La plupart des schémas se présentent sous une forme qui n'est sécurisée que si l'acteur malveillant ne choisit pas les messages à déchiffrer (CPA). Il existe des méthodes normalisées pour convertir ce type de schéma en un schéma qui reste sécurisé, même si l'acteur malveillant manipule les messages chiffrés (CCA), mais il ne s'agit pas d'une procédure automatique. Nous appliquons la célèbre transformation de Boneh-Katz au schéma choisi pour le sécuriser contre cette catégorie d'attaques. Nous présenterons une démonstration de sécurité du schéma de bout en bout dans notre prochain article.

La négation, en particulier, mérite d'être commentée plus en détail. Pour qu'un attribut soit satisfait en cas de négation, son nom doit rester inchangé, mais sa valeur doit être différente. C'est comme si le datacenter disait : « J'ai un pays, mais ce n'est certainement pas le Japon », plutôt que « Je n'ai pas de pays ». Cela peut paraître contre-intuitif, mais cette approche permet le déchiffrement sans nécessiter l'examen de chaque valeur d'attribut. Elle permet également de sécuriser le déploiement incrémentiel d'attributs. Sur la base de ces critères, nous avons fini par choisir le schéma proposé par Tomida et al (2021).

La mise en œuvre d'un schéma cryptographique complexe tel que celui-ci peut être assez difficile. Le postulat du journal discret sur lequel repose la cryptographie à clé publique traditionnelle n'est pas suffisant pour satisfaire aux exigences de sécurité d'ABE. Les schémas ABE doivent permettre de sécuriser à la fois les messages chiffrés et les clés secrètes fondées sur les attributs ; à l'inverse, la cryptographie traditionnelle à clé publique impose uniquement des contraintes de sécurité sur les messages chiffrés, la clé secrète étant simplement un nombre entier. Pour parvenir à ce résultat, la plupart des schémas ABE reposent sur une opération mathématique appelée « appariement bilinéaire ».

La vitesse à laquelle nous pouvons effectuer les opérations d'appariement détermine les performances de référence de notre implémentation. Leur efficacité est particulièrement souhaitable pendant le déchiffrement, durant lequel elles sont mises en œuvre pour réunir la clé secrète fondée sur les attributs et le message chiffré, afin d'obtenir le message en clair. À cette fin, nous nous appuyons sur nos implémentations d'appariement à haute optimisation dans CIRCL, notre bibliothèque open source de suites cryptographiques, dont nous avons longuement parlé dans un précédent article de blog. En outre, les différentes clés, les attributs et le message chiffré dans lequel est intégrée la structure d'accès sont exprimés sous forme de matrices et de vecteurs. Nous avons écrit des routines d'algèbre linéaire permettant de gérer les opérations matricielles telles que la multiplication, la transposition et l'inverse, qui sont nécessaires pour manipuler les structures selon le besoin. Nous avons également ajouté la sérialisation, des tests approfondis et des analyses fondées sur des indices. Enfin, nous avons implémenté notre conversion vers un schéma sécurisé CCA2.

En plus de la cryptographie fondamentale, nous avons dû décider comment nous allions exprimer et représenter les politiques. Nous avons finalement opté pour l'utilisation de chaînes pour notre API. Bien que cette approche soit peut-être moins pratique pour les programmes que ne le seraient des structures, les utilisateurs de notre schéma devraient de toute façon mettre en œuvre un analyseur syntaxique ; aussi, nous avons pris l'initiative de le faire à leur place, afin d'obtenir une interface plus stable. Cela signifie que le front-end de notre langage de création de politiques est composé d'expressions booléennes sous forme de chaînes de caractères, telles que « country: JP or (not region: EU) », tandis que le backend est un circuit booléen monotone constitué de fils et de portes. Les circuits booléens monotones comprennent uniquement des portes AND et OR. Pour traiter les portes NOT, nous avons attribué des valeurs positives ou négatives aux fils. Chaque porte NOT peut être placée directement sur un fil, grâce à la loi de De Morgan, qui permet de convertir une formule telle que « not (X and Y)” into “not X or not Y » ; il en va de même pour la disjonction.

Vous trouverez ci-dessous une démonstration de l'API. L'autorité centrale exécute Setup afin de générer la clé publique principale et la clé secrète principale. La clé publique principale peut être utilisée par tout utilisateur pour chiffrer un message conformément à une politique d'accès. La clé secrète principale, détenue par l'autorité centrale, est utilisée pour générer des clés secrètes pour les utilisateurs en fonction de leurs attributs. Les attributs eux-mêmes peuvent être fournis hors bande. Dans notre cas, nous nous appuyons sur la base de données de provisionnement des machines pour fournir et valider les attributs. Ces clés secrètes fondées sur les attributs font l'objet d'une diffusion sécurisée aux utilisateurs (via TLS, par exemple) et sont utilisées pour déchiffrer les messages chiffrés. L'API inclut également des fonctions d'aide permettant de vérifier les capacités de déchiffrement et d'extraire des politiques des messages chiffrés, offrant ainsi une simplicité d'utilisation améliorée.

publicKey, masterSecretKey := cpabe.Setup()

policy := cpabe.Policy{}
policy.FromString("country: US or region: EU")

ciphertext := publicKey.Encrypt(policy, []byte("secret message"))

attrsParisDC := cpabe.Attributes{}
attrsParisDC.FromMap(map[string]string{"country": "FR", "region": "EU"}

secretKeyParisDC := masterSecretKey.KeyGen(attrsParisDC)

plaintext := secretKeyParisDC.Decrypt(ciphertext)

assertEquals(plaintext, "secret message")

Revenons maintenant à notre exemple initial. Cette fois, c'est l'autorité centrale qui détient la clé secrète principale. Chaque machine dans chaque datacenter présente son ensemble d'attributs à l'autorité centrale qui, après validation, génère pour cette machine particulière une clé secrète unique fondée sur les attributs. La clé est émise lorsqu'une machine est mise en service pour la première fois, lorsque les clés doivent être renouvelées ou lorsqu'un attribut a été modifié, mais n'est jamais émise sur le chemin critique d'une négociation TLS. Cette solution offre également une résistance à la collusion, ce qui signifie que deux machines ne possédant pas les attributs demandés ne peuvent pas réunir leurs clés pour déchiffrer un secret qu'elles ne pourraient pas déchiffrer individuellement. Prenons l'exemple d'une machine possédant l'attribut « country: US » et d'une machine possédant l'attribut « security: high » : ces machines ne peuvent pas s'associer pour déchiffrer une ressource avec la politique « country: US and security: high ».

Cette solution peut évoluer de manière transparente et réagir aux modifications apportées aux machines, ce qui est d'une importance cruciale. Si une nouvelle machine est ajoutée, l'autorité centrale peut simplement lui attribuer une clé secrète, puisque contrairement à notre précédent système de diffusion fondée sur l'identité, il n'est pas nécessaire que les participants au schéma soient prédéterminés lors de la configuration.

Lorsqu'un client transfère son certificat TLS, il peut spécifier une politique ; l'autorité centrale chiffrera alors sa clé privée avec la clé publique principale, conformément à la politique spécifiée. La clé de client chiffrée est ensuite écrite dans Quicksilver, puis diffusée à tous les datacenters. En pratique, il existe ici une couche d'indirection, que nous examinerons dans une section ultérieure.

Lorsqu'un utilisateur consulte le site web du client, le premier service de terminaison TLS du datacenter à recevoir la requête récupère la clé privée chiffrée du client auprès de Quicksilver. Si les attributs du service ne satisfont pas à la politique, le déchiffrement échoue et la requête est transmise au datacenter le plus proche qui satisfait à la politique. Le datacenter qui parvient à déchiffrer la clé effectue la signature, afin de finaliser la négociation TLS.

Le tableau suivant récapitule les avantages et inconvénients des différentes solutions que nous avons évoquées :

Caractéristiques des performances

Nous caractérisons les performances de notre schéma en fonction de mesures inspirées de ECRYPT. Nous définissions une taille d'attribut de 50, soit une valeur nettement supérieure aux exigences de la plupart des applications, qui constitue toutefois le scénario le plus défavorable à des fins d'évaluation. Nous effectuons nos mesures sur un ordinateur portable équipé d'un processeur Intel Core i7-10610U cadencé à 1,80 GHz et comparons les résultats avec RSA avec une sécurité de 2048 bits, X25519 et notre schéma précédent.

Différents schémas de chiffrement basés sur des attributs permettent d'optimiser différents profils de performances. Certains peuvent permettre une génération de clés rapide, tandis que d'autres peuvent prioriser un déchiffrement rapide. Dans notre cas, nous nous intéressons uniquement au déchiffrement rapide, car c'est la seule partie du processus qui réside sur le chemin critique d'une requête. Tout le reste se déroule hors bande, où la surcharge est acceptable.

Une brève remarque sur la méthode Attribute-Based Access Control (ABAC)

Nous avons utilisé Attribute-Based Access Control pour déployer une méthode communément appelée Attribute-Based Access Control (ABAC, contrôle d'accès fondé sur les attributs).

ABAC est une extension de la méthode appelée Role-Based Access Control (RBAC, contrôle d'accès basé sur les rôles), plus connue. Pour comprendre pourquoi ABAC est pertinent, examinons brièvement ses origines. En 1970, le ministère de la Défense des États-Unis a introduit la méthode Discretionary Access Control (DAC, contrôle d'accès discrétionnaire). DAC est utilisé dans la mise en œuvre des systèmes de fichiers Unix, mais s'avère insuffisant si vous souhaitez restreindre le repartage de fichiers, car le propriétaire d'une ressource peut accorder à d'autres utilisateurs la permission d'y accéder d'une manière non approuvée par l'administrateur central. Pour remédier à ce problème, le ministère de la Défense a introduit la méthode Mandatory Access Control (MAC, contrôle d'accès obligatoire). DRM est un bon exemple d'implémentation de la méthode MAC : même si vous détenez un fichier, vous n'êtes pas autorisé à le partager avec d'autres utilisateurs.

RBAC est une mise en œuvre de certains aspects de MAC. ABAC est une extension de RBAC, qui a été définie par le NIST en 2017 en réponse à l'augmentation des caractéristiques d'utilisateurs ne se limitant pas à leurs rôles (par exemple, l'heure, l'agent utilisateur, etc.).

Toutefois, RBAC/ABAC est simplement une spécification. Bien que cette méthode soit traditionnellement mise en œuvre avec une autorité centrale permettant de contrôler l'accès à certaines ressources, ce n'est pas systématiquement le cas. Le chiffrement par attributs est un excellent mécanisme pour la mise en œuvre d'ABAC dans les systèmes décentralisés.

Renouvellement de clés

Bien qu'il puisse être tentant d'attribuer toutes les erreurs au DNS, le remplacement de clés est un concurrent de taille dans cette course. Notre fastidieuse expérience du processus de renouvellement des clés de Geo Key Manager v1, une tâche largement manuelle et sujette aux erreurs, nous a incités à élaborer une méthode de renouvellement des clés robuste et simple, n'affectant pas la disponibilité ; cela a été un objectif explicite du développement de Geo Key Manager v2.

Pour faciliter le renouvellement des clés et améliorer les performances, nous introduisons une couche d'indirection dans le processus d'enveloppement (chiffrement) des clés de client. Lorsqu'un client transfère sa clé privée TLS, au lieu de la chiffrer avec la clé publique principale, nous générons une paire de clés X25519, appelée « clé de politique ». L'autorité centrale ajoute ensuite à une base de données la partie publique de cette paire de clés de politique nouvellement créée et l'identifiant de politique associé. Elle chiffre ensuite la moitié privée de la paire de clés de politique avec la clé publique principale, conformément à la politique d'accès associée. La clé privée du client est chiffrée avec la clé publique de la politique, puis enregistrée dans Quicksilver.

Lorsqu'un utilisateur accède au site web du client, le service de terminaison TLS du datacenter qui reçoit la requête récupère la clé de politique chiffrée associée à la politique d'accès du client. Si les attributs de la machine ne sont pas conformes à la politique, le déchiffrement échoue, et la requête est transmise au datacenter conforme le plus proche. Si le déchiffrement réussit, la clé de politique est utilisée pour déchiffrer la clé privée du client et finaliser la négociation.

Cependant, les clés de politique ne sont pas générées pour le transfert de chaque certificat de client. Comme le représente la figure ci-dessous, si un client émet une requête concernant une politique existant déjà dans le système, et à laquelle une clé de politique est associée, cette dernière sera réutilisée. Dans la mesure où la plupart des clients utilisent les mêmes politiques (par exemple, la restriction à un pays ou la restriction à l'UE), le nombre de clés de politique est considérablement inférieur au nombre de clés de client.

Ce partage des clés de politique est extrêmement utile aux fins du renouvellement des clés. Lors du renouvellement des clés principales (et, par conséquent, des clés secrètes des machines), seul le chiffrement des quelques clés de politique utilisées pour contrôler l'accès aux clés de clients est nécessaire, plutôt que le chiffrement des clés de chaque client. Ceci permet de réduire les besoins de traitement et de bande passante. En outre, la mise en cache des clés de politique par le service de terminaison TLS permet d'améliorer les performances, tout en réduisant le besoin d'exécuter des déchiffrements fréquents sur le chemin critique.

Cette méthode est similaire au chiffrement hybride, dans lequel le chiffrement à clé publique est utilisé pour créer une clé symétrique partagée, qui est ensuite utilisée pour chiffrer les données. La différence ici est que les clés de politique ne sont pas symétriques, mais plutôt des paires de clés X25519 (c'est-à-dire un schéma asymétrique basé sur des courbes elliptiques). Bien qu'elle ne soit pas aussi rapide que les schémas symétriques tels qu'AES, la cryptographie traditionnelle sur les courbes elliptiques est nettement plus rapide que le chiffrement par attributs. Ici, l'avantage est que le service central n'a pas besoin d'avoir accès aux clés secrètes pour chiffrer les clés de clients.

L'autre composante d'une fonctionnalité robuste de renouvellement de clés consiste à conserver plusieurs versions des clés. La dernière génération de clés est utilisée pour le chiffrement, mais la dernière version et les versions précédentes peuvent toutes être utilisées pour le déchiffrement. Nous utilisons un système d'états pour gérer les transitions de clés et la suppression sûre des anciennes clés. Nous avons également établi un système de surveillance étendu, qui nous alerte si une machine n'utilise pas les générations de clés correctes.

« The Tail At Scale »

Geo Key Manager souffrait d'une latence récurrente élevée, qui affectait parfois la disponibilité. L'article de Jeff Dean, « The Tail at Scale », propose une démonstration instructive en expliquant comment, à l'échelle de Cloudflare, même une latence p99 élevée peut être préjudiciable. Malgré la refonte des composants serveur et client de notre service, la latence p99 est restée inchangée. Ces modifications, à l'image de l'abandon des pools d'instances Workers au profit de l'adoption d'une goroutine par requête, ont simplifié le service en permettant la suppression de milliers de lignes de code. Le traçage distribué a permis d'identifier les délais : ils se produisaient entre l'envoi d'une requête par le client et sa réception par le serveur. Toutefois, nous n'avons pas pu étudier le problème plus en détail. L'année dernière, nous avons même écrit un article de blog décrivant nos tentatives de débogage, sans toutefois trouver de solution concrète.

Enfin, nous avons pris conscience qu'il existe une mesure d'indirection entre le client et le serveur. Nos datacenters, à travers le monde, sont de tailles très différentes. Pour éviter de submerger les petits datacenters de connexions, les datacenters plus grands confiaient à des machines intermédiaires individuelles la tâche d'acheminer les requêtes vers d'autres datacenters, en utilisant la bibliothèque Go net/rpc.

Lorsque nous avons inclus, dans le traçage, la fonction de transfert sur le serveur intermédiaire, le problème est devenu manifeste. Un long délai apparaissait entre l'émission de la requête et son traitement. Pourtant, le code n'était qu'un appel à une fonction intégrée de la bibliothèque. Pourquoi retardait-il la requête ?

En fin de compte, nous avons découvert qu'un verrouillage était maintenu pendant la sérialisation de la requête. La suite net/rpc ne prend pas en charge les flux, mais le protocole d'application personnalisé, orienté paquets, que nous avons créé avant l'avènement de gRPC offre cette prise en charge. Pour combler cette lacune, nous avons exécuté une requête et avons attendu la réponse dans la fonction de sérialisation. Bien qu'il s'agisse d'un moyen rapide d'écrire le code, cela a créé un goulet d'étranglement affectant les performances, car une seule requête pouvait être transmise à la fois.

Notre solution a consisté à utiliser des canaux pour la coordination, en laissant s'exécuter plusieurs requêtes pendant que nous attendions l'arrivée des réponses. Lorsque nous l'avons déployée, nous avons constaté une diminution spectaculaire de la latence récurrente.

Malheureusement, nous ne sommes pas (encore) capables d'accélérer la vitesse de la lumière. Les clients qui souhaitent que leurs clés soient conservées uniquement aux États-Unis, alors que les utilisateurs de leur site web se trouvent en Australie, devront s'accommoder de quelques délais pendant le voyage transpacifique. Grâce aux tickets de session, toutefois, ces délais affectent uniquement les nouvelles connexions.

La disponibilité a également été considérablement améliorée. Les datacenters provisionnés après l'initialisation cryptographique pouvaient désormais participer au système ; cela impliquait également que les datacenters qui n'étaient pas conformes à une politique donnée avaient un plus grand nombre de voisins conformes auxquels ils pouvaient transmettre la requête de signature. Cette évolution a permis d'accroître la redondance du système et s'est avérée particulièrement bénéfique pour les datacenters implantés dans des régions ne disposant pas d'une connectivité Internet optimale. Le graphique ci-dessous représente les sondes réussies pour toutes les machines, dans le monde entier, sur une période de deux jours. Pour GeoV1, nous avons observé que la disponibilité des sites web comportant des politiques pour les régions « US » et « EU » avait chuté à moins de 98 %, à une période, tandis que pour GeoV2, le taux de disponibilité chute rarement en dessous des « quatre 9 ».

Conclusion

Félicitations, cher lecteur, d'être arrivé jusqu'ici ! Comme vous, la cryptographie appliquée a parcouru un long chemin, mais seuls quelques fragments parviennent à franchir la barrière qui sépare la recherche de l'adoption dans le monde réel. Combler ce fossé peut contribuer au déploiement de fonctionnalités novatrices de protection des données sensibles. Le chiffrement par attributs est lui-même devenu beaucoup plus efficace et riche en fonctionnalités au cours des dernières années. Nous espérons que cet article vous incitera à réfléchir à l'adoption d'ABE pour répondre à vos besoins en matière de contrôle d'accès, notamment si vous utilisez des systèmes décentralisés et ne souhaitez pas dépendre d'une autorité centrale à haute disponibilité. Nous proposons notre implémentation open source de CP-ABE dans CIRCL, et nous prévoyons de publier un article contenant des détails supplémentaires.

Nous sommes impatients de découvrir les nombreuses améliorations de produit que cette nouvelle fondation cryptographique permettra d'apporter à Geo Key Manager. Nous avons l'intention d'utiliser ce mécanisme fondé sur ABE pour le stockage des clés privées, mais également pour d'autres types de données. Nous nous efforçons de le rendre plus convivial et d'encourager la généralisation de son utilisation par les services internes.

Remerciements

Nous tenons à remercier Watson Ladd pour ses contributions à ce projet lorsqu'il travaillait chez Cloudflare.

......
¹Bien que cela soit vrai pour la plupart des clients, nous proposons le service SSL sans clé qui offre aux clients pouvant gérer leurs propres serveurs de clés la possibilité de stocker leurs clés privées sur site.