Nouveautés de RHEL 10.1 en matière de cryptographie post-quantique

En mai 2025, Red Hat Enterprise Linux 10 (RHEL) proposait les premières étapes vers la cryptographie post-quantique (PQC) pour se protéger contre les attaques des ordinateurs quantiques. Ces attaques rendront possibles les compromissions des algorithmes cryptographiques classiques existants, tels que RSA et les courbes elliptiques. Les CRQC (ordinateurs quantiques pertinents sur le plan cryptographique) ne sont pas encore connus, mais cela ne signifie pas que le risque est nul. Par exemple, les attaques de type « Harvest now, decrypt later » n'exigent pas un ordinateur quantique immédiatement ; il suffit qu'un tel ordinateur devienne disponible avant que les données chiffrées stockées ne perdent leur valeur. Selon les données transférées, plusieurs décennies peuvent s'écouler avant que cela ne se produise.

Pour se préparer à un avenir quantique, RHEL 10.1 améliore ses défenses contre ces attaques du type « Harvest now, decrypt later » et introduit des signatures post-quantiques pour ses paquets.

La section suivante couvre les modifications apportées à la cryptographie post-quantique dans le protocole TLS (Transport Layer Security), suivie d'une section qui explique un changement dans les politiques cryptographiques par défaut de RHEL. Saviez-vous que RHEL est la première grande distribution Linux à signer ses paquets à l'aide de clés post-quantiques hybrides ?

La troisième section couvre les détails de ces modifications, avant de se terminer par les étapes suivantes recommandées pour les utilisateurs et les éditeurs de logiciels tiers.

Cryptographie post-quantique dans TLS

Il peut utiliser la cryptographie post-quantique à deux fins : L'échange de clés, qui protège contre les attaques de type « Harvest now, decrypt later », et les signatures, qui préviennent les attaques de type « Machine-in-the-middle » utilisant des ordinateurs quantiques. Depuis la sortie de RHEL 10.1, les applications qui utilisent OpenSSL, GnuTLS, NSS ou le langage de programmation Go prennent en charge l'échange de clés post-quantique par défaut.

Les bibliothèques cryptographiques OpenSSL, GnuTLS et NSS prennent également en charge les signatures et les certificats TLS avec l’algorithme ML-DSA (Module-Lattice-Based Digital Signature Algorithm), un algorithme de cryptographie post-quantique standardisé par le NIST. Notez qu'aucune autorité de certification (AC) publique ne propose actuellement la cryptographie post-quantique, mais il est possible de créer des AC privées ou des certificats auto-signés avec ML-DSA dès aujourd'hui.

Dans RHEL 10.0, nous avons proposé cette fonctionnalité en tant qu'aperçu technologique en raison de l'évolution rapide des normes et des mises en œuvre. Cela change désormais : la cryptographie post-quantique avec le mécanisme d'encapsulation de clés ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) et ML-DSA dans TLS est généralement disponible et entièrement prise en charge dans Go, OpenSSL, GnuTLS et NSS.

Dans la perspective de RHEL 10.1, les développeurs de Red Hat ont mené un effort de test à l'échelle du produit concernant l'échange de clés PQC et les certificats PQC. Ces tests ont permis d'identifier plusieurs problèmes, que les mainteneurs de paquets ont corrigés dans les projets Open Source en amont et en aval dans RHEL. Nous vous encourageons à commencer à tester l'échange de clés PQC hybride dans vos déploiements TLS dès aujourd'hui, et à établir des plans pour les serveurs de certificats TLS classiques/PQC (voir « Creating a post-quantum TLS certificate »).

PQC par défaut

RHEL gère ses paramètres cryptographiques à l'aide de politiques cryptographiques à l'échelle du système, DEFAULT étant la politique standard. Dans RHEL 10.1, cette politique a été modifiée pour activer et privilégier la cryptographie post-quantique par défaut. Ainsi, les connexions TLS et SSH depuis et vers RHEL 10.1 ou version ultérieure utiliseront automatiquement l'échange de clés post-quantique, le cas échéant. Ces deux protocoles sont largement utilisés et assurent probablement la majorité des transferts de données chiffrées, ce qui renforce considérablement la posture de sécurité.

