View a markdown version of this page

Utilisation de l'échange de clés post-quantique hybride avec AWS Transfer Family - AWS Transfer Family
À propos de l'échange de clés hybrides post-quantiques en SSHComment l'utiliserComment le tester

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation de l'échange de clés post-quantique hybride avec AWS Transfer Family

Transfer Family prend en charge une option hybride d'établissement de clé post-quantique pour le protocole Secure Shell (SSH). Post-quantum un établissement clé est nécessaire car il est déjà possible d'enregistrer le trafic réseau et de le sauvegarder pour le déchiffrer ultérieurement par un ordinateur quantique, ce que l'on appelle une attaque «   store-now-harvest-later ».

Vous pouvez utiliser cette option lorsque vous vous connectez à Transfer Family pour des transferts de fichiers sécurisés vers et depuis le stockage Amazon Simple Storage Service (Amazon S3) ou Amazon Elastic File System (Amazon EFS). Post-quantum l'établissement de clés hybrides en SSH introduit des mécanismes d'établissement de clés post-quantiques, qu'il utilise conjointement avec des algorithmes classiques d'échange de clés. Les clés SSH créées à l'aide de suites de chiffrement classiques sont protégées contre les attaques par force brute grâce à la technologie actuelle. Cependant, le chiffrement classique ne devrait pas rester sécurisé après l'émergence future de l'informatique quantique à grande échelle.

Si votre organisation compte sur la confidentialité à long terme des données transmises via une connexion Transfer Family, vous devriez envisager un plan de migration vers la cryptographie post-quantique avant que les ordinateurs quantiques à grande échelle ne soient disponibles.

Afin de protéger les données chiffrées aujourd'hui contre d'éventuelles attaques futures, AWS participe avec la communauté cryptographique au développement d'algorithmes résistants ou post-quantiques. Nous avons implémenté des suites de chiffrement hybrides post-quantiques par échange de clés dans Transfer Family qui combinent des éléments classiques et post-quantiques.

Ces suites de chiffrement hybrides peuvent être utilisées sur vos charges de travail de production dans la plupart AWS des régions. Cependant, étant donné que les caractéristiques de performance et les exigences en bande passante des suites de chiffrement hybrides sont différentes de celles des mécanismes d'échange de clés classiques, nous vous recommandons de les tester sur vos connexions Transfer Family.

Pour en savoir plus sur la cryptographie post-quantique, consultez l'article de blog sur la sécurité de la Post-Quantum cryptographie.

À propos de l'échange de clés hybrides post-quantiques en SSH

Transfer Family prend en charge les suites de chiffrement d'échange de clés hybrides post-quantiques, qui utilisent à la fois l'algorithme d'échange de clés classique à courbe elliptique Diffie-Hellman (ECDH) et. ML-KEM ML-KEMest un algorithme de chiffrement et d'établissement de clés post-quantique à clé publique que le National Institute for Standards and Technology (NIST) a désigné comme son premier algorithme standard d'accord de clés post-quantique.

Le client et le serveur continuent à échanger des clés ECDH. En outre, le serveur encapsule un secret partagé post-quantique dans la clé publique KEM post-quantique du client, qui est annoncé dans le message d'échange de clés SSH du client. Cette stratégie associe l'assurance élevée d'un échange de clés classique à la sécurité des échanges de clés post-quantiques proposés, afin de garantir la protection des poignées de main tant que l'ECDH ou le secret partagé post-quantique ne peuvent pas être divulgués.

Comment fonctionne l'établissement de clés hybrides post-quantiques dans Transfer Family

AWS a récemment annoncé la prise en charge de l'échange de clés post-quantique lors des transferts de fichiers SFTP au format. AWS Transfer Family Transfer Family fait évoluer en toute sécurité les transferts de fichiers interentreprises vers les services de AWS stockage à l'aide du protocole SFTP et d'autres protocoles. SFTP est une version plus sécurisée du protocole FTP (File Transfer Protocol) qui s'exécute via SSH. La prise en charge de l'échange de clés post-quantique de Transfer Family élève la barre de sécurité pour les transferts de données via SFTP.

La prise en charge SFTP d'échange de clés hybride post-quantique dans Transfer Family inclut la combinaison d'algorithmes post-quantiques et ML-KEM-768, avec ECDH sur des courbes P256 ML-KEM-1024, P384 ou Curve25519. Les méthodes d'échange de clés SSH correspondantes suivantes sont spécifiées dans le projet d'échange de clés SSH hybride post-quantique.

  • mlkem768nistp256-sha256

  • mlkem1024nistp384-sha384

  • mlkem768x25519-sha256

Pourquoi ? ML-KEM

AWS s'engage à soutenir des algorithmes standardisés et interopérables. ML-KEM est le seul algorithme d'échange de clés post-quantique standardisé et approuvé par le projet de Post-Quantum cryptographie du NIST. Les organismes de normalisation sont déjà en train de les ML-KEM intégrer dans les protocoles. AWS prend déjà ML-KEM en charge le protocole TLS sur certains points de terminaison AWS d'API.

Dans le cadre de cet engagement, AWS a soumis un projet de proposition à l'IETF pour la cryptographie post-quantique qui se combine ML-KEM avec des NIST-approved courbes telles que P256 pour SSH. Afin de renforcer la sécurité de nos clients, la AWS mise en œuvre de l'échange de clés post-quantique dans SFTP et SSH suit ce projet. Nous prévoyons de prendre en charge les futures mises à jour de celui-ci jusqu'à ce que notre proposition soit adoptée par l'IETF et devienne une norme.

Les nouvelles méthodes d'échange de clés (répertoriées dans la sectionComment fonctionne l'établissement de clés hybrides post-quantiques dans Transfer Family) pourraient changer à mesure que le projet évoluera vers la normalisation.

