Analyse approfondie de la prise en charge de la cryptographie post-quantique dans le plan de contrôle de Red Hat OpenShift 4.20

L'ère de l'informatique quantique approche, et sa colossale puissance de traitement représente une menace majeure pour les bases de la cryptographie de notre monde numérique. Cet article explore les premiers efforts de prise en charge de la cryptographie post-quantique, ou PQC (Post-Quantum Cryptography), dans Red Hat OpenShift 4.20. Il explique la façon dont cette technologie améliore les principaux composants du plan de contrôle de Kubernetes : le serveur d'API, le kubelet, l'ordonnanceur et le gestionnaire du contrôleur. Le composant etcd, qui utilise une ancienne version de Go, n'est ici pas concerné.

La menace quantique

De nos jours, les systèmes de chiffrement à clé publique les plus courants, tels que l'algorithme RSA et la cryptographie sur les courbes elliptiques, forment la base de la sécurité renforcée des communications en ligne. Ces systèmes sont toutefois vulnérables aux attaques émanant des ordinateurs quantiques à grande échelle, qui sont capables de résoudre avec une rapidité alarmante les problèmes mathématiques sur lesquels reposent ces algorithmes. Face à cette situation, des pirates ont déjà lancé des attaques visant à enregistrer le trafic chiffré pour le déchiffrer ultérieurement, une fois qu'ils auront accès à de puissants ordinateurs quantiques. Le défi est le même pour les données au repos, si le pirate parvient à en faire une copie pour les déchiffrer plus tard.

Pour contrer cette menace, le domaine de la PQC a émergé, avec le développement de nouveaux algorithmes cryptographiques qui résistent aux attaques aussi bien classiques que quantiques.

La PQC dans Kubernetes et OpenShift

Red Hat OpenShift est une distribution Kubernetes certifiée par la CNCF (Cloud Native Computing Foundation), et Kubernetes est codé avec le langage de programmation Go. C'est donc avec Go que commence la prise en charge de la PQC dans OpenShift.

Le lancement de la version 1.24 de Go a marqué une étape importante, avec l'introduction de la prise en charge du mécanisme d'échange de clés hybrides X25519MLKEM768. Ce mécanisme combine le protocole classique d'échange de clés Diffie-Hellman basé sur les courbes elliptiques, X25519, et l'algorithme post-quantique ML-KEM-768. Le secret partagé final est dérivé de cette combinaison des deux mécanismes. L'algorithme ML-KEM repose entièrement sur la cryptographie basée sur les réseaux euclidiens pour offrir une résistance aux attaques quantiques. Le mécanisme X25519MLKEM768 offre à la fois la résistance quantique de l'algorithme ML-KEM et la sécurité classique du protocole X25519.

Pour l'heure, cette approche hybride est réellement plus robuste. L'algorithme ML-KEM de base n'a été standardisé qu'en août 2024, ce qui signifie qu'il est considéré comme « jeune » en termes cryptographiques. En cas d'attaque classique et inattendue contre les hypothèses du réseau euclidien de l'algorithme ML-KEM (cryptanalyse normale, pas quantique), les déploiements de l'algorithme de base seraient cassés. Avec le mécanisme hybride, le protocole X25519 va résister.

Le secret partagé qui en résulte pour une session de chiffrement TLS (Transport Layer Security) fournit le niveau de sécurité attendu tant qu'au moins un des algorithmes des composants n'est pas cassé. Il s'agit d'un moyen robuste et tourné vers l'avenir pour introduire la PQC dans l'écosystème.

Application de la PQC au plan de contrôle d'OpenShift

La prise en charge de la PQC dans OpenShift 4.20 n'est pas axée sur la simple configuration d'indicateurs de PQC spécifiques sur chaque composant Kubernetes. Elle se base plutôt sur le renforcement de la communication TLS entre ces composants, qui est possible grâce à la version sous-jacente de Go et à ses bibliothèques de chiffrement.

Voici comment la prise en charge de la PQC renforce la sécurité de la communication entre les principaux composants OpenShift (sauf etcd, qui sera abordé séparément ci-dessous) :

