Come conservare la chiave di crittografia del database derby in HSM?

3

Il database Derby supporta la crittografia con una chiave o una password. Tradizionalmente questa chiave è memorizzata nei file system, ora invece sto cercando di archiviare e proteggere questa chiave nell'HSM, ma non riuscivo a capire come avrei dovuto farlo.

  1. L'approccio più semplice sembra semplicemente mettere la chiave stessa nell'HSM? Quindi all'avvio del server, l'applicazione interrogherà l'HSM per la chiave, la userà per avviare il database Derby e quindi scarterà la chiave. Tuttavia, ho letto che sembra inefficace perché la chiave può essere semplicemente estratta, ma non capisco veramente qual è il problema di sicurezza con questa appraoch, è questo l'approccio che dovrei prendere?

  2. Il secondo modo in cui leggo è la crittografia ibrida, ma non sono sicuro che sia applicabile al mio caso. Genererò una chiave simmetrica, quindi genererò una coppia di chiavi nell'HSM. Quindi utilizzerò la chiave pubblica dell'HSM per crittografare la chiave simmetrica e archiviarla localmente nel file system. All'avvio del server, passerò questa chiave simmetrica crittografata all'HSM per decodificarla utilizzando la chiave privata non estraibile. C'è qualche merito che usa questo approccio o il suo overkill per questo scopo?

Da come ho capito, la maggior parte dell'uso di HSM ruota attorno al fatto di avere mittenti diversi (criptare) e destinatari (decriptare), quindi l'uso di KeyPairs invece delle chiavi simmetriche?

    
posta Phuah Yee Keat 26.09.2014 - 05:41
fonte

2 risposte

1

Ciò che alcuni motori di database fanno è derivare le chiavi nell'HSM e utilizzare chiavi diverse per parti diverse dei dati. Inoltre, possono anche scorrere le chiavi (ad esempio, leggere / decodificare con la chiave A, crittografare / scrivere lo stesso blocco con la chiave B). Queste operazioni sono incorporate nel motore del database e non sono sicuro che Derby si avvicini a quel livello di sofisticazione.

Inoltre, il vantaggio della crittografia del database è che se qualcuno ruba un hard disk (o un backup del DB), non sarà in grado di accedere ai dati.

Questo cambia completamente nel caso in cui un utente malintenzionato acceda al server, dato che sarà in grado di connettersi al database ed estrarre i dati, o in alternativa sarà in grado di eliminare la chiave dalla memoria.

Il mio suggerimento sarebbe (simile al tuo primo punto): usa l'HSM per ricavare una chiave (solo per ottenere la chiave di una HSM mi sembra sporca), e so che questo è solo per prevenire gli scenari che ho menzionato sopra .

    
risposta data 26.09.2014 - 08:58
fonte
1

Puoi utilizzare HSM per archiviare e gestire le tue chiavi, ma dovresti anche essere in grado di utilizzare HSM per eseguire funzioni di crittografia e decrittografia per conto del tuo database o applicazione. Dipende dalle funzionalità disponibili sull'HSM che hai o stai prendendo in considerazione. Ecco alcuni esempi di come potresti usarlo:

1) Memorizza una chiave di crittografia simmetrica all'interno dell'HSM. La tua applicazione / database può richiedere questa chiave dall'HSM e utilizzarla per operazioni di crittografia e decrittografia. Ciò significa che la chiave lascerà l'HSM e sarà disponibile in testo in chiaro per fare il suo lavoro. Questa chiave sarà vulnerabile allo scraping della memoria.

2) Memorizza una chiave di crittografia simmetrica all'interno dell'HSM. L'applicazione / database può inviare dati all'HSM per essere crittografati o decrittografati. In questo caso la chiave non esce mai dall'HSM.

3) Memorizza una chiave di crittografia simmetrica o asimmetrica all'interno dell'HSM. Utilizzare questa chiave di crittografia per crittografare la chiave di crittografia dei dati (DEK). Salva questo crittogramma ovunque tu voglia. Richiedi la chiave di crittografia chiave (KEK) dall'HSM per decrittografare il tuo DEK e utilizzare il tuo DEK per le operazioni di crittografia / decrittografia.

    
risposta data 25.03.2015 - 14:02
fonte

Leggi altre domande sui tag