Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Uso del intercambio híbrido de claves poscuánticas con AWS Transfer Family
Transfer Family admite una opción híbrida de establecimiento de claves poscuánticas para el protocolo Secure Shell (SSH). El establecimiento de claves poscuánticas es necesario porque ya es posible registrar el tráfico de la red y guardarlo para su descifrado en el futuro mediante un ordenador cuántico, lo que se denomina ataque. *store-now-harvest-later*
Puede utilizar esta opción cuando se conecte a Transfer Family para realizar transferencias de archivos seguras hacia y desde el almacenamiento de Amazon Simple Storage Service (Amazon S3) o Amazon Elastic File System (Amazon EFS). El establecimiento híbrido de claves poscuánticas en SSH introduce mecanismos de establecimiento de claves poscuánticas, que utiliza junto con los algoritmos de intercambio de claves clásicos. Con la tecnología actual, las claves SSH creadas con los conjuntos de cifrado clásicos están a salvo de los ataques de fuerza bruta con tecnología actual. Sin embargo, no se espera que el cifrado clásico siga siendo seguro tras la aparición de la computación cuántica a gran escala en el futuro.
Si su organización depende de la confidencialidad a largo plazo de los datos que se transmiten a través de una conexión de Transfer Family, debería considerar un plan para migrar a la criptografía poscuántica antes de que las computadoras cuánticas a gran escala estén disponibles para su uso.
Para proteger los datos cifrados hoy contra posibles ataques futuros, AWS participa con la comunidad criptográfica en el desarrollo de algoritmos cuánticos resistentes o poscuánticos. Hemos implementado conjuntos de cifrado de intercambio de claves híbrido poscuántico en Transfer Family que combinan elementos clásicos y poscuánticos.
Estos conjuntos de cifrado híbridos están disponibles para su uso en las cargas de trabajo de producción en la mayoría de las regiones de AWS . Sin embargo, dado que las características de rendimiento y los requisitos de ancho de banda de los conjuntos de cifrado híbridos son diferentes de los mecanismos clásicos de intercambio de claves, le recomendamos que los pruebe en sus conexiones de Transfer Family.
Obtenga más información sobre la criptografía poscuántica en la entrada del blog sobre la [criptografía poscuántica](https://aws.amazon.com/security/post-quantum-cryptography/).
**Contents**
+ [Acerca del intercambio de claves híbrido poscuántico en SSH](#pq-about-key-exchange)
+ [Cómo funciona el establecimiento de claves híbrido poscuántico en Transfer Family](#pqtls-details)
+ [¿Por qué ML-KEM?](#why-mlkem)
+ [Requisitos criptográficos y de intercambio de claves híbrido poscuántico SSH (FIPS 140)](#pq-alignment)
+ [Prueba del intercambio de claves híbrido poscuántico en Transfer Family](#pq-policy-testing)
+ [Habilite el intercambio de claves híbrido poscuántico en su punto de conexión SFTP](#pq-enable-policy)
+ [Configuración de un cliente SFTP que admita el intercambio de claves híbrido poscuántico](#pq-client-openssh)
+ [Confirmación del intercambio de claves híbrido poscuántico en SFTP](#pq-verify-exchange)
## Acerca del intercambio de claves híbrido poscuántico en SSH
Transfer Family admite conjuntos de cifrado de intercambio de claves híbridos poscuánticos, que utilizan tanto el clásico algoritmo de intercambio de claves [Elliptic Curve Diffie-Hellman (ECDH](https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final)) como el ML-KEM. El ML-KEM es un algoritmo poscuántico de cifrado y establecimiento de claves públicas que el Instituto [Nacional](https://csrc.nist.gov/projects/post-quantum-cryptography) de Estándares y Tecnología (NIST) ha designado como su primer algoritmo estándar de acuerdo de claves poscuánticas.
El cliente y el servidor siguen intercambiando claves ECDH. Además, el servidor encapsula un secreto compartido poscuántico en la clave pública KEM poscuántica del cliente, que se anuncia en el mensaje de intercambio de claves SSH del cliente. Esta estrategia combina la alta seguridad de un intercambio de claves clásico con la seguridad de los intercambios de claves poscuánticos propuestos para ayudar a garantizar que los protocolos de enlace estén protegidos mientras no se pueda descifrar el ECDH o el secreto compartido poscuántico.
## Cómo funciona el establecimiento de claves híbrido poscuántico en Transfer Family
AWS anunció recientemente la compatibilidad con el intercambio de claves poscuánticas en las transferencias de archivos SFTP. AWS Transfer Family Transfer Family escala de forma segura las transferencias de business-to-business archivos a los servicios de AWS almacenamiento mediante SFTP y otros protocolos. SFTP es una versión más segura del Protocolo de File Transfer (FTP) que se ejecuta a través de SSH. La compatibilidad de intercambio de claves poscuántico de Transfer Family eleva el nivel de seguridad para las transferencias de datos a través de SFTP.
El soporte SFTP de intercambio de claves híbrido poscuántico de Transfer Family incluye la combinación de los algoritmos poscuánticos ML-KEM-768 y ML-KEM-1024, con ECDH sobre curvas P256, P384 o Curve25519. Los siguientes métodos de intercambio de claves SSH correspondientes se especifican en [el borrador del intercambio de claves híbrido poscuántico SSH](https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/).
+ `mlkem768nistp256-sha256`
+ `mlkem1024nistp384-sha384`
+ `mlkem768x25519-sha256`
### ¿Por qué ML-KEM?
AWS se compromete a respaldar algoritmos estandarizados e interoperables. [El ML-KEM es el único algoritmo de intercambio de claves poscuánticas estandarizado y aprobado por el proyecto de criptografía poscuántica del NIST.](https://csrc.nist.gov/projects/post-quantum-cryptography) Los organismos de normalización ya están integrando el ML-KEM en los protocolos. AWS ya es compatible con ML-KEM en TLS en algunos puntos finales de API. AWS
Como parte de este compromiso, AWS ha presentado un borrador de propuesta al IETF para la criptografía poscuántica que combina la ML-KEM con curvas aprobadas por el NIST, como la P256 para SSH. Para ayudar a mejorar la seguridad de nuestros clientes, la AWS implementación del intercambio de claves poscuánticas en SFTP y SSH sigue ese borrador. Planeamos admitir actualizaciones futuras hasta que nuestra propuesta sea adoptada por el IETF y se convierta en un estándar.
Los nuevos métodos de intercambio de claves (enumerados en la sección[Cómo funciona el establecimiento de claves híbrido poscuántico en Transfer Family](#pqtls-details)) podrían cambiar a medida que el borrador avance hacia la estandarización.
**nota**
Actualmente, se admite el uso de algoritmos poscuánticos para el intercambio de claves híbridas poscuánticas en TLS AWS KMS (consulte [Uso del TLS poscuántico híbrido con AWS KMS) y puntos finales de API](https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html).AWS Certificate Manager AWS Secrets Manager
### Requisitos criptográficos y de intercambio de claves híbrido poscuántico SSH (FIPS 140)
Para los clientes que requieren el cumplimiento de FIPS, Transfer Family proporciona criptografía aprobada por FIPS en SSH mediante la biblioteca criptográfica de código abierto con certificación AWS FIPS 140, -LC. AWS Los métodos de intercambio de claves híbridos poscuánticos compatibles con el TransferSecurityPolicy -FIPS-2025-03 de Transfer Family están aprobados por la FIPS [según la norma SP 800-56Cr2 del NIST (sección 2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf)). La Oficina Federal de Seguridad de la Información de Alemania ([BSI](https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Quantentechnologien-und-Post-Quanten-Kryptografie/quantentechnologien-und-post-quanten-kryptografie_node.html)) y la Agence nationale de la sécurité des systèmes d'information ([ANSSI](https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/)) de Francia también recomiendan estos métodos de intercambio de claves híbrido poscuántico.
## Prueba del intercambio de claves híbrido poscuántico en Transfer Family
En esta sección, se describen los pasos que debe seguir para probar el intercambio de claves híbrido poscuántico.
1. [Habilite el intercambio de claves híbrido poscuántico en su punto de conexión SFTP](#pq-enable-policy).
1. Utilice un cliente SFTP (por ejemplo, [Configuración de un cliente SFTP que admita el intercambio de claves híbrido poscuántico](#pq-client-openssh)) que admita el intercambio de claves híbrido poscuántico siguiendo las instrucciones de la especificación del borrador mencionado anteriormente.
1. Transfiera un archivo mediante un servidor de Transfer Family.
1. [Confirmación del intercambio de claves híbrido poscuántico en SFTP](#pq-verify-exchange).
### Habilite el intercambio de claves híbrido poscuántico en su punto de conexión SFTP
Puede elegir la política SSH al crear un nuevo punto de conexión de servidor SFTP en Transfer Family o al editar las opciones del algoritmo criptográfico en un punto de conexión SFTP existente. En la siguiente instantánea se muestra un ejemplo de cómo actualizar la política de SSH. Consola de administración de AWS
![\[Muestra la política poscuántica seleccionada para las opciones del algoritmo criptográfico.\]](http://docs.aws.amazon.com/es_es/transfer/latest/userguide/images/post-quantum-policy-choose.png)
**Los nombres de las políticas de SSH que admiten el intercambio de claves poscuánticas son **TransferSecurityPolicy-2025-03 y -FIPS-2025-03**. TransferSecurityPolicy** Para obtener más información sobre las políticas de Transfer Family, consulte [Políticas de seguridad para servidores AWS Transfer Family](security-policies.md).
### Configuración de un cliente SFTP que admita el intercambio de claves híbrido poscuántico
Tras seleccionar la política SSH poscuántica correcta en el punto de conexión SFTP de Transfer Family, puede experimentar con el SFTP poscuántico en Transfer Family. Instale el último cliente OpenSSH (por ejemplo, la versión 9.9) en su sistema local para realizar la prueba.
**nota**
Asegúrese de que su cliente sea compatible con uno o más de los algoritmos ML-KEM enumerados anteriormente. Puede ver los algoritmos compatibles con su versión de OpenSSH ejecutando este comando:. `ssh -Q kex`
Puede ejecutar el cliente SFTP de ejemplo para conectarse a su terminal SFTP (por ejemplo`s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com`) mediante los métodos de intercambio de claves híbridos poscuánticos, como se muestra en el siguiente comando.
```
sftp -v -o \
KexAlgorithms=mlkem768x25519-sha256 \
-i username_private_key_PEM_file \
username@server-id.server.transfer.region-id.amazonaws.com
```
En el siguiente comando, reemplace los elementos siguientes con su propia información:
+ *username\$1private\$1key\$1PEM\$1file*Sustitúyalo por el archivo codificado en PEM de clave privada del usuario de SFTP
+ Sustitúyalo por el nombre de *username* usuario de SFTP
+ *server-id*Sustitúyalo por el ID del servidor de Transfer Family
+ *region-id*Sustitúyalo por la región real en la que se encuentra el servidor de Transfer Family.
### Confirmación del intercambio de claves híbrido poscuántico en SFTP
Para confirmar que se utilizó el intercambio de claves híbrido poscuántico durante una conexión SSH para SFTP a Transfer Family, compruebe la salida del cliente. Si lo desea, puede utilizar un programa de captura de paquetes. Si utiliza el cliente OpenSSH 9.9, el resultado debería tener un aspecto similar al siguiente (omitiendo información irrelevante por motivos de brevedad):
```
% 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>
```
La salida muestra que la negociación con el cliente se llevó a cabo mediante el método híbrido poscuántico `mlkem768x25519-sha256` y que se estableció correctamente una sesión SFTP.