Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo dello scambio di chiavi post-quantistiche ibrido con AWS Transfer Family
Transfer Family supporta un'opzione ibrida di creazione di chiavi post-quantistiche per il protocollo Secure Shell (SSH). La creazione di chiavi post-quantistiche è necessaria perché è già possibile registrare il traffico di rete e salvarlo per la decrittografia in futuro da parte di un computer quantistico, il che viene chiamato attacco. store-now-harvest-later
Puoi utilizzare questa opzione quando ti connetti a Transfer Family per trasferimenti sicuri di file da e verso lo storage Amazon Simple Storage Service (Amazon S3) o Amazon Elastic File System (Amazon EFS). La creazione di chiavi ibride post-quantistiche in SSH introduce meccanismi di creazione di chiavi post-quantistici, che utilizza in combinazione con i classici algoritmi di scambio di chiavi. Le chiavi SSH create con le suite di crittografia classiche sono protette dagli attacchi di forza bruta con la tecnologia attuale. Tuttavia, non si prevede che la crittografia classica rimanga sicura dopo l'emergere dell'informatica quantistica su larga scala in futuro.
Se la tua organizzazione si affida alla riservatezza a lungo termine dei dati trasmessi tramite una connessione Transfer Family, dovresti prendere in considerazione un piano per migrare alla crittografia post-quantistica prima che i computer quantistici su larga scala diventino disponibili per l'uso.
Per proteggere i dati crittografati oggi da potenziali attacchi futuri, AWS partecipa con la comunità crittografica allo sviluppo di algoritmi quantistici resistenti o post-quantistici. Abbiamo implementato suite di cifratura ibride post-quantistiche a scambio di chiavi in Transfer Family che combinano elementi classici e post-quantistici.
Queste suite di crittografia ibride sono disponibili per l'uso con i carichi di lavoro di produzione nella maggior parte delle regioni. AWS Tuttavia, poiché le caratteristiche prestazionali e i requisiti di larghezza di banda delle suite di crittografia ibride sono diversi da quelli dei classici meccanismi di scambio di chiavi, ti consigliamo di testarli sulle tue connessioni Transfer Family.
Indice
Informazioni sullo scambio di chiavi ibride post-quantistiche in SSH
Transfer Family supporta suite di cifratura a scambio di chiavi ibride post-quantistiche, che utilizzano sia il classico algoritmo di scambio di chiavi Elliptic Curve Diffie-Hellman
Il client e il server effettuano ancora uno scambio di chiavi ECDH. Inoltre, il server incapsula un segreto condiviso post-quantistico nella chiave pubblica KEM post-quantistica del client, pubblicizzata nel messaggio di scambio di chiavi SSH del client. Questa strategia combina l'elevata garanzia di uno scambio di chiavi classico con la sicurezza degli scambi di chiavi post-quantistici proposti, per contribuire a garantire che le strette di mano siano protette finché l'ECDH o il segreto condiviso post-quantistico non possono essere violati.
Come funziona la creazione di chiavi ibride post-quantistiche in Transfer Family
AWS ha recentemente annunciato il supporto per lo scambio di chiavi post-quantistiche nei trasferimenti di file SFTP in. AWS Transfer Family Transfer Family ridimensiona in modo sicuro i trasferimenti di business-to-business file ai servizi di AWS archiviazione utilizzando SFTP e altri protocolli. SFTP è una versione più sicura del File Transfer Protocol (FTP) che funziona su SSH. Il supporto post-quantistico per lo scambio di chiavi di Transfer Family innalza il livello di sicurezza per i trasferimenti di dati tramite SFTP.
Il supporto SFTP per lo scambio di chiavi ibrido post-quantistico in Transfer Family include la combinazione di algoritmi post-quantistici ML-KEM-768 e ML-KEM-1024, con ECDH su curve P256, P384 o Curve25519. I seguenti metodi di scambio di chiavi SSH corrispondenti sono specificati nella bozza di scambio di chiavi SSH ibrida post-quantistica
-
mlkem768nistp256-sha256
-
mlkem1024nistp384-sha384
-
mlkem768x25519-sha256
Perché ML-KEM?
AWS si impegna a supportare algoritmi standardizzati e interoperabili. ML-KEM è l'unico algoritmo di scambio di chiavi post-quantistico standardizzato e approvato dal progetto NIST Post-Quantum Cryptography.
Come parte di questo impegno, AWS ha presentato una bozza di proposta all'IETF per la crittografia post-quantistica che combina ML-KEM con curve approvate dal NIST come P256 per SSH. Per contribuire a migliorare la sicurezza dei nostri clienti, l' AWS implementazione dello scambio di chiavi post-quantistiche in SFTP e SSH segue tale bozza. Abbiamo intenzione di supportarne i futuri aggiornamenti fino a quando la nostra proposta non sarà adottata dall'IETF e diventerà uno standard.
I nuovi metodi di scambio delle chiavi (elencati nella sezioneCome funziona la creazione di chiavi ibride post-quantistiche in Transfer Family) potrebbero cambiare man mano che la bozza si evolve verso la standardizzazione.
Nota
Il supporto di algoritmi post-quantistici è attualmente disponibile per lo scambio di chiavi ibride post-quantistiche in TLS AWS KMS (vedi Utilizzo del TLS ibrido post-quantistico con) e gli endpoint API. AWS KMSAWS Certificate Manager AWS Secrets Manager
Scambio di chiavi SSH ibrido post-quantistico e requisiti crittografici (FIPS 140)
Per i clienti che richiedono la conformità FIPS, Transfer Family fornisce crittografia approvata FIPS in SSH utilizzando la libreria crittografica open source certificata AWS FIPS 140, -LC. AWS I metodi di scambio di chiavi ibridi post-quantistici supportati nel TransferSecurityPolicy -FIPS-2025-03 in Transfer Family sono approvati FIPS secondo
Test dello scambio di chiavi ibride post-quantistiche in Transfer Family
Questa sezione descrive i passaggi da seguire per testare lo scambio di chiavi ibride post-quantistiche.
-
Abilita lo scambio di chiavi ibride post-quantistiche sul tuo endpoint SFTP.
-
Utilizzate un client SFTP (ad esempioConfigura un client SFTP che supporti lo scambio di chiavi ibride post-quantistiche) che supporti lo scambio di chiavi ibride post-quantistiche seguendo le indicazioni contenute nella bozza di specifica sopra menzionata.
-
Trasferisci un file utilizzando un server Transfer Family.
-
Conferma lo scambio di chiavi ibride post-quantistiche in SFTP.
Abilita lo scambio di chiavi ibride post-quantistiche sul tuo endpoint SFTP
È possibile scegliere la politica SSH quando si crea un nuovo endpoint server SFTP in Transfer Family o modificando le opzioni dell'algoritmo crittografico in un endpoint SFTP esistente. L'istantanea seguente mostra un esempio di come si aggiorna la AWS Management Console policy SSH.

