Gestione chiavi / sistema di archiviazione

Dovresti rielaborare l'intero sistema. È intrinsecamente molto meno sicuro di quanto dovrebbe essere. Non c'è una buona ragione per cui dovresti memorizzare le chiavi di crittografia che potrebbero essere usate per impersonare i tuoi dispositivi sui tuoi server. Piuttosto, dovresti fornire a ciascun dispositivo un certificato firmato (da una CA privata che puoi operare in sicurezza utilizzando le best practice di CA). Ciò ti conferma che a) ogni dispositivo utilizza effettivamente una coppia di chiavi pubblica / privata autorizzata dall'utente e b) ti consente di verificare ogni dispositivo dal certificato pubblico che puoi archiviare in chiaro (o addirittura essere trasmesso dal dispositivo a l'inizio di ogni connessione e non memorizzato sui tuoi server).

Per parlare con i tuoi server, devi solo avere una chiave privata utilizzata per tutte le comunicazioni e una chiave pubblica utilizzata dai dispositivi per verificare il tuo server. AES può ancora essere utilizzato per le singole sessioni tra client e server, ma la chiave può essere generata al volo, scambiata usando il sistema asimmetrico e poi scartata alla fine della sessione.

In questa configurazione, devi solo archiviare da 2 a 4 chiavi in modo sicuro invece di avere bisogno di un'intera infrastruttura per gestire le chiavi il cui unico valore insostituibile è per gli aggressori che stanno cercando di compromettere il tuo sistema.

Aggiornamento: se davvero non è possibile utilizzare un'infrastruttura a chiave distribuita adeguata, sarà necessario utilizzare il concatenamento delle chiavi per ridurre al minimo i dati sensibili. Criptare ciascuna chiave con una chiave master, in modo che possano essere memorizzate in modo sicuro ovunque. Imposta un server estremamente bloccato con la chiave master e assicurati che fornisca servizi di crittografia e decrittografia per il sistema in modo che le chiavi non vengano mai decodificate all'esterno del sistema. Il sistema funzionerebbe quindi come HSM (se è possibile ottenere un HSM effettivo, sarebbe preferibile). Le connessioni verranno inviate a quel sistema insieme alla loro chiave di crittografia crittografata. Il sistema decodifica il traffico e lo restituisce al richiedente. Avrai inoltre bisogno di un qualche tipo di sicurezza per autenticare i servizi che fanno richieste al server di crittografia / decrittografia, anche se le esigenze specifiche in questo caso dipendono in gran parte dal tipo di sicurezza di cui hai bisogno sui dati del tuo sito.

Come AJ Henderson ha menzionato, se è necessario utilizzare le chiavi in questo modo piuttosto che dovrebbero essere memorizzate in un HSM. Se si stanno semplicemente memorizzando le chiavi su un server separato, questo non fornisce molta, se nessuna, sicurezza aggiuntiva. Se uno dei tuoi server è compromesso, devi presupporre che anche gli altri server potrebbero essere compromessi e, una volta che questa macchina è stata compromessa, qualsiasi dato chiave può essere semplicemente letto dall'unità o dalla memoria.

Se le chiavi fossero archiviate in un HSM d'altra parte, sarebbe impossibile per chiunque accedere ai dati chiave, anche se hanno il controllo completo di tutte le macchine host. I dati chiave non possono essere esportati dal modulo (almeno, non senza autorizzazione fisica, a seconda del tipo di HSM), e persino l'accesso fisico all'HSM non consentirebbe la lettura dei dati chiave poiché i dispositivi solitamente utilizzano una qualche forma di invasatura che copre i componenti, in modo tale che qualsiasi tentativo di accedervi distruggerà l'hardware.

A seconda del tipo di HSM che utilizzi, di solito fornisci un'API standard che puoi utilizzare per accedere alle chiavi e alle funzioni di crittografia. Il più comune di questi è PKCS11, che può essere utilizzato da C # attraverso vari wrapper, sebbene ci siano anche CryptoAPI (CAPI) di Microsoft, Capi NextGen (CNG), Java JCE, ecc.