Qual è il vantaggio dell'aggiunta della chiave di crittografia dei dati, quindi memorizzarla (crittografata) insieme ai dati

Ti darò un esempio concreto di quando / perché ha senso archiviare la chiave (crittografata) accanto ai dati (mi capita di avere la scheda aperta per rispondere a un'altra domanda, quindi perché no?):

Codifica disco completo Android .

In breve: quando si attiva la Crittografia disco Android, viene generata una chiave AES-128 che viene utilizzata per crittografare l'unità (chiamata chiave master). Quindi prende il tuo Pattern / PIN / Password e lo usa per derivare una seconda chiave AES-128 che usa per crittografare e memorizzare la chiave master sul disco. Sai come la prima cosa che fa Android durante l'avvio è chiedere il tuo PIN / password? Questo perché ha bisogno di decifrare la chiave master in modo che possa decodificare e montare il filesystem principale. La ragione per avere due chiavi AES-128 è che se cambi Pattern / PIN / Password, devi solo crittografare nuovamente il file della chiave master, non l'intero disco.

Un altro buon caso d'uso sono i dati in transito, ad esempio S / MIME o PGP :

Crittografare grandi quantità di dati di testo / allegati con un cifrario asimmetrico (come RSA) è molto lento, quindi ciò che facciamo è crittografare i dati di massa con AES usando una chiave casuale e IV, quindi crittografarli con la chiave pubblica RSA del destinatario e allegare la chiave crittografata AES e IV al massaggio.

In riferimento al tuo punto 2. : il motivo esatto per questa scelta dipende probabilmente dal caso d'uso specifico, ma un vantaggio che ti viene in mente è che puoi rivelare la chiave per una riga a qualcuno - ad esempio un auditor - senza compromettere altre righe nella tabella. Puoi anche inviare i dati a qualcuno senza dover eseguire il lavoro di decrittografia / ricodifica (un grande risparmio se i dati sono grandi o se hai requisiti in tempo reale).

La più grande differenza, (non lo chiamerò un vantaggio) è che se si utilizza una chiave casuale diversa per ogni pezzo di dati, è possibile utilizzare un IV statico e non è necessario memorizzare un IV con ogni pezzo di dati .

Questo non tuttavia, ti offre ulteriore sicurezza rispetto all'opzione 1, utilizzando lo stesso DEK e un IV casuale strong per ogni pezzo di dati.

L'unico vantaggio potenziale (ed è un po 'allungato) è che se i dati sono accessibili indipendentemente, l'esposizione di una chiave di crittografia dei dati (ma non il master KEK) espone solo il singolo pezzo di dati che è crittografato con quel DEK e nessun altro dato. Se questo è uno scenario di minaccia reale per te, allora l'opzione 2 è sicuramente la strada da percorrere. In caso contrario, o se potrebbe essere necessario accedere a molti pezzi di dati contemporaneamente o in rapida successione, l'opzione 1 presenta chiari vantaggi.

Hai considerato un filesystem crittografato? Funziona in modo molto simile alla tua seconda proposta.

Gli esempi sono eCryptfs in Unix e le modalità di NTFS in Windows. In secondo luogo, non ci sono modi fattibili per rompere AES all'infuori di un attacco di forza bruta; Serpent-256 cipher è più lento ma non esiste un modo noto per violare più di pochi numeri.

Per quanto riguarda il motivo per cui ne sceglierne uno su due, è a causa di una cosa chiamata attacco cold boot: se un hacker ottiene l'accesso a un computer in letargo con un'unità crittografata, può prendere un altro computer con lo stesso standard di memoria, rimuovere la memoria dal primo computer dopo averla raffreddata e posizionata nella seconda macchina, quindi riavviandola prima che si deteriori. Così può recuperare le chiavi per qualsiasi file che stavi usando, quindi se ne hai solo uno è facile decifrare il disco rigido, mentre l'uso di un singolo sistema di crittografia dei file consentirà solo all'hacker di decrittografare ciò che era aperto e in esecuzione.

In breve, funzioneranno entrambi a meno che tu non sia preoccupato per gli attacchi di accesso fisico.