Come creare uno schema / protocollo di distribuzione sicuro delle chiavi?

Naviga le tue risposte
4

Stiamo costruendo una piattaforma di elaborazione dati su Amazon AWS. Archiviamo i dati sensibili nell'S3 (crittografati) e quindi il nodo Amazon EC2 verrà utilizzato per elaborare questi dati. Stiamo pianificando di utilizzare la crittografia ibrida per i dati S3, ad esempio utilizzando simmetriche Data Encryption Keys (DEK) & Key Encryption Keys asimmetrici (KEK) & sarà fatto sul lato client prima di caricare i dati su S3. Il DEK crittografato verrà memorizzato con l'oggetto S3 nei metadati. Il gruppo di dataset e amp; le chiavi saranno diverse per questi set di dati.

Stiamo progettando di costruire un piccolo sistema KMS in grado di distribuire le chiavi ai nodi EC2 quando elaboreranno i dati per decrittografarli. Il KMS sarà ospitato nei nostri locali e il trasferimento delle chiavi avverrà su VPN.

La domanda che stiamo discutendo riguarda il protocollo di distribuzione delle chiavi più adatto da costruire per distribuire le chiavi ai nodi EC2. Stiamo pensando di creare un servizio web utilizzando REST / SSL per distribuire le chiavi, tuttavia poiché non ci sono specifiche WS-Security disponibili per REST, riteniamo che solo REST / SSL non sia sufficiente.

  1. Quale può essere un'implementazione aggiuntiva per rafforzare la sicurezza?
  2. Quali sono i modi per autenticare / fornire il nodo EC2 quando chiama il servizio web REST da cui viene generato?
  3. Ciò che è più adatto: passare il DEK crittografato al webservice & ottenere DEK decrittografato vs semplicemente ottenere KEK dal webservice & utilizzarlo per decrittografare DEK per decrittografare i dati?
  4. Eventuali punti aggiuntivi da considerare?
posta Deepesh M 02.02.2013 - 19:34
fonte

1 risposta

4

Innanzitutto, non è possibile spostare in modo sicuro i dati su una rete non sicura tra due endpoint non attendibili. Per distribuire in modo sicuro qualsiasi cosa , che si tratti di chiavi o immagini Blu-Ray da 100 GB, avrai bisogno di una delle due cose impostate su ciascun endpoint per stabilire una reciproca fiducia reciproca tra i due:

  • Un segreto condiviso (vale a dire una password o una chiave condivisa)
  • La metà di una coppia di chiavi asimmetrica (vale a dire un certificato attendibile)

Secondo, tu dici che stai usando una VPN. L'intero punto di una VPN è trasformare una rete non affidabile in una rete fidata tra due endpoint ormai fidati. Se i tuoi host si autenticano automaticamente e aderiscono alla VPN, hanno già un segreto condiviso o un certificato attendibile.

Supponendo che la tua VPN sia crittografata, i tuoi dati saranno già crittografati in transito tra la tua rete e la rete EC2. Se i tuoi host EC2 possono unirsi alla VPN all'avvio, hanno già abbastanza informazioni per identificarsi come uno dei tuoi host. Se non ci riescono, puoi stabilire la fiducia quando gli host sono collegati manualmente alla VPN da un amministratore.

Una volta che gli endpoint sono stati autenticati per entrare nella rete di fiducia, gli host EC2 possono scambiarsi i certificati, stabilendo un collegamento affidabile fino in fondo. Questo è (sorta) come funziona Kerberos.

Nota che questo non proteggerà i tuoi dati da:

  • Un membro malizioso - ad esempio, uno dei tuoi amministratori di sistema o di rete
  • Programmi che conservano il materiale chiave sugli host EC2 più a lungo del necessario

In terzo luogo, al minimo, per la tua protezione, la tua azienda vorrebbe essere in grado di controllare tutti gli accessi ai materiali chiave in un modo che sia protetto contro un utente malintenzionato con accesso root. Potrebbe inoltre essere necessario verificare tutti gli accessi ai materiali crittografati nel database. Pensa bene a cosa servirebbe per implementarlo.

In quarto luogo, proteggere le tue chiavi a riposo (contro un utente malintenzionato che vuole ottenere la root sul tuo KMS o su qualsiasi host EC2) è un problema completamente diverso, e è ancora più difficile da risolvere rispetto alla protezione delle chiavi in transito tra due host reciprocamente attendibili. Sono stato coinvolto nell'implementazione di una "isola di rete PCI-DSS" in passato, ed è un enorme dolore.

Consiglio vivamente alla tua azienda di assumere un consulente per la sicurezza con esperienza nella configurazione di sistemi di gestione delle chiavi distribuiti. Il problema qui non sono solo i rischi noti: le cose che conosci devi difendere - ma quello che Rumsfeld chiamava notoriamente le "incognite sconosciute" - rischia di non sapere nemmeno di avere.

Come sviluppatore personalmente, non mi fiderei delle mie capacità di progettare e implementare un cripto-sistema completo senza la consulenza esterna di un esperto.

    
risposta data 26.03.2013 - 14:53
fonte

Leggi altre domande sui tag

Come combattere Doxware? Perché è una cattiva idea archiviare il mio file di chiavi ethereum nel mio Google Drive / Dropbox, ecc.