I nomi delle policy SSH che supportano lo scambio di chiavi post-quantistiche sono -2025-03 e -FIPS-2025-03. TransferSecurityPolicy TransferSecurityPolicy Per maggiori dettagli sulle politiche di Transfer Family, consultaPolitiche di sicurezza per AWS Transfer Family i server.
Configura un client SFTP che supporti lo scambio di chiavi ibride post-quantistiche
Dopo aver selezionato la politica SSH post-quantistica corretta nell'endpoint SFTP Transfer Family, puoi sperimentare l'SFTP post-quantistico in Transfer Family. Installa il client OpenSSH più recente (ad esempio la versione 9.9) sul tuo sistema locale per eseguire il test.
Nota
Assicurati che il tuo client supporti uno o più degli algoritmi ML-KEM elencati in precedenza. Puoi visualizzare gli algoritmi supportati per la tua versione di OpenSSH eseguendo questo comando:. ssh -Q kex
È possibile eseguire il client SFTP di esempio per connettersi all'endpoint SFTP (ad esempio,s-1111aaaa2222bbbb3.server.transfer.us-west-2.amazonaws.com
) utilizzando i metodi di scambio di chiavi ibridi post-quantistici, come mostrato nel comando seguente.
sftp -v -o \ KexAlgorithms=mlkem768x25519-sha256 \ -i
username_private_key_PEM_file
\username
@server-id
.server.transfer.region-id
.amazonaws.com
Nel comando precedente, sostituite i seguenti elementi con le vostre informazioni:
-
username_private_key_PEM_file
Sostituitelo con la chiave privata dell'utente SFTP (file con codifica PEM) -
Sostituire con il nome utente
username
SFTP -
Sostituisci
server-id
con l'ID del server Transfer Family -
Sostituisci
region-id
con la regione effettiva in cui si trova il tuo server Transfer Family
Conferma lo scambio di chiavi ibride post-quantistiche in SFTP
Per confermare che lo scambio di chiavi ibride post-quantistiche è stato utilizzato durante una connessione SSH per SFTP a Transfer Family, controlla l'output del client. Facoltativamente, è possibile utilizzare un programma di acquisizione di pacchetti. Se si utilizza il client OpenSSH 9.9, l'output dovrebbe essere simile al seguente (omettendo informazioni irrilevanti per brevità):
% 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>
L'output mostra che la negoziazione con il client è avvenuta utilizzando il metodo ibrido post-quantistico e ha stabilito con successo una sessione SFTP. mlkem768x25519-sha256