AWS KMS expose ML-KEM pour encapsuler des clés à l’épreuve de l’ordinateur quantique

26 octobre 2026. AWS Key Management Service (KMS) ouvre les clés ML-KEM, le mécanisme d’encapsulation de clés post-quantique standardisé par le NIST sous FIPS 203. Avril 2026. AWS avait déjà activé par défaut le TLS hybride post-quantique à base de ML-KEM sur KMS, Secrets Manager, ACM, Payment Cryptography et S3. Août 2024. Le NIST publiait ses premières normes post-quantiques, FIPS 203 et FIPS 204. Pourquoi c’est important : jusqu’ici, le post-quantique d’AWS était surtout invisible, caché sous le TLS ; désormais, KMS expose la primitive brute d’établissement de clés, et vous pouvez l’intégrer dans votre propre protocole.

Ce que la mise à jour change réellement

Le support ML-KEM de KMS couvre les trois spécifications de FIPS 203 : ML-KEM-512, ML-KEM-768 et ML-KEM-1024. Chacune correspond à un niveau de sécurité croissant, sur le même algorithme à base de réseaux de modules — la famille « lattice » qui résiste aux attaques quantiques là où RSA et ECDH s’effondrent face à l’algorithme de Shor.

Deux opérations nouvelles structurent le tout. L’API Encapsulate prend une clé publique et produit un secret partagé aléatoire de 32 octets ainsi que sa forme chiffrée, le ciphertext. L’API Decapsulate récupère ce secret partagé à partir du ciphertext grâce à la clé privée correspondante. La clé privée est protégée dans des HSM validés FIPS 140-3 niveau 3, et l’API GetPublicKey permet d’exporter la clé publique pour encapsuler localement, avec AWS-LC, OpenSSL ou Bouncy Castle.

La nuance importante tient à la nature du mécanisme. Contrairement à un accord de clé type ECDH — où chaque partie apporte une contribution — un KEM génère le secret à partir de la seule clé publique du destinataire. Le secret retourné est cryptographiquement aléatoire : il peut servir directement de matériau de clé, ou être passé dans une KDF pour dériver plusieurs clés et nonces distincts.

Le flux, en commandes

# 1. Créer une paire de clés ML-KEM-768 (KeyUsage ENCAPSULATE_DECAPSULATE)
aws kms create-key \
  --key-spec ML_KEM_768 \
  --key-usage ENCAPSULATE_DECAPSULATE \
  --description "clé d'encapsulation post-quantique"

# 2. Exporter la clé publique — la clé privée ne sort jamais de KMS
aws kms get-public-key --key-id <key-id> \
  --query PublicKey --output text > mlkem-768.pub

# 3. Côté expéditeur : encapsuler un secret partagé de 32 octets
aws kms encapsulate --key-id <key-id> \
  --encryption-algorithm ML_KEM_768

# 4. Côté destinataire : décapsuler pour retrouver le même secret
aws kms decapsulate --key-id <key-id> \
  --encryption-algorithm ML_KEM_768 \
  --ciphertext-blob fileb://ciphertext.bin

Le ciphertext produit par l’étape 3 circule librement ; seul le destinataire, détenteur de la clé privée dans KMS, peut en retrouver le secret. AWS recommande de vérifier que la clé publique reçue provient bien de la partie attendue avant de l’utiliser pour encapsuler.

Le chaînon manquant : l’hybride

Il manque encore une pièce que l’écosystème attend : un chiffrement hybride « clé en main ». Le brouillon PQ-HPKE de l’IETF (Post-Quantum Hybrid Public Key Encryption) combine en une seule opération l’encapsulation du secret, une KDF pour dériver une clé AES et un IV, puis le chiffrement AES-GCM du message. AWS indique suivre de près cette standardisation, comme remplaçant post-quantique du chiffrement RSA. En attendant, assembler ces briques soi-même est possible — et c’est précisément ce que ML-KEM dans KMS permet de faire proprement.

L’enjeu de l’hybride dépasse la commodité. Le TLS hybride post-quantique déjà activé par AWS combine ML-KEM et une méthode classique (souvent ECDH) : si ML-KEM venait à être cassé demain, la partie classique préserve la confidentialité. Cette prudence se justifie : ML-KEM est jeune, et son déploiement à grande échelle n’a que quelques années d’historique. Un déploiement « natif » — uniquement ML-KEM, sans repli classique — n’a de sens que si vous assumez ce risque.

Pourquoi c’est maintenant, et pas « un jour »

La menace visée a un nom : harvest now, decrypt later — collecter aujourd’hui, déchiffrer plus tard. Un adversaire qui enregistre aujourd’hui vos échanges chiffrés n’a pas besoin d’ordinateur quantique tout de suite : il lui suffit de conserver les données jusqu’à ce que le calcul quantique mûrisse, puis de casser rétroactivement la couche RSA ou ECDH qui protège vos clés de session. Pour des données qui doivent rester confidentielles des années — secrets bancaires, dossiers médicaux, secrets d’État, propriété industrielle — le risque est réel dès maintenant.

Le calendrier réglementaire ajoute une pression concrète. Les schémas de migration post-quantique demandés par les autorités (le NIST aux États-Unis via IR 8547, l’ANSSI en France) fixent des jalons à l’horizon de la fin de la décennie. Une organisation qui attend que le quantique soit là pour migrer a déjà perdu : la fenêtre de collecte a déjà commencé.

Verdict

Le support ML-KEM de KMS n’est pas une nouveauté cosmétique — c’est le moment où AWS cesse de « faire du post-quantique à votre place » et vous donne la brique pour le faire vous-même, dans votre propre transport de clés.

Si vous concevez un protocole ou un système d’échange de clés, adoptez ML-KEM-768 comme spécification par défaut : c’est le juste milieu entre ML-KEM-512 (plus léger, marge plus faible) et ML-KEM-1024 (plus lourd, pour les exigences maximales), et la clé privée reste enfermée dans un HSM FIPS 140-3 niveau 3. Si vous migrez un système RSA de chiffrement de clés, visez l’hybride ML-KEM + méthode classique tant que vos interlocuteurs ne maîtrisent pas encore le post-quantique. Si vous ne faites que du TLS avec les services AWS, le TLS hybride activé par défaut depuis avril 2026 vous couvre déjà — mais vérifiez vos politiques de clés KMS et votre rotation, car une couche de transport protégée ne protège pas un secret mal géré. Dans tous les cas, une règle unique : le post-quantique se migre avant d’en avoir besoin, jamais après.

Références

• AWS What’s New — AWS Key Management Service now supports ML-KEM for post-quantum key encapsulation (26 octobre 2026)
• AWS KMS Developer Guide — Post-quantum keys in AWS KMS
• AWS KMS Developer Guide — ML-KEM key specs
• AWS — AWS Support for Post-Quantum Confidentiality
• NIST — FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST — IR 8547, Transition to Post-Quantum Cryptography Standards