View a markdown version of this page

Utilizzo dello scambio ibrido di chiavi post-quantistiche con AWS Transfer Family - AWS Transfer Family
Informazioni sullo scambio di chiavi ibrido post-quantistico in SSHCome utilizzarloCome eseguire il test

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 ibrido di chiavi post-quantistiche con AWS Transfer Family

Transfer Family supporta un'opzione ibrida di creazione di chiavi post-quantistiche per il protocollo Secure Shell (SSH). Post-quantum l'istituzione della chiave è necessaria perché è già possibile registrare il traffico di rete e salvarlo per la decrittografia in futuro da parte di un computer quantistico, il cosiddetto 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). Post-quantum la creazione di chiavi ibride in SSH introduce meccanismi di creazione di chiavi post-quantistiche, che utilizza insieme ai classici algoritmi di scambio di chiavi. Le chiavi SSH create con le classiche suite di crittografia sono al sicuro 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 fa affidamento sulla riservatezza a lungo termine dei dati trasmessi tramite una connessione Transfer Family, dovresti prendere in considerazione un piano di migrazione 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, partecipa con la comunità crittografica allo AWS sviluppo di algoritmi quantistici resistenti o post-quantistici. In Transfer Family abbiamo implementato suite ibride di cifratura post-quantistica per lo scambio di chiavi che combinano elementi classici e post-quantistici.

Queste suite di crittografia ibride sono disponibili per l'uso sui 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.

Scopri di più sulla crittografia post-quantistica nel post del blog sulla sicurezza di Cryptography. Post-Quantum

Informazioni sullo scambio di chiavi ibrido post-quantistico in SSH

Transfer Family supporta suite di crittografia a scambio di chiavi ibride post-quantistiche, che utilizzano sia il classico algoritmo di scambio di chiavi Elliptic Curve Diffie-Hellman (ECDH) che. ML-KEM ML-KEMè un algoritmo post-quantistico di crittografia e creazione di chiavi pubbliche che il National Institute for Standards and Technology (NIST) ha designato come primo algoritmo standard post-quantistico per la definizione di chiavi.

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, che viene pubblicizzata nel messaggio di scambio di chiavi SSH del cliente. Questa strategia combina l'elevata sicurezza 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 fintanto che 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 file da azienda a azienda verso i servizi di AWS storage 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 di Transfer Family include la combinazione di algoritmi post-quantistici e ML-KEM-768, con ECDH su P256, di curve P384 o ML-KEM-1024 Curve25519. I seguenti metodi di scambio di chiavi SSH corrispondenti sono specificati nella bozza di scambio di chiavi SSH ibrido post-quantistico. https://datatracker.ietf.org/doc/draft-kampanakis-curdle-ssh-pq-ke/

  • 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 Cryptography. Post-Quantum Gli organismi di standardizzazione si stanno già integrando nei protocolli. ML-KEM AWS supporta già il ML-KEM protocollo TLS in alcuni endpoint AWS API.

Come parte di questo impegno, AWS ha presentato una bozza di proposta all'IETF per la crittografia post-quantistica che si combina ML-KEM con NIST-approved curve come P256 per SSH. Per contribuire a migliorare la sicurezza per i nostri clienti, l' AWS implementazione dello scambio di chiavi post-quantistiche in SFTP e SSH segue questa bozza. Prevediamo di supportarne gli aggiornamenti futuri 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

Post-quantum Il supporto dell'algoritmo è attualmente disponibile per lo scambio di chiavi ibride post-quantistiche in TLS per AWS KMS (vedi Utilizzo di TLS post-quantistico ibrido con) e per gli endpoint API. AWS KMSAWS Certificate Manager AWS Secrets Manager

Post-quantum scambio di chiavi SSH ibrido e requisiti crittografici (FIPS 140)

Per i clienti che richiedono la conformità FIPS, Transfer Family fornisce la FIPS-approved crittografia in SSH utilizzando la libreria crittografica open source certificata AWS FIPS 140, -LC. AWS I metodi di scambio di chiavi ibridi post-quantistici supportati nella famiglia Transfer sono approvati dalla FIPS secondo la norma SP TransferSecurityPolicy-FIPS-2025-03 800-56Cr2 del NIST (sezione 2). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf Anche l'Ufficio federale tedesco per la sicurezza delle informazioni (BSI) e l'Agence nationale de la sécurité des systèmes d'information (ANSSI) della Francia raccomandano questi metodi ibridi di scambio di chiavi post-quantistici. https://www.ssi.gouv.fr/en/publication/anssi-views-on-the-post-quantum-cryptography-transition/

Test dello scambio di chiavi ibrido post-quantistico in Transfer Family

Questa sezione descrive i passaggi da eseguire per testare lo scambio di chiavi ibrido post-quantistico.

  1. Abilita lo scambio di chiavi ibrido post-quantistico sul tuo endpoint SFTP.

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

  3. Trasferisci un file utilizzando un server Transfer Family.

  4. Conferma lo scambio di chiavi ibride post-quantistiche in SFTP.

Abilita lo scambio di chiavi ibrido post-quantistico sul tuo endpoint SFTP

Puoi scegliere la policy SSH quando crei un nuovo endpoint del server SFTP in Transfer Family o modificando le opzioni dell'algoritmo crittografico in un endpoint SFTP esistente. L'istantanea seguente mostra un esempio di dove si aggiorna la Console di gestione AWS politica SSH.

Mostra la politica post-quantistica selezionata per le opzioni dell'algoritmo crittografico.

I nomi delle policy SSH che supportano lo scambio di chiavi post-quantistiche sono e. TransferSecurityPolicy-2025-03 TransferSecurityPolicy-FIPS-2025-03 Per maggiori dettagli sulle politiche di Transfer Family, vedere. Politiche di sicurezza per AWS Transfer Family server

Configura un client SFTP che supporti lo scambio di chiavi ibride post-quantistiche

Dopo aver selezionato la policy SSH post-quantistica corretta nell'endpoint SFTP Transfer Family, potete sperimentare l'SFTP post-quantistico in Transfer Family. Installa il client OpenSSH più recente (come la versione 9.9) sul tuo sistema locale per testarlo.

Nota

Assicurati che il tuo client supporti uno o più degli ML-KEM algoritmi 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 esempios-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:

  • Sostituisci username_private_key_PEM_file con il file della chiave PEM-encoded privata dell'utente SFTP

  • Sostituisci username con il nome utente SFTP

  • Sostituisci server-id con l'ID del server Transfer Family

  • Sostituiscilo region-id con la regione effettiva in cui si trova il server Transfer Family

Conferma lo scambio di chiavi ibride post-quantistiche in SFTP

Per confermare che lo scambio di chiavi ibrido post-quantistico è stato utilizzato durante una connessione SSH da SFTP a Transfer Family, controllate l'output del client. Facoltativamente, è possibile utilizzare un programma di acquisizione dei 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 cliente è avvenuta utilizzando il metodo ibrido post-quantistico e ha stabilito con successo una sessione SFTP. mlkem768x25519-sha256