shyrokova - stock.adobe.com

Chiffrement postquantique : Red Hat accélère sa feuille de route

Comme bon nombre d'éditeurs américains, en matière de chiffrement postquantique, Red Hat suit le rythme imprimé par l’Administration américaine. Pour son directeur technique, un long travail attend encore les entreprises concernées.

En marge de la KubeCon ayant lieu à Salt Lake cette semaine, Red Hat a annoncé les mises à jour d’OpenShift, qui passe en v5, et de son système d’exploitation RHEL 9.9 et 10.3.

Un enjeu technique traverse les ajouts à ces produits : la cybersécurité.

En premier lieu, Red Hat s’adapte à la feuille de route dictée par les États-Unis. L’agence de cybersécurité américaine a annoncé au début du mois d’octobre qu’à partir de 2027, les nouvelles solutions que déploient les agences fédérales devront intégrer des mécanismes de chiffrement postquantique. L’Executive Order 14412, publié en juin 2026, impose aux systèmes critiques des agences fédérales de migrer vers des mécanismes postquantique d’ici 2030 (2031 pour la signature cryptographique), et non plus 2035. Le NIST a revu son guide d’adoption à la fin du mois d’octobre.

« Nous sommes donc en mesure d’y répondre grâce à nos algorithmes », indique Chris Wright, directeur technique et vice-président de l’ingénierie chez Red Hat, auprès du MagIT, lors d’un passage à Paris. Oracle et Microsoft prennent des mesures similaires. Certains acteurs, comme Tixeo, dont les solutions sont utilisées par des entreprises issues de secteurs régulés, suivent.

Dans RHEL 10.3 et OpenShift 5, l’éditeur poursuit l’intégration du chiffrement PQC à la chaîne d’outils Go, entamée en 2025 avec OpenShift 4.20.

En disponibilité générale, OpenShift 5 combine ML-KEM 768 (Lattice-Based Key-Encapsulation Mechanism) avec l’algorithme à courbe elliptique X25519 en lien avec l’ensemble des serveurs TLS de la plateforme. Ce dispositif ne fonctionne pleinement qu’avec le protocole TLS 1.3 et est compatible avec TLS 1.2. Ce mécanisme hybride n’est toutefois pas (encore ?) conforme à la norme FIPS. Selon Red Hat, cela permet de sécuriser les communications initiées par le control plane de son orchestrateur, que ce soit en mode cloud ou sur site.

Ce mécanisme doit empêcher les attaques de types « harvest now, decrypt later », rappelle Chris Wright. Celle-ci vise à exfiltrer des données chiffrées, puis de les conserver jusqu’à ce que la puissance de calcul disponible soit suffisante pour briser les enveloppes de chiffrement. En l’occurrence, les ordinateurs quantiques pourront mettre à mal les algorithmes de chiffrement d’ancienne génération.

RHEL 10.3 et OpenShift 5 incluent des « briques de base » pour le chiffrement postquantique

Pour le CTO de Red Hat, ce n’est qu’un début : la filiale d’IBM propose des « briques de base ».

Chris WrightChris Wright, CTO, Red Hat

« Il faut également savoir où ces technologies sont déployées, et procéder aux mises à niveau et conversions nécessaires », souligne Chris Wright. « Bien sûr, nous pouvons nous adapter, mais la manière dont une application ou une infrastructure tire parti des algorithmes de chiffrement nécessite que nos clients procèdent à des changements, et cela commence par ce processus de découverte ».

Là, Red Hat ne peut que conseiller ses clients. Pour l’instant, il peut offrir des rapports plus précis de la conformité des clusters en s’appuyant sur le programme payant Lightwell. Celui-ci débute à peine, mais IBM a déjà annoncé un pipeline de vente équivalent à 700 millions de dollars pour cette offre de sécurisation de projets open source clés, propulsée à l’IA. « Je travaille chez Red Hat depuis près de 21 ans et nous n’avons jamais rien vu de tel, tant par notre capacité à lancer un nouveau produit aussi rapidement que par la réaction des clients et leur adoption du produit », avance Chris Wright.

