Google et d’autres organisations, comme le NIST, l’IETF et la NSA, estiment qu’il est crucial de migrer vers la cryptographie post-quantique en raison du risque important posé par un ordinateur quantique cryptographiquement pertinent (CRQC). En août, nous avons annoncé les travaux de Chrome Security visant à protéger les utilisateurs contre les risques des futurs ordinateurs quantiques en s’appuyant sur une nouvelle forme d’échange de clés cryptographiques post-quantiques hybrides, Kyber (ML-KEM). Nous sommes heureux d’annoncer que nous avons activé la dernière spécification provisoire de Kyber par défaut pour TLS 1.3 et QUIC sur toutes les plateformes Chrome pour ordinateurs de bureau à partir de Chrome 124.
Ce déploiement a révélé un certain nombre de bogues préexistants dans plusieurs produits de type boîte intermédiaire TLS. Pour faciliter le déploiement des correctifs, Chrome propose une politique d’entreprise temporaire permettant de se désinscrire.
**L’agilité des certificats pour une transition post-quantique**
La stratégie post-quantique de Chrome donne la priorité à l’échange de clés résistant aux attaques quantiques dans HTTPS et à une plus grande agilité dans les certificats de l’ICP du Web. Bien que l’agilité de l’ICP puisse sembler peu liée, son absence a entraîné des retards importants lors des précédentes transitions cryptographiques et continuera de le faire jusqu’à ce que nous trouvions une solution viable dans ce domaine. Une ICP du Web plus agile est nécessaire pour permettre une transition sûre et fiable vers la cryptographie post-quantique sur le web.
**Échange de clés et authentification dans HTTPS**
Dans le contexte de HTTPS, la cryptographie est principalement utilisée de trois manières différentes :
* **Cryptage/décryptage symétrique** : HTTP est transmis sous forme de données à l’intérieur d’une connexion TLS à l’aide d’un chiffrement authentifié (AEAD) tel que AES-GCM. Ces algorithmes sont généralement considérés comme sûrs contre la cryptanalyse quantique et peuvent rester en place.
* **Échange de clés** : La cryptographie symétrique nécessite une clé secrète. L’échange de clés est une forme de cryptographie asymétrique dans laquelle deux parties peuvent générer mutuellement une clé secrète partagée sur un canal public. Cette clé secrète peut ensuite être utilisée pour le cryptage et le décryptage symétriques. Toutes les formes actuelles d’échange de clés asymétriques standardisées pour une utilisation dans TLS sont vulnérables à la cryptanalyse quantique.
* **Authentification** : Dans HTTPS, l’authentification est principalement réalisée grâce à l’utilisation de signatures numériques, qui sont utilisées pour transmettre l’identité du serveur, l’authentification du protocole d’établissement de liaison et la transparence pour l’émission de certificats. Tous les algorithmes de signature numérique et de clé publique standardisés pour l’authentification dans TLS sont vulnérables à la cryptanalyse quantique.
**Menaces quantiques pour HTTPS**
Cela entraîne deux menaces quantiques distinctes pour HTTPS :
* **Attaques de type « stockage-aujourd’hui-décryptage-plus-tard »** : Un adversaire pourrait stocker le trafic crypté maintenant, attendre qu’un CRQC soit pratique, puis l’utiliser pour décrypter le trafic après coup. Cette menace est relativement urgente, car peu importe quand un CRQC est pratique, la menace provient du stockage des données cryptées maintenant. Se défendre contre cette attaque nécessite que l’échange de clés soit résistant aux attaques quantiques. Le lancement de Kyber dans Chrome permet aux serveurs d’atténuer les attaques de type « stockage-aujourd’hui-décryptage-plus-tard ».
* **Usurpation d’identité par des CRQC** : Une fois qu’un CRQC existe réellement, il pourrait être utilisé pour casser la cryptographie asymétrique utilisée pour l’authentification dans HTTPS. Pour se défendre contre l’usurpation d’identité par un CRQC, nous devons migrer toute la cryptographie asymétrique utilisée pour l’authentification vers des variantes post-quantiques. Cependant, casser l’authentification n’affecte que le trafic généré après la disponibilité des CRQC. En effet, casser l’authentification sur une transcription enregistrée n’aide pas l’attaquant à usurper l’identité d’aucune des parties : la conversation est déjà terminée.
**Agilité des autorités de certification**
Nous pensons que la prochaine étape importante pour l’authentification résistante aux attaques quantiques dans HTTPS est de se concentrer sur l’activation de l' »agilité des ancrages de confiance ». Historiquement, l’ICP publique du web ne pouvait pas déployer de nouveaux algorithmes rapidement. En effet, la plupart des opérateurs de sites fournissent généralement un certificat unique pour tous les clients et navigateurs pris en charge. Ce certificat doit à la fois être émis par une hiérarchie de confiance qui est approuvée par chaque navigateur ou client que l’opérateur du site prend en charge, et le certificat doit être compatible avec chacun de ces clients.
Le modèle de certificat unique rend difficile l’évolution de l’ICP du Web. Au fur et à mesure que les exigences de sécurité changent, les opérateurs de sites peuvent constater qu’il n’y a plus d’intersection entre les certificats approuvés par les clients déployés, les certificats approuvés par les nouveaux clients, les algorithmes pris en charge par les clients déployés et les algorithmes pris en charge par les nouveaux clients (le tout recoupé avec chaque navigateur et magasin racine distinct). Ces clients peuvent aller de différents navigateurs à des versions plus anciennes de ces navigateurs ne recevant pas de mises à jour, en passant par des applications sur des téléviseurs intelligents ou des terminaux de paiement. À mesure que les exigences divergent, les opérateurs de sites doivent choisir entre la sécurité pour les nouveaux clients et la compatibilité avec les anciens clients.
**Expressions de confiance et certificats d’arbre de Merkle**
Pour introduire l’agilité dans TLS, nous avons besoin d’un mécanisme explicite de « négociation d’ancrage de confiance », pour permettre au client et au serveur de déterminer efficacement quel certificat utiliser. Lors de la réunion de l’IETF de novembre 2023 à Prague, Chrome a proposé les « Expressions de confiance » comme mécanisme de négociation d’ancrage de confiance dans TLS. Chrome recherche actuellement les contributions de la communauté sur les expressions de confiance via le processus de l’IETF. Nous pensons que l’objectif de pouvoir déployer proprement plusieurs certificats pour gérer une gamme de clients est beaucoup plus important que les mécanismes spécifiques de la proposition.
À partir de là, nous pouvons explorer des moyens plus efficaces d’authentifier les serveurs, tels que les Certificats d’arbre de Merkle. Nous considérons l’introduction d’un mécanisme d’agilité des ancrages de confiance comme une nécessité pour une authentification post-quantique efficace. L’expérimentation sera extrêmement importante au fur et à mesure du développement des propositions. L’agilité permet également d’utiliser différentes solutions dans différents contextes, plutôt que d’envoyer des données supplémentaires pour le plus petit dénominateur commun : des solutions comme les certificats d’arbre de Merkle et l’élision intermédiaire nécessitent des clients à jour.
**Conclusion**
Compte tenu de ces contraintes, priorités et risques, nous pensons que l’agilité est plus importante que de définir exactement à quoi ressemblera une PKI post-quantique à l’heure actuelle. Nous recommandons de ne PAS standardiser immédiatement ML-DSA dans X.509 pour une utilisation dans l’ICP publique du Web via le Forum CA/Navigateur. Nous prévoyons que ML-DSA, une fois que le NIST aura terminé sa normalisation, jouera un rôle dans une PKI Web post-quantique, mais nous nous concentrons d’abord sur l’agilité. Cela n’empêche pas l’introduction de ML-DSA dans X.509 en tant qu’option pour les PKI privées, qui peuvent fonctionner sur des délais post-quantiques plus stricts et avoir moins de contraintes autour de la taille du certificat, de la latence du protocole d’établissement de liaison, de la transparence d’émission et des points d’extrémité non gérés