Sicurezza delle comunicazioni interne - AWS Key Management Service
Creazione delle chiaviHSMlimite di sicurezzaComandi firmati con quorumSessioni autenticate

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

Sicurezza delle comunicazioni interne

I comandi tra gli host o AWS KMS gli operatori del servizio e il HSMs sono protetti tramite due meccanismi illustrati inSessioni autenticate: un metodo di richiesta firmato dal quorum e una sessione autenticata che utilizza un protocollo -service host. HSM

I comandi firmati dal quorum sono progettati in modo che nessun singolo operatore possa modificare le protezioni di sicurezza critiche che forniscono. HSMs I comandi che vengono eseguiti durante le sessioni autenticate aiutano a garantire che solo gli operatori di servizio autorizzati possano eseguire operazioni che coinvolgono le chiavi. KMS Tutte le informazioni segrete relative al cliente sono protette in tutta l'infrastruttura. AWS

Creazione delle chiavi

Per proteggere le comunicazioni interne, AWS KMS utilizza due diversi metodi di definizione delle chiavi. Il primo è definito come C (1, 2, ECC DH) nella Raccomandazione per schemi di definizione di chiavi a coppie che utilizzano la crittografia a logaritmi discreti (revisione 2). Questo schema ha un iniziatore con una chiave di firma statica. L'iniziatore genera e firma una chiave Diffie-Hellman () a curva ellittica effimera, destinata a un destinatario con una chiave di accordo statica. ECDH ECDH Questo metodo utilizza una chiave temporanea e due chiavi statiche utilizzando. ECDH Questa è la derivazione dell'etichetta C (1, 2, DH). ECC Questo metodo viene talvolta chiamato one-pass. ECDH

Il secondo metodo di determinazione delle chiavi è C (2, 2ECC, DH). In questo schema, entrambe le parti dispongono di una chiave di firma statica e generano, firmano e scambiano una chiave ECDH effimera. Questo metodo utilizza due chiavi statiche e due chiavi temporanee, ognuna delle quali utilizza. ECDH Questa è la derivazione dell'etichetta C (2, 2,, DH). ECC Questo metodo viene talvolta chiamato ECDH effimero o. ECDHE Tutte le ECDH chiavi vengono generate sulla curva secp384r1 (-P384). NIST

HSMlimite di sicurezza

Il limite di sicurezza interno di AWS KMS è il. HSM HSMHa un'interfaccia proprietaria e non ha altre interfacce fisiche attive nel suo stato operativo. Durante l'inizializzazione, a un operatore vengono fornite le chiavi crittografiche necessarie per stabilire il suo ruolo nel dominio. HSM I materiali crittografici sensibili di HSM vengono archiviati solo nella memoria volatile e cancellati quando HSM esce dallo stato operativo, inclusi arresti o ripristini intenzionali o non intenzionali.

Le HSM API operazioni vengono autenticate mediante singoli comandi o tramite una sessione riservata con autenticazione reciproca stabilita da un host del servizio.

HSMAPIoperazioni.

Comandi firmati con quorum

I comandi firmati dal quorum vengono emessi dagli operatori a. HSMs In questa sezione viene descritto come i comandi basati su quorum vengono creati, firmati e autenticati. Queste regole sono abbastanza semplici. Ad esempio, per essere autenticato il comando Foo richiede due membri dal ruolo Bar. Per la creazione e la verifica di un comando basato su quorum sono necessari tre passaggi. Il primo passo è la creazione iniziale del comando, il secondo è l'invio ad operatori aggiuntivi per la firma e il terzo è la verifica e l'esecuzione.

Per introdurre i concetti, supponiamo che esista un insieme autentico di chiavi e ruoli pubblici dell'operatore {QOSs} e un insieme di regole di quorum QR = {Commandi, Rule{i, t}} in cui ogni regola è un insieme di ruoli e un numero minimo N {Role, N}. t t Affinché un comando soddisfi la regola del quorum, il set di dati del comando deve essere firmato da un set di operatori elencati in {QOSs} in modo che soddisfino una delle regole elencate per quel comando. Come accennato in precedenza, l'insieme di regole del quorum e degli operatori viene memorizzato nello stato del dominio e nel token di dominio esportato.