Dans un même temps, « il existe des recoupements très significatifs entre l’analyse de dépendances logicielles et celle nécessaire pour déterminer où les éléments cryptographiques sont déployés », croit le CTO.

Du fait de la recrudescence des cyberattaques et du renforcement des réglementations, les entreprises sont en effet inventées à produire leur nomenclature logicielle (SBOM) et à la maintenir à jour. Les deux opérations – lister les dépendances logicielles et les clés de chiffrement utilisées – pourraient converger.

Les clients de Red Hat pour qui le chiffrement postquantique deviendra une obligation commencent ce processus d’évaluation. « Cela couvre aussi bien les logiciels que les équipements qui portent les mécanismes de chiffrement », raconte le CTO de Red Hat. « Les fonctionnalités intégrées à la plateforme [OpenShift] permettent aux clients de tester que les algorithmes ne nuisent pas au bon fonctionnement et à la performance de leurs applications ». Selon le directeur technique, c’est une « première phase ».

En préversion technique, OpenShift 5 permet de configurer l’algorithme, la taille des clés et le type de courbes elliptiques employées pour les certificats PKI de la plateforme. Cela sonne comme un préliminaire à la suppression progressive des certificats signés avec des algorithmes RSA, plus sensibles aux attaques quantiques.

RHEL 10.3, lui prend en charge des images « scellées », à savoir un moyen de confirmer au démarrage de Linux que l’OS n’exécute pas des paquets vérolés. Ces images sont signées avec des clés de chiffrement « contrôlées par les clients » de Red Hat. L’éditeur n’a pas encore précisé les algorithmes compatibles.

Un regain d’intérêt pour l’informatique confidentielle à confirmer

D’autres mesures au sein de la distribution Kubernetes concernent l’isolation des charges de travail, notamment liées à l’IA. En août, Red Hat a présenté des conteneurs « confidentiels », à déployer sur des instances bare-metal et un environnement sandbox, dédié aux agents IA. Ces mécanismes s’appuient sur des runtime Kata, des pseudos-conteneurs, réputés pour leur capacité d’isolation. Les conteneurs confidentiels permettent avant tout de chiffrer les poids des modèles s’exécutant en DRAM ou en VRAM. Cette approche sera d’abord utilisée par les fournisseurs de LLM, anticipe le directeur technique de Red Hat.

« Traditionnellement, le calcul confidentiel reposait davantage sur le fait que le propriétaire de l’application ne faisait pas confiance au fournisseur d’infrastructure », rappelle Chris Wright. « En fait, la situation s’est inversée. Ici, l’application, c’est le modèle, et son propriétaire, le laboratoire IA ».

Cette tendance se vérifie par l’acqui-hiring d’Opaque par Anthropic et le développement d’OpenShell chez Nvidia, projet auquel Red Hat participe.

Ce regain d’intérêt des éditeurs, des fournisseurs et de la communauté open source pour les technologies d’informatique confidentielle ne se traduit pas encore en exigence chez tous les clients, considère le directeur technique. Là encore, les plus intéressés sont les sociétés ou les organisations des secteurs réglementés qui doivent exécuter des charges de travail dans des environnements « air-gapped ». « Nous sommes prêts à répondre à ce type d’exigence, mais c’est un écosystème qui doit encore se développer », juge-t-il. Les freins techniques, notamment l’achat de matériel spécifique et le surcoût de performance pourraient toutefois être effacés par un cas d’usage à forte valeur ajoutée : l’IA agentique, s’enthousiasme le directeur technique.

Red Hat OpenShift 5 est en disponibilité générale. RHEL 9.9 et 10.3 sont attendus dans les « prochaines semaines ».

Pour approfondir sur Sécurité des environnements virtuels et des conteneurs