Vos clés ne se réveillent qu'en Allemagne : à l'intérieur du gestionnaire GeoKey post-quantique de Cloudflare

Points clés

• Le gestionnaire GeoKey PQ de Cloudflare, lancé le 23 octobre 2026 en version bêta fermée avec une disponibilité générale prévue au premier trimestre de 2027, enveloppe les clés de déchiffrement des clients pour qu’elles ne puissent être déballées que sur des serveurs situés dans une zone géographique choisie par le client. Une requête qui aboutit ailleurs échoue de façon sécuritaire : elle est rejetée, pas réacheminée vers un serveur qui pourrait aider.
• La conception répond à deux menaces à la fois. Récolter aujourd’hui, déchiffrer plus tard signifie qu’un adversaire peut enregistrer le trafic chiffré aujourd’hui et le déchiffrer quand un ordinateur quantique arrivera. Les règles géographiques signifient que certaines données ne doivent jamais être déchiffrées hors d’une région. Une clé qui ne peut se réveiller qu’en Allemagne, et qui résiste au déchiffrement quantique, couvre les deux.
• Le mécanisme est une hiérarchie, pas une seule clé. Une clé racine régionale symétrique de 256 bits par région sert à dériver des paires de clés propres à une application pour un service, une région et une époque. La clé enveloppée voyage partout dans le monde par le système de distribution Quicksilver de Cloudflare, mais la clé racine ne voyage jamais ainsi. Elle n’atteint les serveurs périphériques autorisés que par un chemin d’approvisionnement distinct, et sur les serveurs périphériques elle ne vit que dans la mémoire volatile du trousseau de clés du noyau, jamais sur le disque périphérique (le service d’approvisionnement stocke les copies maîtresses dans Vault sur place).
• L’enveloppement lui-même est HPKE hybride (Hybrid Public Key Encryption, chiffrement à clé publique hybride) : ML-KEM-768 plus X25519, avec dérivation de clé HKDF-SHA-256 et chiffrement authentifié AES-256-GCM. Hybride signifie que l’enveloppement reste sûr tant qu’au moins un des deux mécanismes d’encapsulation de clé tient, ce qui est la posture honnête tant que les algorithmes post-quantiques sont encore jeunes.
• Pour les équipes canadiennes, la question à apporter aux appels avec les fournisseurs n’est pas de savoir si un fournisseur promet la résidence. C’est de savoir ce qui se passe mécaniquement quand une requête aboutit au mauvais endroit, qui détient les clés racines, et ce que la définition de région du fournisseur inclut. Une promesse qui échoue en mode ouvert n’est pas un contrôle.

Certaines données restent sensibles longtemps. Un dossier de santé, un contrat de défense, un dossier financier : ces données peuvent compter pendant des décennies après leur création. Ce long horizon fait de la stratégie récolter aujourd’hui, déchiffrer plus tard une vraie menace plutôt qu’une expérience de pensée. Un adversaire n’a pas besoin d’un ordinateur quantique aujourd’hui. Il a besoin d’un disque dur, de patience et d’une copie de votre texte chiffré. Quand la machine arrivera, le trafic enregistré s’ouvrira.

Ajoutez une deuxième contrainte, que les équipes de protection des renseignements personnels au Canada connaissent bien. Certaines données ne doivent pas être déchiffrées hors d’une zone géographique choisie. Les règlements, les contrats et les attentes des clients tracent des lignes sur des cartes, et un réseau mondial qui reproduit les données partout par souci de disponibilité franchit ces lignes par défaut. Le réseau de Cloudflare est exactement ce type de réseau : anycast, partout, conçu pour servir à partir de l’endroit le plus proche. Concilier cette architecture avec une promesse comme « cette clé ne fonctionne qu’en Allemagne » est un vrai problème d’ingénierie, et c’est le problème que le nouveau gestionnaire GeoKey post-quantique de l’entreprise tente de résoudre.

Deux menaces, un seul système de clés

