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

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

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 (AmazonEFS). L'établissement de clés hybrides post-quantiques SSH introduit des mécanismes d'établissement de clés post-quantiques, qu'il utilise conjointement avec des algorithmes d'échange de clés classiques. SSHles clés 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 de l'informatique quantique à grande échelle dans le futur.

Si votre organisation compte sur la confidentialité à long terme des données transmises via une connexion Transfer Family, vous devez envisager de passer à la cryptographie post-quantique avant que des 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 aux quanta ou post-quantiques. Nous avons mis en œuvre des suites de chiffrement hybrides par échange de clés post-quantiques 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 le billet de blog sur la sécurité post-quantique.

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

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

Le client et le serveur procèdent toujours à un échange de ECDH clés. De plus, le serveur encapsule un secret partagé post-quantique dans la clé KEM publique post-quantique du client, qui est annoncée dans le message d'échange de clés du SSH client. Cette stratégie combine la haute assurance d'un échange de clés classique avec la sécurité des échanges de clés post-quantiques proposés, afin de garantir que les poignées de main sont protégées tant que le secret partagé ECDH ou le secret partagé post-quantique ne peut pas être brisé.

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-quantiques lors des transferts de SFTP fichiers dans AWS Transfer Family. Transfer Family adapte en toute sécurité les transferts de business-to-business fichiers vers les services AWS de stockage à SFTP l'aide d'autres protocoles. SFTPest une version plus sécurisée du protocole de transfert de fichiers (FTP) qui s'exécute surSSH. 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 SFTP données.

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

Pourquoi Kyber ?

AWS s'engage à soutenir des algorithmes standardisés et interopérables. Kyber est le premier algorithme de chiffrement post-quantique sélectionné pour la standardisation par le projet NISTPost-Quantum Cryptography. Certains organismes de normalisation intègrent déjà Kyber dans leurs protocoles. AWS prend déjà en charge Kyber TLS dans certains points de AWS API terminaison.

Dans le cadre de cet engagement, AWS a soumis un projet de proposition à la cryptographie post-quantique qui combine Kyber avec des courbes NIST approuvées, comme P256 IETF pour. SSH Afin de renforcer la sécurité de nos clients, la AWS mise en œuvre de l'échange de clés post-quantique figure dans SFTP et SSH suit ce projet. Nous prévoyons de prendre en charge les futures mises à jour jusqu'à ce que notre proposition soit adoptée par le 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) peuvent changer au fur et à mesure que le projet évolue vers la standardisation ou lors de la NIST ratification de l'algorithme de Kyber.

Échange de SSH clés hybrides post-quantiques et exigences cryptographiques (140) FIPS

Pour les clients qui ont besoin de FIPS conformité, Transfer Family fournit une cryptographie FIPS approuvée en SSH utilisant la bibliothèque cryptographique open source AWS FIPS certifiée 140, -LC. AWS Les méthodes d'échange de clés hybrides post-quantiques prises en charge dans le document TransferSecurityPolicy-PQ-SSH-FIPS -Experimental-2023-04 de Transfer FIPS Family sont approuvées NISTconformément au SP 800-56Cr2 (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.

Test de l'échange de clés hybride post-quantique dans Transfer Family

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

Activez l'échange de clés hybrides post-quantiques sur votre terminal SFTP

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

Les noms de SSH politique qui prennent en charge l'échange de clés post-quantique sont TransferSecurityPolicy-PQ- -Experimental-2023-04 et -PQ- - SSH -Experimental-2023-04. TransferSecurityPolicy SSH FIPS Pour plus de détails sur les politiques de Transfer Family, consultezPolitiques de sécurité pour AWS Transfer Family.

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

Après avoir sélectionné la bonne SSH politique post-quantique dans votre terminal SFTP Transfer Family, vous pouvez expérimenter la politique post-quantique SFTP dans Transfer Family. Vous pouvez utiliser un SFTP client (tel qu'OQSOpen SSH) qui prend en charge l'échange de clés hybrides post-quantiques en suivant les instructions du projet de spécification susmentionné.

OQSOpen SSH est un fork open source d'Open SSH qui ajoute une cryptographie sécurisée quantique en utilisant. SSH liboqs liboqsest une bibliothèque C open source qui implémente des algorithmes cryptographiques résistants aux quanta. OQSOuvrez SSH et liboqs faites partie du projet Open Quantum Safe (OQS).

Pour tester l'échange de clés hybrides post-quantiques dans Transfer Family SFTP with OQS OpenSSH, vous devez créer OQS Open SSH comme expliqué dans le document du READMEprojet. Après avoir créé OQS OpenSSH, vous pouvez exécuter l'exemple de SFTP client pour vous connecter à votre SFTP point de terminaison (par exemple,s-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 -S ./ssh -v -o \
   KexAlgorithms=ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org \
   -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 :

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

Pour vérifier que l'échange de clés hybride post-quantique a été utilisé lors d'une SSH connexion SFTP à Transfer Family, vérifiez la sortie du client. Vous pouvez éventuellement utiliser un programme de capture de paquets. Si vous utilisez le SSH client Open Quantum Safe Open, le résultat doit ressembler à ce qui suit (en omettant les informations non pertinentes par souci de concision) :

$./sftp -S ./ssh -v -o KexAlgorithms=ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org -i username_private_key_PEM_file username@s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com
OpenSSH_8.9-2022-01_p1, Open Quantum Safe 2022-08, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/lab/openssh/oqs-test/tmp/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com [xx.yy.zz..12] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_8.9-2022-01_
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 /home/lab/.ssh/known_hosts2: No such file or directory
[...]
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes192-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes192-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:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649
[...]
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 AWS.Tranfer.PQ.SFTP.test-endpoint.aws.com ([xx.yy.zz..12]:22) using "publickey".s
debug1: channel 0: new [client-session]
[...]
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 ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org méthode hybride post-quantique et qu'une SFTP session a été établie avec succès.