Using hybrid post-quantum key exchange with Amazon Transfer Family - Amazon Transfer Family
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Using hybrid post-quantum key exchange with Amazon Transfer Family

Amazon Transfer Family supports a hybrid post-quantum key establishment option for the Secure Shell (SSH) protocol. Post-quantum key establishment is needed because it's already possible to record network traffic and save it for decryption in future by a quantum computer, which is called a store-now-harvest-later attack.

You can use this option when you connect to Transfer Family for secure file transfers into and out of Amazon Simple Storage Service (Amazon S3) storage or Amazon Elastic File System (Amazon EFS). Post-quantum hybrid key establishment in SSH introduces post-quantum key establishment mechanisms, which it uses in conjunction with classical key exchange algorithms. SSH keys created with classical cipher suites are safe from brute-force attacks with current technology. However, classical encryption isn't expected to remain secure after the emergence of large-scale quantum computing in the future.

If your organization relies on the long-term confidentiality of data passed over a Transfer Family connection, you should consider a plan to migrate to post-quantum cryptography before large-scale quantum computers become available for use.

To protect data encrypted today against potential future attacks, Amazon is participating with the cryptographic community in the development of quantum-resistant or post-quantum algorithms. We've implemented hybrid post-quantum key exchange cipher suites in Transfer Family that combine classic and post-quantum elements.

These hybrid cipher suites are available for use on your production workloads in most Amazon Regions. However, because the performance characteristics and bandwidth requirements of hybrid cipher suites are different from those of classic key exchange mechanisms, we recommend that you test them on your Transfer Family connections.

Find out more about post-quantum cryptography in the Post-Quantum Cryptography security blog post.

About post-quantum hybrid key exchange in SSH

Transfer Family supports post-quantum hybrid key exchange cipher suites, which uses both the classical Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm, and CRYSTALS Kyber. Kyber is a post-quantum public-key encryption and key-establishment algorithm that the National Institute for Standards and Technology(NIST) has designated as its first standard post-quantum key-agreement algorithm.

The client and server still do an ECDH key exchange. Additionally, the server encapsulates a post-quantum shared secret to the client’s post-quantum KEM public key, which is advertised in the client’s SSH key exchange message. This strategy combines the high assurance of a classical key exchange with the security of the proposed post-quantum key exchanges, to help ensure that the handshakes are protected as long as the ECDH or the post-quantum shared secret cannot be broken.

How post-quantum hybrid key establishment works in Transfer Family

Amazon recently announced support for post-quantum key exchange in SFTP file transfers in Amazon Transfer Family. Transfer Family securely scales business-to-business file transfers to Amazon Storage services using SFTP and other protocols. SFTP is a more secure version of the File Transfer Protocol (FTP) that runs over SSH. The post-quantum key exchange support of Transfer Family raises the security bar for data transfers over SFTP.

The post-quantum hybrid key exchange SFTP support in Transfer Family includes combining post-quantum algorithms Kyber-512, Kyber-768, and Kyber-1024, with ECDH over P256, P384, P521, or Curve25519 curves. The following corresponding SSH key exchange methods are specified in the post-quantum hybrid SSH key exchange draft.

  • ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org

  • ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org

  • ecdh-nistp521-kyber-1024r3-sha512-d00@openquantumsafe.org

  • x25519-kyber-512r3-sha256-d00@amazon.com

Note

These new key exchange methods may change as the draft evolves towards standardization, or when NIST ratifies the Kyber algorithm.

Why Kyber?

Amazon is committed to supporting standardized, interoperable algorithms. Kyber is the first post-quantum encryption algorithm selected for standardization by the NIST Post-Quantum Cryptography project. Some standards bodies are already integrating Kyber into protocols. Amazon already supports Kyber in TLS in some Amazon API endpoints.

As part of this commitment, Amazon has submitted a draft proposal to the IETF for post-quantum cryptography that combines Kyber with NIST-approved curves like P256 for SSH. To help enhance security for our customers, the Amazon implementation of the post-quantum key exchange in SFTP and SSH follows that draft. We plan to support future updates to it until our proposal is adopted by the IETF and becomes a standard.

