Gestione chiavi AES / Come scambiare la chiave di crittografia

Le chiavi di crittografia possono avere un cryptoperiod dopo il quale queste chiavi non devono continuare a essere utilizzate per la crittografia. Ciò potrebbe essere dovuto a politiche di sicurezza, a causa di un individuo che conosce un componente chiave che lascia l'azienda, a causa del sospetto di una violazione della chiave di crittografia, ecc.

Spesso, un'azienda utilizza una chiave di crittografia (chiamiamola chiaveA) per la crittografia per il periodo X. Dopo questo periodo di tempo verrà generata e utilizzata per la crittografia una nuova chiave di crittografia (chiameremo questa chiaveB). I dati crittografati verranno archiviati con un riferimento alla chiave con cui è stato crittografato, in modo che l'applicazione sappia quale chiave utilizzare per la decrittografia. Utilizzando la nostra denominazione precedente, la chiave A potrebbe essere considerata non valida per la crittografia dei nuovi dati, ma potrebbe essere utilizzata per la decrittografia dei dati crittografati utilizzando tale chiave. KeyB potrebbe attualmente essere valido sia per la crittografia che per la decrittografia dei dati.

Poiché i tuoi dati vengono probabilmente archiviati in base ai periodi di conservazione dei dati definiti, una volta eliminati i dati precedenti, è possibile rimuovere anche le chiavi precedenti in quanto non più necessarie per la decrittografia dei dati.

Per il tuo post, decifrare e ricodificare grandi volumi di dati può richiedere molto tempo e costare molto.

Perché non esegui la crittografia di decodifica su richiesta?

Non sono sicuro che funzioni per il tuo caso, ma qui sono i miei pensieri. I dati originariamente arrivano alla tua applicazione web come semplici dati, giusto? Quindi crittografare i dati e archiviarli. Assumiamo il seguente scenario

1. Oggi ho caricato il file "My_Data1.txt" sul server che lo hai crittografato utilizzando una chiave AES denominata "X1"
2. "X1" scadrà dopo 90 giorni da oggi, imposta 80 giorni da oggi come tempo di riciclo di "X1"
3. Dopo 20 giorni ho caricato un nuovo file "My_Data2.txt", di nuovo lo criptiamo con "X1"
4. Dopo 80 giorni volevo accedere a "My_Data1.txt", lo decifri utilizzando "X1"
5. Ho apportato alcune modifiche a "My_Data1.txt" quando richiedo di memorizzare di nuovo il file sul tuo server per crittografare "My_Data1.txt" utilizzando una nuova chiave "X2"
6. "X2" scadrà 90 dopo che "X1" è scaduto.
7. Qualsiasi accesso utente ai dati crittografati dopo che il punto di riciclaggio della chiave di crittografia corrente ha attivato la decrittografia con la chiave corrente e crittografato con una nuova chiave.

Questo eviterà la necessità di eseguire un enorme processo di crittografia / decrittografia per tutti i dati memorizzati contemporaneamente.

un'altra opzione

1. Dedicare un altro server per preformare il processo di crittografia / decrittografia o
2. Esegui la crittografia sul lato client (richiede una progettazione molto prudente)

Infine , qual è il requisito di sicurezza dietro questa richiesta. Potremmo essere in grado di suggerire una soluzione migliore per evitare la decrittazione / crittografia intensiva

Passerai attraverso il compito relativamente arduo di decifrare e ricodificare i dati per un solo motivo: ritieni che la chiave crittografica sia stata compromessa, ma i dati non hanno, o il contrario.

Se entrambi i dati e la chiave sono stati compromessi. sei pane tostato Nessuna quantità di modifica delle chiavi ti salverà.

Se una chiave o dati sono stati compromessi, potrebbe essere sensato cambiare la chiave e ricodificare i dati nel caso in cui un utente malintenzionato possa ottenere in qualche modo l'altra metà del puzzle. Tuttavia, questo odore "cambia la tua password ogni 30 giorni, Just In Case.)

Hai menzionato un rischio di decifrare e ricodificare, in particolare un fallimento durante il processo. Riduci questo rischio crittografando i nuovi media. Ma, naturalmente, i vecchi media rimangono, crittografati con la vecchia chiave. Devi distruggere sia i vecchi dati che la vecchia chiave con acido, fuoco e potenti magneti quando il processo è completato, o non hai davvero mitigato alcun rischio. Se si tratta di un sistema online, durante il processo di re-crittografia ci saranno tempi di inattività o di sola lettura. Potrebbero esserci altri rischi.

Se in qualche modo si ruotano le chiavi di crittografia in modo che in qualsiasi momento parte dei dati siano crittografati con una chiave precedente e alcuni con una chiave più recente, come suggerito in un'altra risposta, quindi alcuni dei dati vengono esposti in caso di un compromesso.

Come Gilles ha già scritto, questo sa di sicurezza. Chiunque sia responsabile della politica dovrebbe descrivere i rischi che verranno mitigati attraverso l'implementazione. Puoi quindi esaminare i costi e i rischi nuovi introdotti e prendere una decisione informata.