Commencez par la moitié quantique. La cryptographie classique à clé publique, la machinerie RSA et à courbe elliptique qui protège la plupart des échanges de clés, se brise devant un ordinateur quantique assez puissant exécutant l’algorithme de Shor. Personne ne sait quand une telle machine arrivera, et cette incertitude est le point central. Les données chiffrées aujourd’hui avec un échange de clés classique peuvent être enregistrées aujourd’hui et déchiffrées plus tard. La défense consiste à passer aux algorithmes post-quantiques normalisés par le NIST, et à le faire avant que la fenêtre de récolte compte. Cloudflare migre déjà ses propres produits vers la cryptographie post-quantique; ce lancement est la prochaine étape.

La moitié géographique est plus ancienne. Cloudflare a été pionnière des clés TLS à restriction géographique en 2017 avec le gestionnaire GeoKey original : un client pouvait dire que ses clés privées TLS ne se déballent qu’en Inde, pour que la signature TLS de ses requêtes se fasse dans le réseau de l’Inde, et nulle part ailleurs sur le maillage anycast. En 2022, le système a évolué vers le chiffrement fondé sur les attributs avec politique de texte chiffré, ou ABE, qui exprimait les exigences géographiques sous forme d’attributs, comme « région égale Union européenne » ou « région égale Canada plus États-Unis plus Mexique ». Les serveurs nouvellement autorisés pouvaient recevoir des capacités de déchiffrement correspondantes sans réenvelopper chaque clé de client.

Cette flexibilité a créé l’ouverture pour la nouvelle conception, et aussi son principal compromis. Aucun schéma ABE post-quantique prêt pour la production n’existe aujourd’hui, et Cloudflare dit que les clients n’ont pas besoin d’un grand nombre de régions. Le nouveau gestionnaire GeoKey abandonne donc ABE et choisit la simplicité : une protection hybride ML-KEM-768 et X25519, avec deux types de clés. Une clé racine régionale est un secret symétrique lié à une région. Une paire de clés propre à une application en est dérivée pour un seul service, comme Gateway ou Tunnel. Le résultat protège les clés privées contre la stratégie récolter aujourd’hui, déchiffrer plus tard tout en préservant les limites régionales d’utilisation des clés. Plus simple à exploiter, plus facile à auditer, et il abandonne la flexibilité d’attributs d’ABE. C’est un compromis à nommer franchement, pas un détail à enterrer.

La hiérarchie : racines, clés d’application, époques

Chaque clé privée de client enveloppée porte des métadonnées avec trois champs : le contexte de service, la limite régionale et l’époque. Le contexte de service est le service Cloudflare qui utilise la clé, Tunnel ou Gateway, par exemple. La limite régionale est l’ensemble approuvé de centres de données où la clé peut être déballée et utilisée, des centres de données en Allemagne ou dans l’Union européenne, par exemple. L’époque identifie la génération de la clé racine régionale à laquelle la clé appartient. Chaque rotation crée une nouvelle époque.

Les clés qui partagent un contexte de service, une limite régionale et une époque partagent une paire de clés propre à une application. L’exemple de Cloudflare rend le rayon d’impact concret. Acme Co. a une clé pour Tunnel en Allemagne et une autre pour Gateway en Allemagne. Road Runner Inc. a une clé pour Tunnel en Allemagne et une autre pour Gateway dans l’Union européenne. Compromettre la clé privée propre à Tunnel-Allemagne pourrait exposer à la fois les clés Tunnel-Allemagne d’Acme et de Road Runner, mais pas leurs clés Gateway. Compromettre la clé racine de l’Allemagne pourrait toucher chaque clé propre à une application dérivée de cette racine pour la même époque. C’est la hiérarchie qui fait son travail : les dommages restent dans la case où ils se sont produits, et les cases sont tracées selon des lignes qu’un client peut comprendre.

L’architecture actuelle utilise des paires de clés asymétriques propres à une application. La composante publique enveloppe la clé privée du client. La composante privée est requise pour la déballer. La clé privée enveloppée est ensuite distribuée avec son contexte de service, sa région et son époque joints comme métadonnées.

Deux chemins de distribution, et pourquoi la séparation compte

