Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden Sie den hybriden Schlüsselaustausch nach dem Quantum mit AWS Transfer Family

Transfer Family unterstützt eine hybride Option zur Einrichtung von Post-Quantum-Schlüsseln für das Secure Shell (SSH) -Protokoll. Post-quantum Die Einrichtung eines Schlüssels ist erforderlich, da es bereits möglich ist, den Netzwerkverkehr aufzuzeichnen und für die future Entschlüsselung durch einen Quantencomputer zu speichern, was als Store-Now-Harvest-Later-Attacke bezeichnet wird.

Sie können diese Option verwenden, wenn Sie eine Verbindung zu Transfer Family herstellen, um sichere Dateiübertragungen in und aus dem Amazon Simple Storage Service (Amazon S3) -Speicher oder Amazon Elastic File System (Amazon EFS) durchzuführen. Post-quantum Die hybride Schlüsseletablierung in SSH führt Mechanismen zur Einrichtung von Schlüsseln ein, die erst nach dem Quantenverfahren eingerichtet wurden. Diese werden in Verbindung mit klassischen Schlüsselaustauschalgorithmen verwendet. SSH-Schlüssel, die mit klassischen Verschlüsselungssammlungen erstellt wurden, sind mit der aktuellen Technologie vor Brute-Force-Angriffen geschützt. Es wird jedoch nicht erwartet, dass die klassische Verschlüsselung nach dem Aufkommen von Quantencomputern in future sicher bleibt.

Wenn Ihr Unternehmen auf die langfristige Vertraulichkeit von Daten angewiesen ist, die über eine Transfer Family Family-Verbindung übertragen werden, sollten Sie einen Plan zur Umstellung auf Post-Quanten-Kryptografie in Betracht ziehen, bevor große Quantencomputer für den Einsatz verfügbar sind.

Um heute verschlüsselte Daten vor möglichen future Angriffen zu schützen, beteiligt AWS sich die Kryptografie-Community an der Entwicklung quantenresistenter oder Post-Quanten-Algorithmen. Wir haben in Transfer Family hybride Verschlüsselungssuiten für den Schlüsselaustausch nach dem Quantenaustausch implementiert, die klassische Elemente und Post-Quantum-Elemente kombinieren.

Diese hybriden Verschlüsselungssammlungen sind in den meisten Regionen für den Einsatz auf Ihren Produktions-Workloads verfügbar. AWS Da sich die Leistungsmerkmale und Bandbreitenanforderungen von Hybrid-Cipher Suites jedoch von denen klassischer Schlüsselaustauschmechanismen unterscheiden, empfehlen wir, sie auf Ihren Transfer Family Family-Verbindungen zu testen.

Weitere Informationen zur Post-Quanten-Kryptografie finden Sie im Blogbeitrag Post-QuantumCryptography Security.

Informationen zum hybriden Schlüsselaustausch in SSH nach der Quantenphase

Transfer Family unterstützt Post-Quantum-Hybrid-Schlüsselaustausch-Verschlüsselungssuiten, die sowohl den klassischen Elliptic Curve Diffie-Hellman (ECDH) -Schlüsselaustauschalgorithmus verwenden, als auch. ML-KEM ML-KEMist ein Algorithmus zur Verschlüsselung und Einrichtung von Schlüsseln nach dem Quantenprozess, den das National Institute for Standards and Technology (NIST) als seinen ersten Standardalgorithmus für die Zeit nach der Quantenschlüsselvereinbarung bezeichnet hat.

Der Client und der Server führen weiterhin einen ECDH-Schlüsselaustausch durch. Darüber hinaus kapselt der Server einen gemeinsamen geheimen Schlüssel für die Zeit nach dem Quantum in den öffentlichen KEM-Schlüssel des Clients ein, der in der SSH-Schlüsselaustauschnachricht des Clients angekündigt wird. Diese Strategie kombiniert die hohe Sicherheit eines klassischen Schlüsselaustauschs mit der Sicherheit des geplanten Schlüsselaustauschs nach dem Quantenaustausch, um sicherzustellen, dass die Handshakes geschützt sind, solange das ECDH oder das gemeinsame geheime Post-Quantum-Geheimnis nicht geknackt werden können.

So funktioniert die Etablierung hybrider Schlüssel nach der Quantenentwicklung in Transfer Family

AWS hat kürzlich die Unterstützung für den Austausch von Schlüsseln nach dem Quantenzugriff bei SFTP-Dateiübertragungen in angekündigt. AWS Transfer Family Transfer Family skaliert sichere Dateiübertragungen von Unternehmen zu AWS Speicherdiensten mithilfe von SFTP und anderen Protokollen. SFTP ist eine sicherere Version des File Transfer Protocol (FTP), das über SSH ausgeführt wird. Die Unterstützung von Transfer Family nach dem Quanten-Schlüsselaustausch legt die Sicherheitslatte für Datenübertragungen über SFTP höher.

Die SFTP-Unterstützung für den Post-Quantum-Hybrid-Schlüsselaustausch in der Transfer Family umfasst die Kombination von Post-Quanten-Algorithmen und mit ECDH über P256- ML-KEM-768 ML-KEM-1024, P384- oder Curve25519-Kurven. Die folgenden entsprechenden Methoden für den SSH-Schlüsselaustausch sind im Entwurf für den Austausch von SSH-Schlüsseln nach dem Quanten-Hybrid-Verfahren spezifiziert.

