Étiquette : GeoKey Manager

Une salle de serveurs remplie de racks de matériel informatique dans un centre de données.

Cloudflare déploie un gestionnaire de clés post-quantiques géolocalisé

Cloudflare a mis en bêta son gestionnaire de clés géographiquement restreint, le PQ GeoKey Manager. Ce système permet d’ancrer les clés de déchiffrement de manière à ce qu’elles ne soient accessibles que sur les serveurs situés dans la zone géographique choisie par le client. C’est un jalon important dans la migration de l’entreprise vers la cryptographie post-quantique, une nécessité face à la menace « récolter maintenant, déchiffrer plus tard ».

Pour les organisations traitant des données très sensibles — gouvernements, institutions financières ou prestataires de soins de santé — le risque ne vient pas uniquement de l’attente d’un ordinateur quantique. En raison de l’échelle de son réseau mondial, Cloudflare doit répliquer les données sur de nombreux serveurs. Or, les réglementations de souveraineté exigent que le traitement des données en clair se fasse uniquement dans des frontières précises. Le nouveau gestionnaire orchestre cela en encapsulant chaque clé de déchiffrement de sorte qu’elle ne puisse être déchiffrée que par les serveurs autorisés dans la région désignée.

Le concept de clé géolocalisée n’est pas nouveau chez Cloudflare. Le GeoKey Manager initial, lancé en 2017, permettait déjà de contrôler où les clés TLS pouvaient être déchiffrées sur le réseau anycast. En 2022, le système a évolué vers le chiffrement basé sur les attributs (ABE), permettant de définir des exigences géographiques via des attributs comme « région = Union Européenne ». Ce modèle a rencontré un obstacle : l’absence de schémas ABE matures compatibles avec la cryptographie post-quantique.

Photographie en plan rapproché de deux professionnels analysant une interface de sécurité affichant des données cryptographiques et des cartes régionales.

Le choix de simplifier l’architecture était donc logique. Au lieu de l’ABE, Cloudflare utilise désormais une protection hybride combinant ML-KEM-768, un standard NIST, et X25519. Cette structure repose sur deux types de clés. Il y a la clé racine régionale, un secret symétrique lié à une zone précise, et des paires de clés spécifiques à une application (comme Tunnel ou Gateway) dérivées de cette racine. Ce mécanisme garantit que le matériel sensible de clé reste enfermé dans ses frontières régionales.

Séparation des chemins de clés et politique de rejet stricte

La mise en œuvre technique est rigoureuse. Lors de l’initialisation, le service de clés au niveau de la périphérie vérifie qu’il a chargé toutes les clés racines régionales nécessaires. Si une clé configurée est manquante ou mal formée, le service refuse de démarrer. De plus, pour chaque requête individuelle, le système applique une politique de « fail closed » : si les métadonnées d’une requête indiquent une clé racine régionale absente localement, la requête est rejetée. Si une tentative de déchiffrement pour l’Allemagne arrivait en Espagne, par exemple, elle échouerait faute de disposer de la clé racine allemande. Ce principe assure que la clé racine ne quitte jamais sa juridiction.

Ce changement architectural signifie que les clés chiffrées sont distribuées globalement via Quicksilver, le magasin de clés-valeurs de Cloudflare, mais le déchiffrement est strictement cantonné à la zone définie par la clé racine. Les ingénieurs ont insisté sur le fait que ce modèle, bien que performant, est une décision délibérée. En cas de défaillance de la vérification de contexte régional ou d’époque, le système refuse le service. Comme l’a souligné un expert en cybersécurité, ce refus est « une décision intentionnelle » (InfoQ, 2026-10-31).

Gestion des transitions sans interruption

Le passage à ce nouveau modèle a nécessité de résoudre la question de la maintenance. Comment éviter une interruption de service lors du changement des clés ? Le système gère cela via un modèle d’« époque ». Une rotation douce introduit une nouvelle époque tandis qu’un nombre limité des anciennes restent utilisables. Pour une rotation complète, une époque est « réemballée » sous une nouvelle, coupant l’accès aux précédentes. L’objectif est que le client maintienne la continuité de service pendant la transition cryptographique.

La bêta est ouverte aux clients de la Data Localization Suite, et la généralisation est prévue pour le premier trimestre 2027. Il reste à observer comment les entreprises géographiquement contraintes réagissent à cette politique de rejet stricte face à un échec de vérification, même si Cloudflare affirme que c’est le prix à payer pour garantir la souveraineté des données à l’échelle mondiale.

Sources

Crédits photo