In pratica, un firmatario iniziale firma il comando Sig1 = Sign(dOp1, Command). Anche un secondo operatore firma il comando Sig2 = Sign(dOp2, Command) . Il messaggio con doppia firma viene inviato a un utente per l'esecuzione. HSM HSMEsegue quanto segue:

  1. Per ogni firma, estrae la chiave pubblica del firmatario dallo stato del dominio e verifica la firma sul comando.

  2. Verifica che il set di firmatari soddisfi una regola per il comando.

Sessioni autenticate

Le tue operazioni chiave vengono eseguite tra gli host rivolti verso l'esterno e il. AWS KMS HSMs Questi comandi riguardano la creazione e l'uso di chiavi di crittografia e la generazione di numeri casuali sicuri. I comandi vengono eseguiti su un canale autenticato dalla sessione tra gli host del servizio e il. HSMs Oltre alla necessità di autenticità, queste sessioni richiedono la riservatezza. I comandi in esecuzione su queste sessioni includono la restituzione di chiavi di dati in chiaro e messaggi decrittografati destinati all'utente. Per garantire che queste sessioni non possano essere sovvertite tramite man-in-the-middle attacchi, le sessioni vengono autenticate.

Questo protocollo esegue un accordo di autenticazione reciproca tra l'host del servizio ECDHE e l'host. HSM Lo scambio viene avviato dall'host del servizio e completato da. HSM Restituisce HSM inoltre una chiave di sessione (SK) crittografata dalla chiave negoziata e un token chiave esportato che contiene la chiave di sessione. Il token chiave esportato contiene un periodo di validità, dopo il quale l'host del servizio deve rinegoziare una chiave di sessione.

Un service host è un membro del dominio e dispone di una coppia di chiavi per la firma dell'identità (d HOSi, QHOSi) e di una copia autentica delle chiavi pubbliche di identitàHSMs. Utilizza il suo set di chiavi per la firma dell'identità per negoziare in modo sicuro una chiave di sessione che può essere utilizzata tra l'host del servizio e qualsiasi parte del dominio. HSM Ai token chiave esportati è associato un periodo di validità, dopodiché è necessario negoziare una nuova chiave.

HSM-sessioni autenticate dall'operatore del service host.

Il processo inizia con il riconoscimento da parte dell'host del servizio che richiede una chiave di sessione per inviare e ricevere flussi di comunicazione sensibili tra l'host e un HSM membro del dominio.

  1. Un host di servizi genera una ECDH coppia di chiavi temporanea (d1, Q1) e la firma con la sua chiave di identità Sig1 = Sign (DoS, Q). 1

  2. HSMVerifica la firma sulla chiave pubblica ricevuta utilizzando il token di dominio corrente e crea una coppia di ECDH chiavi temporanea (2d, Q). 2 Quindi completa la procedura ECDH-key-exchange conforme alla Raccomandazione per gli schemi di definizione delle chiavi a coppie che utilizzano la crittografia a logaritmi discreti (rivista) per formare una chiave negoziata a 256 bit. AES GCM Genera HSM una nuova chiave di sessione a 256 bit. AES GCM Crittografa la chiave di sessione con la chiave negoziata per formare la chiave di sessione crittografata (). ESK Inoltre, crittografa la chiave di sessione sotto la chiave di dominio come token chiave esportato. EKT Infine, firma un valore restituito con la sua coppia di chiavi di identità Sig 2 = Sign (dHSK, (Q2,ESK,EKT)).

  3. L'host del servizio verifica la firma sulle chiavi ricevute utilizzando il token di dominio corrente. L'host del servizio completa quindi lo scambio di ECDH chiavi secondo la Raccomandazione per gli schemi di definizione delle chiavi a coppie che utilizzano la crittografia a logaritmi discreti (rivista). Successivamente decripta per ottenere la chiave di sessione SK. ESK

Durante il periodo di validità di EKT, l'host del servizio può utilizzare la chiave di sessione negoziata SK per inviare comandi crittografati tramite busta a. HSM Ogni service-host-initiated comando di questa sessione autenticata include. EKT HSMRisponde utilizzando la stessa chiave di sessione negoziata SK.