Voici la partie de la conception qui mérite le plus d’attention, parce que c’est là que la plupart des arguments de marketing sur la « souveraineté » s’effondrent. Le gestionnaire GeoKey sépare deux choses que d’autres systèmes mélangent : les clés enveloppées distribuées mondialement, et les clés racines régionales qui peuvent les déballer.

Quicksilver, le système mondial de distribution de configuration de Cloudflare, transporte les clés privées enveloppées et leurs métadonnées dans tout le réseau. Il ne transporte jamais les clés racines régionales. Celles-ci empruntent un chemin d’approvisionnement distinct : un service d’approvisionnement les stocke, adossé à Vault géré sur place, et ne les livre qu’aux serveurs périphériques autorisés pour chaque région.

L’autorisation est là où le matériel rencontre l’inventaire. Avant qu’un serveur périphérique puisse recevoir une clé racine régionale, le service d’approvisionnement vérifie trois éléments. D’abord, un module de plateforme sécurisée prouve que le serveur détient une identité matérielle enregistrée. Ensuite, Zinc, le système d’inventaire des serveurs de Cloudflare, associe cette identité à un centre de données et à un emplacement physique. Troisièmement, le service d’approvisionnement décide quelles clés racines régionales ce serveur peut recevoir. Le serveur présente son identité matérielle, reçoit un jeton qui ne permet que les clés racines régionales autorisées pour son emplacement, et récupère ces clés.

Les clés sont ensuite chargées dans le trousseau de clés du noyau Linux, et non écrites sur disque. Des contrôles d’accès au niveau des processus limitent les services qui peuvent les utiliser. Comme la mémoire est volatile, un redémarrage de la machine efface les clés, et le serveur doit s’authentifier et les approvisionner de nouveau. C’est de la complexité opérationnelle achetée exprès : moins de clés persistantes qui traînent pour qu’un adversaire les trouve.

L’appartenance n’est pas statique non plus. À mesure que des serveurs entrent en service ou en sortent, Zinc met à jour les centres de données qui composent une région, la couche d’approvisionnement actualise cette appartenance plusieurs fois par jour, et la définition mise à jour se propage rapidement par Quicksilver. Quand l’appartenance régionale change, le service d’approvisionnement synchronise le trousseau de clés du noyau de chaque serveur avec le dernier ensemble autorisé. Une région, dans ce système, est une liste d’inventaire vivante, pas une ligne tracée une fois sur une carte. Gardez cela en tête la prochaine fois qu’un fournisseur dira « vos données restent dans la région X » sans dire ce que la région X contient cette semaine.

Échouer de façon sécuritaire, sinon ce n’est pas un contrôle

Le choix de conception qui compte le plus pour une équipe de protection des renseignements personnels est le mode de défaillance. Le gestionnaire GeoKey échoue de façon sécuritaire, délibérément et à deux niveaux.

Au démarrage, le service de clés périphériques, le composant sur chaque serveur périphérique qui déballe les clés privées des clients et sert les requêtes, vérifie qu’il a chargé chaque clé racine régionale exigée par sa configuration. Si une clé configurée manque ou est mal formée, le service ne démarre pas. Il ne continue pas en boitant en espérant que tout ira bien.

Au moment de la requête, si les métadonnées d’une requête désignent une clé racine régionale qui n’est pas disponible localement, la requête échoue. L’exemple de Cloudflare : une requête pour l’Allemagne qui tenterait d’une façon ou d’une autre de déchiffrer en Espagne ou en France échoue, parce que ni l’Espagne ni la France ne détiennent la clé racine régionale de l’Allemagne. La garantie est énoncée de façon absolue : une clé racine régionale ne quitte jamais sa région, quoi qu’il arrive.

Échouer en mode ouvert signifierait déballer la clé privée d’un client hors de sa région autorisée plutôt que de rejeter la requête. Cloudflare dit qu’elle ne le fait jamais. Si une vérification requise échoue, contexte de service, région, époque, la requête est rejetée. Un serveur périphérique ne sert des requêtes pour une région qu’une fois sa configuration et son approvisionnement en clés terminés.

