Questo è in realtà un problema piuttosto complicato senza una soluzione perfetta.
Se il file system era uno, i dati venivano scritti una sola volta e scritti interamente in sequenza, sarebbe stata idonea una singola crittografia CBC dall'inizio alla fine del supporto. È possibile eseguire la decrittografia dell'accesso casuale di CBC, è sufficiente leggere un ulteriore blocco di cifratura. Questo potrebbe funzionare per la crittografia di qualcosa come ISO9660.
Tuttavia, quando sono richieste scritture ad accesso casuale, eseguire una singola crittografia CBC dell'intero supporto non funzionerà.
Metodi di scelta di un IV
Invece si deve cifrare ogni settore con una nuova IV. Questo porta a un nuovo problema, ovvero che i dati crittografati sono più grandi del testo in chiaro. Se il supporto sottostante è stato progettato per essere utilizzato con una crittografia sicura, potrebbe benissimo essere stato progettato per utilizzare settori fisici leggermente più grandi per risolvere il problema. Non ho incontrato nessun media dove sia questo il caso. I CD hanno dimensioni di blocco fisiche insolite, ma i motivi storici per questo non sono correlati alla crittografia.
Di fronte al problema di dove conservare la flebo, sono stati visti vari modi di tagliare gli angoli. Il primo e molto povero approccio era semplicemente usare il numero di settore come IV.
Il numero del settore è prevedibile. E un avversario può facilmente costruire modelli di dati che fanno sì che l'IV nei settori vicini si annulli con i modelli nei dati e si traduca in due settori vicini sul supporto crittografato con testo cifrato esattamente identico. Più prodotti di crittografia di archiviazione hanno avuto questa vulnerabilità.
Un approccio leggermente migliore è quello di crittografare il numero del settore e utilizzarlo come IV. Se si dispone di una singola istantanea del supporto crittografato, non conosco alcun modo per sfruttarlo. Tuttavia, i backup, i settori rimappati su hard disk, il livellamento dell'usura su SSD, l'uso di SAN, ecc. Possono portare a scenari in cui un avversario può vedere più di un testo cifrato crittografato usando la stessa identica IV. A quel punto sarà visibile all'avversario quanti blocchi di codici a partire dall'inizio dei dati sono identici tra le due versioni.
Un approccio ancora migliore consiste nel calcolare un hash crittografico del numero di settore e tutto il testo in chiaro, tranne che nel primo blocco del settore. Quindi crittografare l'hash e utilizzare come IV. Quindi se si utilizza AES che ha una dimensione di blocco di 16 byte e si crittografano settori di 512 byte, si otterrà il numero di settore e 496 byte del settore. Ciò significa che il riutilizzo IV si verifica solo se si scrivono esattamente gli stessi dati con lo stesso identico numero di settore. Questa è ancora una perdita, anche se molto minore rispetto al semplice utilizzo del numero di settore come IV. Sfortunatamente il passaggio hashing aumenta l'utilizzo della CPU per questo approccio.
Utilizzo di un IV casuale
Puoi usare una IV casuale se puoi in qualche modo memorizzare i dati aggiuntivi. Ma se i settori fisici e logici hanno dimensioni identiche, ciò significa che ogni volta che viene scritto un settore di testo normale, è necessario scrivere due settori fisici. Questo è un grosso problema perché se un'operazione di scrittura viene interrotta, si perdono i dati. Scrivere dietro la cache è in grado di affrontare il rallentamento associato a più scritture necessarie, ma rende ancora più pericoloso il rischio di perdita di dati.
L'inserimento nel journal potrebbe risolvere il problema della perdita di dati. Ma a quel punto avresti trasferito molte funzionalità nel livello di crittografia, che avresti normalmente desiderato su un livello diverso.
GBDE è l'unico esempio che conosco dell'uso di un layout del disco in cui ogni settore logico è memorizzato come 512 + 16 byte completi su disco. Ciò significa che ogni 32 settori logici sono memorizzati come 33 settori fisici. Tuttavia, è stato progettato senza il livello di inserimento nel journal, il che significa che esiste il rischio di perdita di dati. Inoltre l'autore di GBDE ha inventato il proprio PRNG che si è rivelato debole, quindi non è un ottimo esempio di come progettare una crittografia di archiviazione.
Alternative a CBC
I molti casi di IVs scarsamente scelti per CBC hanno portato a una percezione abbastanza comune che la CBC sia debole. Per tali motivi sono state prese in considerazione alternative alla CBC per la crittografia di archiviazione. Tuttavia, alcune delle alternative proposte sono ancora peggiori, ad esempio è stato proposto di utilizzare la modalità CTR che genera un blocco temporaneo pseudocasuale. Semplicemente usando questo per cifrare un media, si riuserà a riutilizzare alcune parti del one-time-pad ogni volta che si scrive in un settore che è stato precedentemente scritto.
La maggior parte dell'uso di CBC nella crittografia di archiviazione e tutte le alternative che ho visto hanno una cosa in comune. Codificano un settore logico in testo semplice in un singolo settore di testo cifrato fisico della stessa dimensione. Ciò significa che nessuno di questi può raggiungere la sicurezza semantica.