View a markdown version of this page

Uso del intercambio híbrido de claves poscuánticas con AWS Transfer Family - AWS Transfer Family

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). Post-quantum Es necesario establecer la clave porque ya es posible registrar el tráfico de la red y guardarlo para poder descifrarlo en el futuro mediante un ordenador cuántico, lo que se denomina ataque de almacenamiento, ahora, cosecha y más tarde.

Puede usar esta opción cuando se conecte a Transfer Family para realizar transferencias seguras de archivos desde y hacia el almacenamiento de Amazon Simple Storage Service (Amazon S3) o Amazon Elastic File System (Amazon EFS). Post-quantum el establecimiento de claves híbridas en SSH introduce mecanismos de establecimiento de claves poscuánticos, que utiliza junto con los algoritmos clásicos de intercambio de claves. 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 en la actualidad contra posibles ataques futuros, AWS participa con la comunidad criptográfica en el desarrollo de algoritmos poscuánticos o resistentes a la tecnología cuántica. 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 seguridad criptográfica. Post-Quantum

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 algoritmo clásico de intercambio de claves de curva elíptica Diffie-Hellman (ECDH) como. ML-KEM ML-KEMes un algoritmo poscuántico de cifrado de clave pública y establecimiento de claves que el Instituto Nacional 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 su compatibilidad con el intercambio poscuántico de claves en las transferencias de archivos mediante SFTP. AWS Transfer Family Transfer Family escala de forma segura las transferencias de archivos de empresa a empresa a los servicios AWS de 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.

La compatibilidad con el SFTP para el intercambio de claves híbrido poscuántico de Transfer Family incluye la combinación de algoritmos poscuánticos y ML-KEM-768, con ECDH en curvas ML-KEM-1024 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.

  • mlkem768nistp256-sha256

  • mlkem1024nistp384-sha384

  • mlkem768x25519-sha256

¿Por qué? ML-KEM

AWS se compromete a respaldar algoritmos estandarizados e interoperables. ML-KEM es el único algoritmo de intercambio de claves poscuánticas estandarizado y aprobado por el proyecto de criptografía del NIST. Post-Quantum Los organismos de normalización ya se están integrando ML-KEM en los protocolos. AWS ya es compatible con ML-KEM TLS en algunos puntos finales AWS de API.

Como parte de este compromiso, AWS ha presentado un borrador de propuesta al IETF para la criptografía poscuántica que se combina ML-KEM con NIST-approved curvas 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ónCómo funciona el establecimiento de claves híbrido poscuántico en Transfer Family) podrían cambiar a medida que el borrador avance hacia la estandarización.

nota

Post-quantum La compatibilidad con algoritmos está actualmente disponible para el intercambio de claves híbridas poscuánticas en TLS para puntos finales de API AWS KMS (consulte Uso de TLS híbridos poscuánticos con AWS KMS) y puntos finales de API.AWS Gestor de certificados AWS Secrets Manager

Post-quantum requisitos criptográficos y de intercambio de claves SSH híbridas (FIPS 140)

Para los clientes que requieren cumplir con la FIPS, Transfer Family proporciona FIPS-approved criptografía en SSH mediante el uso de la biblioteca criptográfica de código abierto -LC, certificada por la AWS FIPS 140. AWS Los métodos híbridos poscuánticos de intercambio de claves admitidos en la familia TransferSecurityPolicy-FIPS-2025-03 In Transfer cuentan con la aprobación FIPS según el 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) y la Agence nationale de la sécurité des systèmes d'information (ANSSI) 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.

  2. Utilice un cliente SFTP (por ejemplo, Configuración de un cliente SFTP que admita el intercambio de claves híbrido poscuántico) que admita el intercambio de claves híbrido poscuántico siguiendo las instrucciones de la especificación del borrador mencionado anteriormente.

  3. Transfiera un archivo mediante un servidor de Transfer Family.

  4. Confirmación del intercambio de claves híbrido poscuántico en SFTP.

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. La siguiente instantánea muestra un ejemplo en el que Consola de administración de AWS se actualiza la política de SSH.

Muestra la política poscuántica seleccionada para las opciones del algoritmo criptográfico.

Los nombres de las políticas SSH que admiten el intercambio de claves poscuánticas son y. TransferSecurityPolicy-2025-03 TransferSecurityPolicy-FIPS-2025-03 Para obtener más información sobre las políticas de Transfer Family, consulte Políticas de seguridad para AWS Transfer Family servidores.

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. Instala el cliente OpenSSH más reciente (por ejemplo, la versión 9.9) en tu sistema local para realizar pruebas.

nota

Asegúrese de que su cliente admite uno o más de los ML-KEM algoritmos 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 punto final de SFTP (por ejemplos-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_private_key_PEM_fileSustitúyalo por el archivo de clave privada del usuario de SFTP PEM-encoded

  • usernameSustitúyalo por el nombre de usuario de SFTP

  • server-idSustitúyalo por el identificador del servidor de Transfer Family

  • region-idSustitúyalo por el de la región actual 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 ser similar al siguiente (omitiendo la 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.