C’est le test à appliquer à toute affirmation de résidence d’un fournisseur. Demandez ce qui se passe quand la vérification échoue. Si la réponse est que le trafic est réacheminé, retenté ailleurs, ou dégradé avec élégance vers un serveur qui peut aider, la promesse de résidence est une préférence de routage, pas un contrôle. Un contrôle refuse.

Vérifiez la clé vous-même

La hiérarchie se ressent plus facilement qu’elle ne se lit. Ci-dessous se trouve un simulateur construit à partir du mécanisme décrit plus haut. Choisissez les métadonnées d’une clé enveloppée, une politique de région, un service, une époque et un algorithme d’enveloppement, puis lancez des requêtes vers des serveurs périphériques dans cinq villes et observez lesquels peuvent déballer la clé et lesquels échouent de façon sécuritaire. Les notes par serveur nomment la vérification qui a tranché.

Trois choses à remarquer si vous l’avez exécuté avec les valeurs par défaut. D’abord, la clé enveloppée elle-même voyage partout. La distribution mondiale n’est pas la fuite; le déballage est l’étape contrôlée, et le contrôle est la clé racine régionale. Ensuite, changez le service de Tunnel à Gateway et regardez Francfort échouer : même région, même époque, mauvais contexte de service, et la clé propre à l’application ne correspond pas. Les cases sont tracées par service, pas seulement par carte. Troisièmement, passez l’enveloppement à X25519 classique seulement et lisez le panneau de récolte : la même clé enveloppée qui est sûre aujourd’hui devient une reconnaissance de dette payable au premier adversaire muni d’un ordinateur quantique et d’un disque dur plein de trafic enregistré. L’enveloppement hybride est ce qui supprime cette reconnaissance de dette.

Essayez aussi l’époque périmée. Une clé d’époque précédente se déballe encore pendant une rotation douce, parce que l’ancienne époque reste disponible pour une transition contrôlée. C’est une fonction avec un coût : les anciennes époques sont une ancienne surface d’attaque. Une rotation stricte réenveloppe les clés touchées sous une époque de remplacement pour que l’époque précédente puisse être retirée entièrement. La politique de rotation est là où la théorie rencontre le calendrier des opérations, et il vaut la peine de demander à un fournisseur laquelle il applique par défaut.

La cryptographie : HPKE hybride, énoncée plainement

Pour le chemin Cloudflare One, le service de gestion des clés du plan de contrôle dérive une paire de clés HPKE propre à une application, suivant la RFC 9180. Le mécanisme d’encapsulation de clé combine ML-KEM-768 avec X25519. HKDF-SHA-256 fournit la dérivation de clé. AES-256-GCM fournit le chiffrement authentifié.

La construction hybride fait un travail précis. Combiner un algorithme post-quantique avec un algorithme classique préserve la confidentialité tant qu’au moins une composante reste sûre. Cela compte parce que ML-KEM est jeune. C’est une norme du NIST, FIPS 203, et elle ouvre des portes à des clients très sensibles qui exigent des algorithmes post-quantiques normalisés. Mais les jeunes normes portent un risque d’implantation et de cryptanalyse, et X25519 est le filet de sécurité éprouvé. Si ML-KEM se brise, X25519 tient toujours. Si X25519 tombe devant un ordinateur quantique, ML-KEM tient toujours. La combinaison est le choix prudent, et la prudence est la bonne posture pour des clés qui doivent survivre des décennies.

Une mise en garde honnête accompagne cela. La protection hybride couvre la couche d’enveloppement décrite ici. Elle ne rend pas à elle seule chaque autre partie du trafic d’un client sûre contre le quantique. Les configurations TLS, le texte chiffré stocké ailleurs dans la pile et les propres systèmes du client ont chacun leurs propres calendriers de migration. Un gestionnaire de clés géolocalisé et résistant au quantique est un composant, pas une migration terminée.

Rotation, et la limite de confiance