Warum? ML-KEM

AWS setzt sich für die Unterstützung standardisierter, interoperabler Algorithmen ein. ML-KEM ist der einzige Algorithmus für den Schlüsselaustausch nach dem Quantenaustausch, der vom NIST Post-Quantum Cryptography Project standardisiert und genehmigt wurde. Normungsgremien sind bereits dabei, sich in Protokolle zu integrieren ML-KEM . AWS unterstützt ML-KEM TLS bereits auf einigen AWS API-Endpunkten.

Im Rahmen dieser Verpflichtung AWS hat das Unternehmen der IETF einen Vorschlagsentwurf für Post-Quanten-Kryptografie vorgelegt, der ML-KEM mit NIST-approved Kurven wie P256 für SSH kombiniert wird. Um die Sicherheit für unsere Kunden zu verbessern, folgt die AWS Implementierung des Post-Quantum-Schlüsselaustauschs in SFTP und SSH diesem Entwurf. Wir planen, future Aktualisierungen zu unterstützen, bis unser Vorschlag von der IETF angenommen wird und ein Standard wird.

Die neuen Schlüsselaustauschmethoden (im Abschnitt aufgeführtSo funktioniert die Etablierung hybrider Schlüssel nach der Quantenentwicklung in Transfer Family) könnten sich ändern, wenn sich der Entwurf in Richtung Standardisierung weiterentwickelt.

Post-quantum hybrider SSH-Schlüsselaustausch und kryptografische Anforderungen (FIPS 140)

Für Kunden, die FIPS-Konformität benötigen, bietet Transfer Family FIPS-approved Kryptografie in SSH mithilfe der AWS FIPS 140-zertifizierten Open-Source-Kryptografiebibliothek -LC. AWS Die in Transfer Family unterstützten Methoden für den hybriden Schlüsselaustausch nach dem TransferSecurityPolicy-FIPS-2025-03 Quantenverfahren sind gemäß SP 800-56Cr2 von NIST (Abschnitt 2) FIPS-zugelassen. Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) und die Frankreich Agence nationale de la sécurité des systèmes d'information (ANSSI) empfehlen ebenfalls solche Methoden für den hybriden Schlüsselaustausch nach dem Quantenverfahren.

Testen des hybriden Schlüsselaustauschs nach dem Quantenprozess in der Transfer Family

In diesem Abschnitt werden die Schritte beschrieben, die Sie unternehmen, um den hybriden Schlüsselaustausch nach dem Quantenverfahren zu testen.

Aktivieren Sie den hybriden Schlüsselaustausch nach dem Quantum-Verfahren auf Ihrem SFTP-Endpunkt

Sie können die SSH-Richtlinie auswählen, wenn Sie einen neuen SFTP-Serverendpunkt in Transfer Family erstellen, oder indem Sie die Optionen für den kryptografischen Algorithmus in einem vorhandenen SFTP-Endpunkt bearbeiten. Der folgende Snapshot zeigt ein Beispiel dafür, AWS-Managementkonsole wo Sie die SSH-Richtlinie aktualisieren.

Die SSH-Richtliniennamen, die den Schlüsselaustausch nach dem Quantenvorgang unterstützen, lauten und. TransferSecurityPolicy-2025-03TransferSecurityPolicy-FIPS-2025-03 Weitere Informationen zu den Richtlinien von Transfer Family finden Sie unterSicherheitsrichtlinien für Server AWS Transfer Family.

Richten Sie einen SFTP-Client ein, der den hybriden Schlüsselaustausch nach dem Quantum-Verfahren unterstützt

Nachdem Sie die richtige Post-Quantum-SSH-Richtlinie in Ihrem SFTP Transfer Family-Endpunkt ausgewählt haben, können Sie in Transfer Family mit Post-Quantum-SFTP experimentieren. Installieren Sie zum Testen den neuesten OpenSSH-Client (z. B. Version 9.9) auf Ihrem lokalen System.

Sie können den Beispiel-SFTP-Client ausführen, um eine Verbindung zu Ihrem SFTP-Endpunkt herzustellen (z. B.s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com), indem Sie die Post-Quantum-Methoden für den hybriden Schlüsselaustausch verwenden, wie im folgenden Befehl gezeigt.

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

Ersetzen Sie im vorherigen Befehl die folgenden Elemente durch Ihre eigenen Informationen:

Bestätigen Sie den Hybrid-Schlüsselaustausch nach der Quantum-Implementierung in SFTP

Überprüfen Sie die Client-Ausgabe, um sicherzustellen, dass der hybride Schlüsselaustausch nach dem Quantenverfahren während einer SSH-Verbindung für SFTP zu Transfer Family verwendet wurde. Optional können Sie ein Programm zur Paketerfassung verwenden. Wenn Sie den OpenSSH 9.9-Client verwenden, sollte die Ausgabe etwa wie folgt aussehen (wobei der Kürze halber irrelevante Informationen weggelassen werden):

% 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>

Die Ausgabe zeigt, dass die Client-Verhandlung mithilfe der mlkem768x25519-sha256 Post-Quantum-Hybridmethode stattgefunden hat und erfolgreich eine SFTP-Sitzung eingerichtet wurde.