The new key exchange methods (listed in section How post-quantum hybrid key establishment works in Transfer Family) might change as the draft evolves towards standardization or when NIST ratifies the Kyber algorithm.

Note

Post-quantum algorithm support is currently available for post-quantum hybrid key exchange in TLS for Amazon KMS ( see Using hybrid post-quantum TLS with Amazon KMS),Amazon Certificate Manager, and Amazon Secrets Manager API endpoints.

Post-quantum hybrid SSH key exchange and cryptographic requirements (FIPS 140)

For customers that require FIPS compliance, Transfer Family provides FIPS-approved cryptography in SSH by using the Amazon FIPS 140-certified, open-source cryptographic library, Amazon-LC. The post-quantum hybrid key exchange methods supported in the TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 in Transfer Family are FIPS approved according to NIST's SP 800-56Cr2 (section 2). The German Federal Office for Information Security ( BSI) and the Agence nationale de la sécurité des systèmes d'information (ANSSI) of France also recommend such post-quantum hybrid key exchange methods.

Testing post-quantum hybrid key exchange in Transfer Family

This section describes the steps you take to test post-quantum hybrid key exchange.

  1. Enable post-quantum hybrid key exchange on your SFTP endpoint.

  2. Use an SFTP client (such as Set up an SFTP client that supports post-quantum hybrid key exchange) that supports post-quantum hybrid key exchange by following the guidance in the aforementioned draft specification.

  3. Transfer a file using a Transfer Family server.

  4. Confirm post-quantum hybrid key exchange in SFTP.

Enable post-quantum hybrid key exchange on your SFTP endpoint

You can choose the SSH policy when you create a new SFTP server endpoint in Transfer Family, or by editing the Cryptographic algorithm options in an existing SFTP endpoint. The following snapshot shows an example of the Amazon Web Services Management Console where you update the SSH policy.


               Shows the post-quantum policy selected for the Cryptographic algorithm
                  options.

The SSH policy names that support post-quantum key exchange are TransferSecurityPolicy-PQ-SSH-Experimental-2023-04 and TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04. For more details on Transfer Family policies, see Security policies for Amazon Transfer Family servers.

Set up an SFTP client that supports post-quantum hybrid key exchange

After you select the correct post-quantum SSH policy in your SFTP Transfer Family endpoint, you can experiment with post-quantum SFTP in Transfer Family. You can use an SFTP client (such as OQS OpenSSH) ithat supports post-quantum hybrid key exchange by following the guidance in the aforementioned draft specification.

OQS OpenSSH is an open-source fork of OpenSSH that adds quantum-safe cryptography to SSH by using liboqs. liboqs is an open-source C library that implements quantum-resistant cryptographic algorithms. OQS OpenSSH and liboqs are part of the Open Quantum Safe (OQS) project.

To test post-quantum hybrid key exchange in Transfer Family SFTP with OQS OpenSSH, you need to build OQS OpenSSH as explained in the project's README. After you build OQS OpenSSH, you can run the example SFTP client to connect to your SFTP endpoint (for example, s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com) by using the post-quantum hybrid key exchange methods, as shown in the following command.

./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

In the previous command, replace the following items with your own information:

  • Replace username_private_key_PEM_file with the SFTP user's private key PEM-encoded file

  • Replace username with the SFTP user name

  • Replace server-id with the Transfer Family server ID

  • Replace region-id with the actual region where your Transfer Family server is located

Confirm post-quantum hybrid key exchange in SFTP

To confirm that post-quantum hybrid key exchange was used during an SSH connection for SFTP to Transfer Family, check the client output. Optionally, you can use a packet capture program. If you use the Open Quantum Safe OpenSSH client, the output should look similar to the following (omitting irrelevant information for brevity):

$./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>

The output shows that client negotiation occurred using the post-quantum hybrid ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org method and successfully established an SFTP session.