La conception validée prend en charge deux modes de rotation. Une rotation douce crée une nouvelle époque pour la clé racine régionale tout en conservant un accès contrôlé à un nombre limité d’époques précédentes, une génération précédente selon l’exemple de Cloudflare. Les nouvelles clés privées sont enveloppées avec la dernière époque, tandis que les anciennes clés enveloppées restent utilisables pendant la transition. L’analogie offerte est celle d’une société de cartes de crédit qui vous laisse utiliser un numéro de carte précédent pour des paiements récurrents chez un détaillant autorisé. Le service continue pendant que la transition se termine.

Une rotation stricte réenveloppe plutôt les clés privées enveloppées touchées sous une époque de remplacement pour que l’accès à l’époque précédente puisse être retiré. La carte précédente cesse de fonctionner partout, immédiatement. La rotation stricte est le mode de réponse aux incidents : elle coûte un effort opérationnel et c’est ainsi qu’on retire vraiment une époque compromise ou dépassée.

La limite de confiance vaut la peine d’être énoncée exactement, parce qu’elle dit qui pourrait briser la promesse. Elle inclut le service de gestion des clés, le service d’approvisionnement et les services de clés périphériques autorisés, parce que chacun peut accéder aux clés racines régionales. Quicksilver reste hors de la limite : il ne reçoit que des clés privées enveloppées et leurs métadonnées associées. La garantie repose donc sur le bon comportement de trois systèmes, pas d’un seul. C’est une surface plus petite que « tout le nuage », et c’est quand même une surface. Un fournisseur qui affirme que sa garantie de résidence n’a aucun composant de confiance vous vend autre chose.

Les limites honnêtes

Un fournisseur qui décrit son propre programme de cryptographie mérite une lecture sceptique, et il y a quatre endroits où insister.

D’abord, c’est une version bêta fermée. La disponibilité générale est prévue au premier trimestre de 2027, et l’intégration CDN qui apporterait ce nouveau gestionnaire à la capacité GeoKey CDN existante est encore en développement. Si votre cas d’usage concerne les certificats CDN plutôt que Cloudflare One, ce qui est décrit ici est une feuille de route, pas une fonction que vous pouvez acheter aujourd’hui. L’annonce est prudente sur cette distinction. Votre calendrier d’achat devrait l’être aussi.

Ensuite, la flexibilité d’ABE a disparu. Le système de 2022 pouvait exprimer des politiques sous forme d’attributs dans de nombreuses régions sans réenvelopper les clés. Le nouveau système utilise une clé racine régionale par région et des clés d’application dérivées. Cloudflare dit que les clients n’ont pas besoin d’un grand nombre de régions, et pour la plupart des clients, c’est probablement vrai. Mais si votre politique exige des combinaisons d’attributs fines, vérifiez que le modèle plus simple exprime ce dont vous avez besoin avant de le supposer.

Troisièmement, la région est une liste d’inventaire qui change plusieurs fois par jour. C’est de la bonne ingénierie, puisque le réseau change constamment, et cela signifie que « l’Allemagne » est une définition tenue à jour, pas un fait fixe. Demandez comment les changements d’appartenance régionale sont audités, et si un client est avisé quand les centres de données de sa région changent. Une garantie dont la portée change en silence est plus faible qu’une garantie dont les changements sont journalisés.

Quatrièmement, la garantie couvre l’endroit où les clés se déballent, pas tout le reste. Cloudflare est explicite : des chantiers distincts déterminent où les tunnels se terminent, où le trafic est inspecté, comment il est acheminé et où le traitement du texte clair a lieu. Tous dépendent de la région de déballage, parce que le trafic TLS ne peut être déchiffré que là où la clé est disponible, mais ce sont des contrôles distincts avec leurs propres configurations. Le gestionnaire GeoKey est la fondation de clés de l’histoire de souveraineté, pas toute l’histoire. Un examen de résidence qui s’arrête au déballage des clés est incomplet.

La lecture canadienne de diligence raisonnable

Si vous achetez, construisez ou supervisez des systèmes pour une organisation canadienne, voici comment convertir cette annonce en questions.

