Les ordinateurs quantiques capables de casser les chiffrements largement utilisés aujourd’hui restent une menace future. Google Cloud ne veut pas que sa migration de sécurité devienne un problème à l’avenir.
Google a fixé 2029 comme objectif pour parvenir à une préparation complète à la cryptographie post-quantique dans l’ensemble de Google Cloud, en présentant une migration pluriannuelle couvrant les connexions réseau, les signatures numériques, les systèmes d’identité, les certificats, la gestion des clés et la sécurité assistée par le matériel. L’entreprise a déjà déployé certaines protections et prévoit d’importants changements supplémentaires en 2027 et 2028.
Pour les équipes informatiques et de sécurité des entreprises, la feuille de route de Google véhicule un message moins confortable : les fournisseurs cloud peuvent sécuriser leur propre infrastructure contre les menaces quantiques, mais leurs clients devront toujours migrer leurs applications, leurs clés, leurs certificats, leurs logiciels et leurs configurations.
Google a déjà entamé la transition vers la sécurité quantique
de Google feuille de route post-quantique, publiée le 11 août, divise la migration en trois grands volets : protéger les données chiffrées contre un déchiffrement futur, protéger les signatures numériques et les identités contre la falsification, et construire une infrastructure cryptographique capable de s’adapter à l’évolution des normes.
Une partie de ce travail est déjà terminée.
Google indique que les points de terminaison de ses API Cloud prennent désormais en charge l’échange de clés résistant aux attaques quantiques, avec ML-KEM, une norme du NIST, en mode hybride. Les équilibreurs de charge applicatifs et les proxys prennent également en charge l’échange hybride de clés post-quantique pour TLS 1.3, tandis que Cloud KMS propose désormais de manière générale les algorithmes standardisés ML-KEM, ML-DSA et SLH-DSA.
Google a renforcé cet effort en août en introduisant l’importation de clés résistantes aux attaques quantiques en préversion pour Cloud KMS, à destination des organisations qui utilisent des modèles de type « bring your own key » pour transférer des clés cryptographiques vers Google Cloud.
Le calendrier est important, car les agences de sécurité ne considèrent plus la cryptographie post-quantique comme une préparation théorique. Après avoir finalisé trois normes de cryptographie post-quantique en 2024, le NIST a exhorté les organisations à commencer à les utiliser et à planifier leurs migrations plutôt qu’à attendre l’apparition d’un ordinateur quantique suffisamment puissant.
Ces préparatifs de sécurité se déroulent alors que le matériel quantique lui-même continue de progresser. eWeek a récemment expliqué comment l’infrastructure quantique d’IBM évolue grâce à d’immenses modules cryogéniques interconnectés, conçus pour soutenir ses travaux en matière de calcul tolérant aux pannes.
La feuille de route de Google devient plus ambitieuse jusqu’en 2028
La partie la plus immédiate du plan de Google porte sur ce que les chercheurs en sécurité appellent les attaques consistant à « stocker maintenant, déchiffrer plus tard ».
Un adversaire n’a pas besoin aujourd’hui d’un ordinateur quantique pertinent sur le plan cryptographique pour créer un problème futur. Le trafic chiffré peut en théorie être collecté dès maintenant, puis stocké jusqu’à ce que des systèmes quantiques suffisamment puissants existent pour s’attaquer au chiffrement à clé publique vulnérable.
Google vise donc la fin de 2027 pour un ensemble de protections couvrant les charges de travail des clients, les connexions des administrateurs et des développeurs, ainsi que les pipelines de données. Sa feuille de route cite notamment Cloud VPN, Cloud Interconnect, les SDK Google Cloud, le maillage de services GKE, Cloud Storage, BigQuery et les services de transfert de données.
La phase suivante cible 2028.
Google prévoit d’étendre la protection résistante aux attaques quantiques aux signatures numériques, aux attestations logicielles, aux certificats, aux systèmes d’identité et de gestion des accès, à Confidential Computing, à Cloud HSM et aux systèmes externes de gestion des clés. Cloud IAM figure parmi les produits prévus pour 2028, tandis que le déploiement plus large de l’authentification résistante aux attaques quantiques dans l’ensemble de l’infrastructure de Google s’étend sur 2027 et 2028.
Ce calendrier s’inscrit dans le cadre d’un effort américain beaucoup plus vaste en faveur de la préparation à l’ère quantique. Un décret présidentiel de juin exige que les actifs fédéraux de grande valeur et les systèmes à fort impact utilisent la cryptographie post-quantique pour les signatures numériques d’ici à la fin de 2031. eWeek a examiné cette échéance et l’effort fédéral plus large dans son article consacré à la nouvelle initiative quantique.
Ce qu’a constaté eWeek : l’objectif de Google ne supprime pas la migration du client
Le détail le plus important de la feuille de route de Google est peut-être enfoui sous toutes ces échéances produit : 2029 est l’objectif de Google, pas nécessairement la ligne d’arrivée du client.
Google répartit explicitement les responsabilités entre la sécurité « du cloud » et la sécurité « dans le cloud ».
L’entreprise indique qu’elle prendra en charge la transition de son infrastructure sous-jacente, notamment les réseaux, le chiffrement en transit, les serveurs, les systèmes d’exploitation et les autres fondations du cloud. Mais les clients restent responsables de leurs propres applications, de leurs logiciels côté client, du cycle de vie de leurs clés asymétriques et de leurs configurations Google Cloud.
Google avertit même que certaines transitions matérielles pourront se poursuivre au-delà de 2029, car les mises à niveau peuvent dépendre des cycles normaux de remplacement des équipements. Les calendriers de certains produits pourront également évoluer au gré des exigences techniques, des dépendances tierces et de l’évolution des normes.
Cette distinction empêche la date de 2029 de devenir une étape trompeuse signifiant que le « problème est résolu ».
Le défi de la migration dépasse largement Google Cloud. L’analyse par eWeek de la stratégie d’IBM en matière de sécurité quantique a également souligné la nécessité, pour les organisations, d’identifier les vulnérabilités cryptographiques et de préparer leurs systèmes avant que les machines quantiques à grande échelle ne deviennent des menaces concrètes.
Ce que les entreprises devraient commencer à faire dès maintenant
Google recommande trois mesures immédiates : inventorier, mettre à jour et valider.
Les organisations doivent identifier les endroits où sont utilisées des clés cryptographiques, des certificats et des algorithmes vulnérables ; mettre à jour leurs logiciels et leurs outils de développement afin de prendre en charge la PQC ; et tester leurs applications avec des API et des équilibreurs de charge résistants aux attaques quantiques avant que la transition n’atteigne les systèmes de production.
Les recommandations du NIST sur la migration vers la PQC vont dans le même sens. L’agence affirme que les produits, services et protocoles de cybersécurité devront être mis à jour et que les organisations doivent identifier les endroits où sont utilisés des algorithmes vulnérables aux attaques quantiques avant de les remplacer. Ses recommandations actuelles de transition prévoient que ces algorithmes soient déconseillés, puis finalement retirés des normes du NIST d’ici à 2035, les systèmes les plus exposés devant migrer plus tôt.
Pour les équipes chargées de la sécurité des entreprises, l’objectif fixé par Google à 2029 est donc moins un compte à rebours lointain qu’un jalon de planification.
Le fournisseur cloud modifie déjà la cryptographie sous-jacente à sa plateforme. Pour les clients, la question la plus difficile est de savoir s’ils connaissent suffisamment bien la cryptographie présente dans leurs propres environnements pour suivre le rythme.
À lire également : eWeek a précédemment expliqué pourquoi la cryptographie post-quantique doit être déployée avant que les ordinateurs quantiques ne deviennent assez puissants pour menacer le chiffrement à clé publique utilisé aujourd’hui.