Supponiamo di avere un database da 18 GB di cui viene eseguito il backup ogni notte scaricando il database e quindi crittografato utilizzando un algoritmo moderno come AES-256. Questo database ha un aggiornamento giornaliero del tasso di circa il 5%.
Il supporto di memorizzazione i backup vengono salvati sulla deduplicazione a livello di blocchi di supporto. Sono interessato a sapere come questo avrebbe un impatto sulla velocità di de-dupe della partizione di backup.
La deduplicazione funziona sulla rilevazione di file o blocchi di dati identici. Tali duplicati si verificano solo con probabilità trascurabile in dati casuali, e i dati crittografati correttamente dovrebbero essere indistinguibili dalla casualità. La crittografia è in grado di garantire riservatezza e ciò include, in particolare, la possibilità di nascondere a chiunque l'intercettazione di due file di dati di origine identici o meno.
In questo senso, la deduplicazione può funzionare su file crittografati solo se il modello di crittografia è indebolito. Questa non è una decisione leggera: nel caso del tuo database, mostra quali "blocchi" sono cambiati e quali non possono essere abbastanza rivelatori su ciò che hai fatto nel tuo database nel frattempo. Il termine generico è analisi del traffico . La pagina di Wikipedia elenca diversi famosi casi militari; l'analisi del traffico è anche molto utile per prevedere le tattiche di business dei concorrenti (ad esempio notando in anticipo i preparativi per il rilascio di nuovi prodotti principali).
Supponendo che si voglia eseguire la deduplicazione a livello di blocco, nonostante le possibili fughe di cui sopra, ci sono buoni modi e cattivi modi per farlo. Per prima cosa è necessario dividere i dati di input in blocchi di dimensioni di blocchi, in realtà un po 'più piccoli a causa della necessità di un'intestazione extra per blocco (per IV e un MAC ). Ogni blocco verrà crittografato separatamente. Ora la parte più difficile è che per la deduplicazione funzioni, gli stessi dati di blocco devono essere ricodificati in modo identico se non cambiano tra le invocazioni, quindi è necessario riutilizzare l'IV. Il riutilizzo del valore IV è un peccato; è mortale quando si usano modi come CTR e in particolare i suoi derivati moderni GCM e EAX . La soluzione qui è una IV calcolata con una funzione unidirezionale dall'offset del blocco nel file e dal suo contenuto; la funzione unidirezionale dovrebbe essere "casuale" e essere codificata, altrimenti gli autori degli attacchi potrebbero tentare una ricerca esauriente sui dati stessi, facendo corrispondere il blocco IV.
Il seguente schema dovrebbe essere sicuro (all'interno del modello indebolito) ma ciò richiederebbe un'analisi attenta:
Ci sono due chiavi K 1 e K 2 (probabilmente derivate da un singolo master chiave con una funzione di derivazione chiave .
Per il numero di blocco i , con dati d , calcola IV = HMAC ( K 1 , i || d ) (l'IV è il risultato di HMAC / SHA-256 sulla concatenazione di i e dei dati d , usando K 1 come chiave - tronca la IV ai suoi primi 128 bit).
Encrypt d con AES, utilizzando IV dal passaggio precedente e il tasto K 2 , in modalità CBC.
Metti insieme IV e il risultato della crittografia in un blocco a dimensione di blocco.
Questo usa CBC e MAC-and-encrypt, che non è "ideale" per quanto riguarda la crittografia, ma è un modello indebolito. Ottieni ciò che chiedi.
Modifica: nota importante: sebbene alcuni HMAC vengano utilizzati qui, ciò non garantisce l'integrità dei dati del blocco. È possibile utilizzare l'IV per la decrittografia e quindi ricalcolare l'IV e verificare se corrisponde a quello nel file; ciò impedirà alterazioni generiche, ma un utente malintenzionato attivo potrebbe comunque sostituire un blocco con una versione precedente di questo stesso blocco. Se hai bisogno di un controllo dell'integrità sui tuoi backup, fai quanto segue: oltre a qualsiasi crittografia e MAC sopra descritto, calcola un MAC o una firma sul file completo e verifica prima di utilizzare il backup (se stai ripristinando un backup, allora presumo che lo leggerai comunque in ogni caso, quindi potresti avere la verifica della MAC o della firma "gratuitamente").
La deduplicazione ama i pattern nei dati, buoni crypto odia i pattern nell'output . Ne consegue che la deduplicazione prima di criptare produrrà risultati di deduplica migliori.
Immagino che tu abbia più copie di backup notturne del database, ed è principalmente l'efficacia della deduplica tra quelle a cui sei interessato.
Alcune modalità di cifratura a blocchi propagheranno le modifiche in avanti (ad esempio CBC): una singola differenza nel primo blocco dell'input produrrà (quasi certamente) un output completamente diverso. Cattivo per la deduplica.
Se la crittografia scelta localizza le modifiche nell'input allo stesso blocco o blocchi (dare o prendere) nell'output, quindi la deduplica può essere efficace.
Blocca cifra modalità contatore (CTR, XTS) do non ha questa proprietà di propagazione, risolvendo così i problemi con l'accesso casuale e la crittografia / decrittografia parallela / concorrente. ( I cifrari del flusso sincrono localizzano anche i cambiamenti nell'input.)
Un IV / nonce / sale modificato (stai usando un salt casuale o IV, giusto?) cambierà (quasi certamente cambierà) ogni singolo blocco. Cattivo per la deduplica.
Se veramente vuoi sacrificare un po 'di sicurezza, dovresti misurare la tua prestazione di deduplicazione usando un IV fisso o sale con AES-256 in modalità CTR per vedere quale sia il vantaggio della deduplicazione.
Per riassumere:
It depends exactly on which mode of AES is in use, worst case for dedupe is if you're either using CBC or a random IV/salt for each backup: there will be (near) zero dedupe gain.
If you're using CTR or XTS modes, and a static IV (not a good plan in general, and definitely not with CTR mode), then you should see reasonable gains.
You'll (almost) never get the same gain compared with unencrypted files: if you have large runs of zeroed or identical blocks (not uncommon in databases) these will not appear as such in the encrypted output (unless you're using something silly like ECB mode). The best you can hope for is dedupe between backup files approaching 95% (and dedupe within each encrypted backup file approaching 0%).
Vedi questi per come vengono risolti questo e altri problemi simili:
Leggi altre domande sui tag storage encryption backup