Chiffrement post-quantique : Google Cloud commence par la signature numérique

Des signatures numériques post-quantiques avec Cloud KMS

L’implémentation mise en place par GCP repose sur des clés asymétriques de niveau de sécurité de 192 bits. La clé privée est d’une longueur de 4 032 octets, la clé publique de 1 952 octets, tandis que la signature fait 3 309 octets. Dans sa catégorie, ML-DSA-65 est réputé pour offrir un compromis entre performance et sécurité du chiffrement.

GCP prend également en charge un algorithme de signature numérique sans état basé sur le hachage (FIPS 205) basé lui-même sur le schéma SPHINCS+. Plus particulièrement, le fournisseur a choisi SLH-DSA-SHA2-128S. Ici, l’algorithme disposant d’un niveau de sécurité 128 bits génère des clés publiques de 32 octets et la taille de signature atteint 7 856 octets.

Ces algorithmes qui ont le même rôle doivent produire des clés beaucoup plus difficiles à briser par l’algorithme quantique de Shor. Ce ne serait pas le cas du protocole traditionnel Diffie-Hellman (sa version post-quantique est en cours de développement) ni des schémas RSA et ECC. Ils sont par ailleurs plus résistants aux attaques dites « Harvest Now, Decrypt Later », consistant à collecter des éléments signés pour tenter de les déchiffrer plus tard.

Pour l’instant, il s’agit de tester la signature de données et de documents, mais Google entend éprouver différentes techniques pour les adapter aux certificats numériques et à la signature de code.

« Même si ce n’est pas pour demain, ceux qui déploient des racines de confiance à longue durée de vie ou qui signent des microprogrammes (firmware) pour des dispositifs gérant des infrastructures critiques devraient envisager dès maintenant des options d’atténuation de ce vecteur de menace », affirme Google Cloud. « Plus tôt nous serons en mesure de sécuriser ces signatures, plus la base de confiance du monde numérique sera résistante ».

HSM : Un échange en cours avec les équipementiers

La prise en charge des deux algorithmes de signature est logicielle. Google Cloud doit encore assurer le stockage de ces clés dans son HSM Cloud et travailler avec les équipementiers afin que son offre Google Cloud External Key Manager et les autres modules matériels les prennent en charge.

À plus long terme, le fournisseur entend offrir des chemins de migrations pour les protocoles d’échanges de clés existants (notamment pour les certificats PKI), de renforcer son infrastructure cloud et de partagerer des techniques à la fois avec la communauté et avec les organismes de normalisation. Il s’engage à prendre en charge l’ensemble des standards PQC du NIST, à commencer par le mécanisme d’encapsulation basé sur des clés asymétriques générées par un algorithme à treillis (FIPS 203, ouvert aux commentaires jusqu’au 7 mars 2025). Le fournisseur entend partager ces implémentations de manière ouverte à travers les frameworks Tink et BoringCrypto.

Depuis ses premiers tests en 2016, et l’application d’une méthode post-quantique pour protéger son protocole de transfert ATLS en interne, Google a maintenant acquis la conviction qu’il doit appliquer cette protection partout où il le peut.

Une autre guerre de clocher ? 

Toutefois, le gros du travail consiste à assurer l’interopérabilité des techniques développées par Google avec le reste du monde. Et vice-versa.

Ainsi, pour le moment, GCP a décidé de ne pas proposer des API prenant en charge l’hybridation des techniques de signatures numériques traditionnelles avec celles post-quantiques.

« Si beaucoup d’entre nous pensent que l’hybridation est le bon choix pour mitiger les risques, le fait que la communauté n’arrive pas à se décider […] provoque des risques d’interopérabilité et ralentit le déploiement du chiffrement post-quantique », déclarait Jennifer Fernick, alors ingénieur sécurité senior responsable du chiffrement chez Google cloud en mars 2024.

Près d’un an plus tard, le NIST et la communauté n’auraient pas encore trouvé de consensus pour favoriser ces combinaisons, ce qui ne devrait pas tarder, selon Google Cloud. Il s’agit, entre autres, d’assurer une forme d’interopérabilité du chiffrement post-quantique avec les protocoles TLS et x509.

Google Cloud n’est pas le seul à s’engager sur la voie du « pan post-quantique ». En décembre 2024, AWS a présenté son plan pour faire de même, en commençant par tester les standards du NIST avant de tenter de les implémenter. AWS a déjà mis en place un mécanisme hybride pour sa couche TLS, mais en utilisant un algorithme symétrique AES-GCM 256 bits, qui n’est pas une solution post-quantique à proprement parler.

Microsoft expliquait ce même mois participer avec l’IETF (Internet Engineering Task Force) au développement de protocoles d’échanges de clés et d’authentification basée sur les algorithmes ML-DSA et SLH-DSA pour les implanter dans Microsoft Schannel (TLS/SSL) et dans le framework SymCrypt for OpenSSL.

Eviden prend également en charge les algorithmes de la famille CHRYSTALS-DILITHIUM à l’aide de son service HMaaS.