• Serveur d'API : il joue un rôle central dans le plan de contrôle de Kubernetes. Toutes les communications vers et depuis ce serveur constituent un point de sécurité critique. Avec le protocole TLS renforcé par l'algorithme ML-KEM, la communication du plan de contrôle est protégée contre les attaques qui enregistrent le trafic chiffré dans le but de le déchiffrer ultérieurement.
• Kubelet : ce composant qui s'exécute sur chaque nœud communique avec le serveur d'API pour fournir des mises à jour sur l'état du nœud et recevoir les spécifications du pod. Cette communication inclut désormais un échange de clés PQC hybrides pour renforcer la sécurité, permettant de vérifier l'intégrité et la confidentialité de ce lien.
• Ordonnanceur et gestionnaire du contrôleur : ces composants interagissent en permanence avec le serveur d'API pour prendre des décisions d'ordonnancement et gérer l'état du cluster. Ces interactions sont également protégées par le protocole TLS renforcé par l'algorithme ML-KEM, qui augmente la sécurité de la logique et des processus d'exploitation assurant l'exécution des applications.

Le point de vue de Red Hat

Même si de nombreuses réglementations du secteur n'exigent pas de déployer la PQC avant 2035, nous œuvrons activement à la transition. Dans un article récent intitulé « Préparer les entreprises à l'avenir quantique », nous avons insisté sur l'importance de commencer rapidement l'adoption de la PQC. De plus, le travail en cours sur l'intégration la cryptographie post-quantique à Red Hat Enterprise Linux est un indicateur clé de la voie que nous choisissons pour OpenShift. L'inclusion de fonctions PQC dans OpenShift 4.20 constitue une avancée importante.

Incompatibilité avec la version de Go

La version de Go peut entraîner une potentielle incompatibilité entre les différents composants d'un cluster. Par exemple, si un client kubectl créé avec une version de Go compatible avec l'algorithme ML-KEM communique avec un serveur d'API plus ancien, la négociation TLS peut basculer de manière silencieuse vers un algorithme de chiffrement classique. Cette situation entraînerait la perte de la protection de la PQC sans avertissement clair. Il est donc essentiel de vérifier que tous les composants de l'environnement OpenShift exécutent des versions compatibles qui prennent en charge la PQC.

Le cas du composant etcd

Si les principaux composants du plan de contrôle bénéficient du protocole TLS renforcé par l'algorithme ML-KEM, ce n'est pas le cas du composant etcd, qui présente un rôle et des principes de développement spécifiques. Le composant etcd constitue la source de vérité incontestable pour l'ensemble du cluster. Ses priorités sont la stabilité, l'intégrité des données et les performances. Le projet etcd suit intentionnellement un calendrier de gestion des versions plus classique que Kubernetes. Alors que le projet Kubernetes adopte souvent la dernière version de Go pour utiliser rapidement les nouvelles fonctions et améliorer les performances, l'équipe en charge d'etcd privilégie la stabilité en conservant les versions de Go plus anciennes et plus fiables. Ce décalage voulu permet à l'ensemble de la communauté d'examiner en détail les problèmes potentiels dans un nouvel environnement d'exécution Go avant son introduction dans un composant aussi essentiel qu'etcd.

L'absence de prise en charge immédiate de la PQC n'est pas une négligence, mais une conséquence directe de cette approche axée sur la stabilité. Avant la prise en charge officielle dans etcd des algorithmes de PQC introduits dans Go 1.24, cette version de Go doit d'abord être adoptée dans les branches de version stables d'etcd, qui utilisent toujours Go 1.23. Ce processus implique des tests approfondis de validation pour confirmer l'absence d'effets négatifs sur le protocole de consensus Raft, la latence d'E/S ou les opérations de récupération. Nous vous tiendrons au courant de l'évolution de la prise en charge de la PQC dans les prochaines versions d'etcd.

Ce qui nous attend

L'intégration de la PQC à OpenShift 4.20 témoigne de l'approche proactive qu'adopte Red Hat pour préparer l'informatique cloud-native à un avenir quantique. Si la PQC n'en est qu'à ses balbutiements pour les signatures et les certificats numériques, la mise en œuvre de l'échange de clés hybrides dans le protocole TLS reste une première étape essentielle.