Les applications exécutées sur RHEL 9.7 basées sur OpenSSL ou NSS peuvent également utiliser PQC dans TLS si le module de politique cryptographique à l'échelle du système « PQ » est activé à l'aide de sudo update-crypto-policies --set DEFAULT:PQ.

Pour vérifier la politique utilisée par votre système, exécutez update-crypto-policies --show.

Mises à jour de paquets avec signatures post-quantiques

Enfin, l'équipe de développement de Red Hat travaille à la mise en place de protections contre les attaques basées sur les ordinateurs quantiques pour nos canaux de distribution de logiciels. Il s'agit d'un point important, car les mises à jour de paquets via ces canaux constitueront le moyen par lequel Red Hat fournira de futures évolutions dans la transition post-quantique.

Red Hat Enterprise Linux 10 utilise l'implémentation Sequoia-PGP d'OpenPGP pour vérifier les signatures de paquets. Une spécification permettant d'utiliser le PQC dans OpenPGP en est à ses dernières étapes, et Red Hat a contribué au financement de sa mise en œuvre dans Sequoia-PGP, qui est désormais disponible en tant que version préliminaire. Certains environnements d'exploitation sont soumis à des exigences réglementaires en matière de signature de logiciels de cryptographie post-quantique dans des délais courts. Après avoir effectué des tests approfondis, RHEL 10.1 inclut donc désormais cette mise en œuvre.

Dans le même projet, les outils sq-cryptoki et sq ont acquis la prise en charge de l'accès aux clés post-quantiques via PKCS#11. Cela permet l'intégration avec des modules de sécurité matériels. Red Hat a modernisé son infrastructure de signature, créé une clé de signature post-quantique qui utilise un hybride de ML-DSA-87 et Ed448, et a commencé à signer ses paquets RPM avec cette clé. RHEL est la première et unique grande distribution Linux à atteindre ce jalon.

Le premier paquet signé post-quantique était ipmitool-1.8.19-10.el10_1 dans RHBA-2025:23156 :

# dnf download ipmitool ipmitool-1.8.19-10.el10_1.aarch64.rpm                                                                                                                                                                            # rpm -Kv ipmitool-1.8.19-10.el10_1.aarch64.rpm | head -3 ipmitool-1.8.19-10.el10_1.aarch64.rpm:     Header V6 ML-DSA-87+Ed448/SHA512 Signature, key ID 05707a62: OK     Header V4 RSA/SHA256 Signature, key ID fd431d51: OK

Notez que ce paquet est toujours signé par notre clé RSA. Les systèmes qui comprennent le format d'en-tête RPM 6 et les signatures OpenPGP v6 vérifient à la fois les signatures RSA et PQC. Les systèmes plus anciens ne valident que la signature RSA classique.

Conclusion

Red Hat a franchi des étapes importantes dans sa transition post-quantique afin de préparer ses clients aux risques et aux exigences réglementaires à venir. Le TLS avec échange de clés hybride ML-KEM n'est plus en aperçu technologique et peut désormais atténuer les attaques de type « Harvest now, decrypt later » dès aujourd'hui. La prise en charge des certificats et des signatures ML-DSA dans les bibliothèques cryptographiques principales de RHEL (OpenSSL, GnuTLS et NSS) est également désormais disponible.

En conformité avec les récentes initiatives de l'industrie (par exemple, la loi européenne sur la cyberrésilience) en faveur de la sécurité par défaut, la configuration standard a été modifiée pour activer et privilégier les algorithmes post-quantiques dans TLS et SSH. D’autres protocoles suivront à l’avenir. Nous encourageons tous nos utilisateurs à déployer l'échange de clés PQC et à tester les configurations de certificats TLS classiques/PQC avec leurs serveurs TLS. Vous souhaiterez peut-être également découvrir comment préparer votre entreprise à un avenir quantique.

Enfin, RHEL est la première grande distribution à ajouter des signatures post-quantiques hybrides à ses paquets. Pour nos partenaires, mon collègue Jakub Jelen a documenté comment signer des paquets RPM avec des clés post-quantiques. L'intégration avec des modules de sécurité matériels via PKCS#11 3.2 est déjà possible aujourd'hui pour la signature de RPM. Nos équipes d'assistance et d'ingénierie peuvent vous aider à vous lancer.

Go ne prend actuellement en charge ML-KEM qu'à partir de la version 1.24. La prise en charge de ML-DSA est prévue dans une prochaine version.