È sicuro archiviare la chiave crittografata nel database (crittografata da un altro codice)?

Question

È sicuro archiviare la chiave crittografata nel database (crittografata da un altro codice)?

#1 da (3 voti)

1

Voglio migliorare il flusso di crittografia utilizzato dalla mia applicazione. Oggi uso il codice AES mentre la sua chiave e il suo IvBuffer sono codificati nel codice. So che non è sicuro e voglio migliorare questo. Voglio creare un nuovo codice AES mentre la sua chiave sarà archiviata nel database. La chiave sarà crittografata con il vecchio codice AES.

L'applicazione utilizzerà il nuovo codice AES:

Decrittografa la chiave per il nuovo cifrario usando il vecchio codice.
Cifra / decrittografa le informazioni utilizzando il nuovo codice utilizzando la chiave decrittografata.

Il flusso consentirà una più facile rotazione delle chiavi in futuro (posso elaborarlo ma non è correlato alla mia domanda).

In che modo è protetto il processo di crittografia?

Che cosa fare con IvBuffer per il nuovo codice AES? Per memorizzarlo nel database o per inserire codice hardcoded nel codice?

Aggiunto

Capisco dalla risposta che segue che la chiave aggiuntiva hardcoded non migliora la mia sicurezza. Ho bisogno di memorizzare la chiave di crittografia nel database (opzione 7 elencata qui dove memorizzare una chiave per la crittografia? ). Purtroppo non posso usare dispositivi esterni per la memorizzazione delle chiavi e quindi ho bisogno di usare il database.

Domanda se la sicurezza dell'opzione quando la chiave è memorizzata nel testo normale nel database è meglio che l'opzione quando si utilizza una chiave hard codificata aggiuntiva per la stessa chiave memorizzata nel database?

encryption key-management aes decryption initialisation-vector

posta Michael 17.02.2017 - 07:33

fonte

1 risposta

Leggi altre domande sui tag encryption key-management aes decryption initialisation-vector

In che modo WebRTC bypassa un tunnel VPN Perché utilizzare il metodo UUID rispetto all'ID tradizionale?

score 3 · Accepted Answer

Se ti ho capito correttamente, vuoi continuare a usare la vecchia chiave, che rimane codificata, ma usarla solo per crittografare le chiavi AES, che vengono poi utilizzate per crittografare e decrittografare i tuoi dati.

Questo non migliora la tua sicurezza. La vulnerabilità nel tuo vecchio progetto è che la chiave e la IV sono codificate in modo rigido. Se si cripta la nuova chiave con la vecchia chiave, questo aggiunge un ulteriore livello di complessità (perché è necessario gestire più chiavi), ma in realtà non risolve il problema che si è verificato (hardcodifica una chiave). Se si desidera eseguire la rotazione delle chiavi, come si dice, è necessario sostituire la vecchia chiave con quella nuova dopo aver crittografato nuovamente i dati utilizzati per crittografare con il vecchio codice.

Per quanto riguarda l'IV: da un punto di vista crittografico, finché gli IV sono univoci per testo crittografato, questi sono pubblici. Ad esempio, in modalità CBC, IV è solo il primo input che XOR applica al testo normale; per tutti i blocchi successivi, viene utilizzato il testo cifrato del blocco precedente. Ciò che conta è la freschezza.

Alternative a hard-coding

Memorizzare la chiave in un database è meglio perché hai almeno la possibilità di cambiare la chiave in seguito. Se si protegge adeguatamente il database (ad es. Protezione password e crittografia), questa potrebbe essere una soluzione ragionevolmente sicura. Tuttavia, è probabile che sia più facile utilizzare una libreria esistente che memorizza la chiave in un file, protetta con una passphrase. Ciò significherebbe che per accedere ai dati, la tua logica sarebbe costituita da:

ottieni la passphrase
estrai la chiave dal file usando la passphrase
elimina la passphrase dalla memoria
decifrare i dati usando la chiave, criptare e scrivere nuovi dati
elimina la chiave dalla memoria

È probabile che tutte le cose della passphrase vengano fatte usando una libreria. Ti consiglio di aprire una seconda domanda se hai altre domande su questo argomento.