Commencez par le mode de défaillance. Que se passe-t-il, mécaniquement, quand une requête aboutit là où sa clé ne peut se déballer? Parcourez un scénario : une clé destinée à l’Allemagne, une requête qui atteint un serveur en France. Le système rejette-t-il, ou trouve-t-il un autre moyen? Si le fournisseur ne peut pas décrire le chemin de rejet, l’affirmation de résidence est une préférence de routage.

Ensuite, les clés racines. Qui les détient, où vivent-elles, et quel est le chemin d’approvisionnement? Demandez si les clés enveloppées et les clés racines empruntent le même système de distribution. Si oui, un seul compromis comble l’écart que toute la conception existe pour maintenir. Demandez si les clés racines touchent jamais le disque, et ce qui se passe au redémarrage du serveur. La mémoire volatile avec réauthentification est le modèle à rechercher.

Ensuite, la définition de région. Qu’est-ce qui se trouve exactement dans votre région, à quelle fréquence cela change-t-il, et comment ce changement est-il audité? Sous la Loi 25 du Québec, les organisations portent la responsabilité des renseignements personnels qu’elles transfèrent et des mesures de protection qui les entourent, et une promesse de région que vous ne pouvez pas auditer est difficile à documenter dans une évaluation des facteurs relatifs à la vie privée. Il en va de même pour le principe de responsabilité de la LPRPDE : vous restez responsable de ce que vos sous-traitants font, y compris l’endroit où ils déchiffrent.

Deux autres, propres à la moitié quantique. D’abord, le calendrier. Récolter aujourd’hui, déchiffrer plus tard signifie que l’horloge de migration a commencé quand les données ont été enregistrées pour la première fois, pas quand l’ordinateur quantique arrivera. Demandez aux fournisseurs leurs dates de migration post-quantique par composant, pas une seule date d’entreprise. Ensuite, la question hybride. L’enveloppement est-il hybride, ou à algorithme unique? Un seul algorithme post-quantique est un pari sur la jeunesse d’une norme. Un hybride est une couverture, et pour des clés qui doivent survivre des décennies, la couverture est le point central.

Cloudflare mérite d’être reconnue pour la forme de cette conception : une petite limite de confiance, un mode de défaillance sécuritaire, des clés racines volatiles, et un choix d’algorithme hybride qui refuse de tout miser sur une seule norme nouvelle. Ce sont les propriétés à exiger de tout fournisseur qui fait une promesse de région, que le fournisseur soit Cloudflare ou non.

La question ouverte

L’annonce se termine par un formulaire où les clients actuels de la suite de localisation des données peuvent manifester leur intention de tester la fonction pour le trafic CDN avant la disponibilité générale. C’est la bonne prochaine étape pour une équipe dont le modèle de menace inclut à la fois un adversaire quantique et une règle géographique. Mais cela laisse la question la plus difficile ouverte, et c’est une question pour toute l’industrie.

Chaque promesse de souveraineté repose sur la définition d’une région par quelqu’un, l’inventaire de serveurs de quelqu’un, et le chemin d’approvisionnement de quelqu’un. Ce sont des faits opérationnels, pas mathématiques, et ils changent plusieurs fois par jour. La cryptographie peut rendre la garantie précise : cette clé se déballe ici et nulle part ailleurs, sous ces vérifications, ou pas du tout. Ce que la cryptographie ne peut pas faire, c’est rendre la définition de « ici » stable, auditable et convenue entre les fournisseurs, les régulateurs et les clients. La prochaine manche de cette histoire n’est pas un meilleur algorithme. C’est un langage commun pour dire ce qu’une région signifie, et une piste d’audit quand elle change. D’ici là, la bonne posture est celle de Cloudflare elle-même : échouer de façon sécuritaire, documenter la limite, et vérifier vous-même le chemin de rejet.

Sources principales

1. Bringing post-quantum cryptography to geographically fenced key management (Cloudflare)
2. GeoKey Manager (Cloudflare Developers)
3. HPKE: Hybrid Public Key Encryption (RFC 9180) (IETF)
4. ML-KEM (FIPS 203) (NIST)