Note

Post-quantum la prise en charge des algorithmes est actuellement disponible pour l'échange de clés hybrides post-quantiques dans TLS pour AWS KMS (voir Utilisation du TLS post-quantique hybride avec AWS KMS) et les points de terminaison d'API AWS Certificate Manager. AWS Secrets Manager

Post-quantum échange de clés SSH hybride et exigences cryptographiques (FIPS 140)

Pour les clients qui ont besoin de la conformité à la norme FIPS, Transfer Family fournit un FIPS-approved chiffrement en SSH en utilisant la bibliothèque cryptographique open source certifiée AWS FIPS 140, -LC. AWS Les méthodes d'échange de clés hybrides post-quantiques prises en charge dans la famille TransferSecurityPolicy-FIPS-2025-03 in Transfer sont approuvées FIPS conformément à la norme SP 800-56Cr2 du NIST (section 2). L'Office fédéral allemand de la sécurité de l'information (BSI) et l'Agence nationale de la sécurité des systèmes d'information (ANSSI) de France recommandent également de telles méthodes d'échange de clés hybrides post-quantiques.

Tester l'échange de clés hybrides post-quantiques dans Transfer Family

Cette section décrit les étapes à suivre pour tester l'échange de clés hybride post-quantique.

  1. Activez l'échange de clés hybride post-quantique sur votre terminal SFTP.

  2. Utilisez un client SFTP (tel queConfigurer un client SFTP qui prend en charge l'échange de clés hybride post-quantique) qui prend en charge l'échange de clés hybrides post-quantiques en suivant les instructions du projet de spécification susmentionné.

  3. Transférez un fichier à l'aide d'un serveur Transfer Family.

  4. Confirmer l'échange de clés hybrides post-quantiques dans SFTP.

Activez l'échange de clés hybride post-quantique sur votre terminal SFTP

Vous pouvez choisir la politique SSH lorsque vous créez un nouveau point de terminaison de serveur SFTP dans Transfer Family, ou en modifiant les options de l'algorithme cryptographique d'un point de terminaison SFTP existant. L'instantané suivant montre un exemple de l' Console de gestion AWS endroit où vous mettez à jour la politique SSH.

Affiche la politique post-quantique sélectionnée pour les options de l'algorithme cryptographique.

Les noms des politiques SSH qui prennent en charge l'échange de clés post-quantiques sont TransferSecurityPolicy-2025-03 et TransferSecurityPolicy-FIPS-2025-03. Pour plus de détails sur les politiques relatives aux transferts familiaux, consultezPolitiques de sécurité pour AWS Transfer Family serveurs.

Configurer un client SFTP qui prend en charge l'échange de clés hybride post-quantique

Après avoir sélectionné la bonne politique SSH post-quantique dans votre terminal SFTP Transfer Family, vous pouvez expérimenter le SFTP post-quantique dans Transfer Family. Installez la dernière version du client OpenSSH (telle que la version 9.9) sur votre système local à des fins de test.

Note

Assurez-vous que votre client prend en charge un ou plusieurs des ML-KEM algorithmes répertoriés précédemment. Vous pouvez consulter les algorithmes pris en charge pour votre version d'OpenSSH en exécutant cette commande :. ssh -Q kex

Vous pouvez exécuter l'exemple de client SFTP pour vous connecter à votre point de terminaison SFTP (par exemples-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com) en utilisant les méthodes d'échange de clés hybrides post-quantiques, comme indiqué dans la commande suivante.

sftp -v -o \
   KexAlgorithms=mlkem768x25519-sha256 \
   -i username_private_key_PEM_file \
   username@server-id.server.transfer.region-id.amazonaws.com

Dans la commande précédente, remplacez les éléments suivants par vos propres informations :

  • Remplacer username_private_key_PEM_file par le fichier de clé PEM-encoded privée de l'utilisateur SFTP

  • Remplacer username par le nom d'utilisateur SFTP

  • Remplacer server-id par l'ID du serveur Transfer Family

  • region-idRemplacez-la par la région dans laquelle se trouve votre serveur Transfer Family

Confirmer l'échange de clés hybrides post-quantiques dans SFTP

Pour confirmer que l'échange de clés hybride post-quantique a été utilisé lors d'une connexion SSH entre SFTP et Transfer Family, vérifiez la sortie du client. Vous pouvez éventuellement utiliser un programme de capture de paquets. Si vous utilisez le client OpenSSH 9.9, la sortie doit ressembler à ce qui suit (en omettant les informations non pertinentes pour des raisons de concision) :

% sftp -o KexAlgorithms=mlkem768x25519-sha256 -v -o IdentitiesOnly=yes -i username_private_key_PEM_file username@s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com
OpenSSH_9.9p2, OpenSSL 3.4.1 11 Feb 2025
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 146: Applying options for *
debug1: Reading configuration data /Users/username/.ssh/bastions-config
debug1: Reading configuration data /opt/homebrew/etc/ssh/ssh_config
debug1: Connecting to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com [xxx.yyy.zzz.nnn] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_9.9
debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1
debug1: compat_banner: no match: AWS_SFTP_1.1
debug1: Authenticating to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com:22 as 'username'
debug1: load_hostkeys: fopen /Users/username/.ssh/known_hosts2: No such file or directory
[...]
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Ic1Ti0cdDmFdStj06rfU0cmmNccwAha/ASH2unr6zX0
[...]
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
[...]
Authenticated to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com ([xxx.yyy.zzz.nnn]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
[...]
Connected to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com.
sftp>

Le résultat montre que la négociation avec le client a eu lieu à l'aide de la mlkem768x25519-sha256 méthode hybride post-quantique et qu'une session SFTP a été établie avec succès.