La crittografia a livello di file può essere utile in diversi casi, ecco alcuni esempi:

• Invio di dati su canali non sicuri. Hai menzionato TLS e questo è sufficiente quando lo avete. Ma cosa succede se non sei sicuro che ogni nodo utilizzi effettivamente TLS? E ti fidi davvero di ogni nodo? Pensa alle email, ad esempio.
• Archiviazione dei dati in luoghi non attendibili. Potresti fidarti del tuo disco rigido esterno crittografato, ma per quanto riguarda Google Drive? E il tuo provider di hosting? Se vuoi essere sicuro che nessun altro sia in grado di accedere ai tuoi file (Google, dipendenti del tuo provider di hosting, criminali informatici che riescono a violare quel servizio, ecc.), Dovrai crittografare i tuoi file.
• Difesa in profondità. La crittografia dell'intero disco proteggerà i tuoi dati quando la tua macchina è spenta, ma cosa succede se un utente malintenzionato afferra il tuo laptop mentre è acceso? Cosa succede se la tua macchina viene infettata e prima che tu noti che tutti i tuoi file sensibili vengano inviati all'attaccante? Con la crittografia a livello di file, l'attaccante non avrà immediatamente accesso al contenuto dei tuoi file sensibili, quindi tali attacchi potrebbero fallire.

La crittografia dell'intero disco fornisce nessuna protezione di sorta contro gli aggressori con accesso remoto mentre la macchina è alimentata (poiché per definizione FDE richiede che i dati vengano decrittografati a ogni accesso). Quindi, per poter utilizzare la macchina, devi sbloccare tutti i dati .

Al contrario, i file crittografati vengono decrittografati solo su richiesta esplicita dell'utente che fornisce la password . Ciò significa che anche quando la macchina è compromessa, quei file sono protetti fino a quando l'utente non fornisce una password valida, che dà tempo extra per rilevare l'aggressore e proteggerti. Ciò fornisce anche una granularità molto più elevata (poiché la password può essere diversa in ognuno di essi o in base alla sensibilità dei dati o al gruppo di utenti con cui è condivisa), fornendo una maggiore sicurezza tramite principio del minimo privilegio

Ad esempio, le mie ricette di cucina che uso ogni giorno potrebbero essere protette da una password, i miei conti correnti bancari che pago una volta al mese da un'altra e il mio che cambio una volta ogni 10 anni con l'ennesima terza password. Quindi l'attaccante dovrebbe rimanere inosservato per 10 anni se spera di vedere la mia volontà. Con FDE, avrebbe potuto accedervi immediatamente con tutto il resto.

Inoltre, i file crittografati separatamente sono compatibili con il file server condiviso, a cui accedono utenti con privilegi diversi (e quindi conoscono solo un sottoinsieme di password condivise con cui i documenti sono crittografati).

TLS stesso ha molti problemi, come attacchi MiTM o compromessi CA (ti fidi davvero di tutte le CA nel tuo browser web? Di certo non lo faccio per nulla di serio - potresti eliminarli tutti e usa solo la tua CA, che sarebbe sicura, ma nessuno lo fa perché ti impedirebbe di accedere alla tua banca, ecc.).

I file crittografati, d'altra parte, dipendono solo dalla segretezza della password condivisa da te e da altri che hanno bisogno di accedere a quelle informazioni - e su questo hai il controllo completo.

I file crittografati sono anche protetti end-to-end quando li trasmetti, quindi non si preoccupano se il percorso tra te e il destinatario è compromesso. Alleghi file crittografati alla tua email e sai che nessuno può leggerlo a meno che non conosca la password. Se invece ti affidi agli ISP per implementare correttamente TLS in SMTP, stai per essere nel mondo del dolore (SMTP STARTTLS stripping MiTM, fallback SMTP predefinito in testo non crittografato, file archiviati in testo non crittografato sul server IMAP del destinatario e a seconda della sicurezza e buona volontà dei suoi dipendenti scontenti, ecc.)

Inoltre, pensa alla difesa in profondità. Puoi (e dovresti, se ti interessa abbastanza) utilizzare file crittografati e TLS e FDE per ottenere la massima sicurezza.

L'unico punto che posso vedere è un utente malintenzionato con poche abilità che ha accesso alla macchina con il file crittografato. Essenzialmente se un amico / familiare ha accesso e non vede accidentalmente qualcosa. Mi manca uno scenario?

La tua supposizione che l'unico modo in cui un utente malintenzionato possa avere accesso al tuo computer sia essere fisicamente presente è completamente sbagliata, anche se non parlerò delle capacità di tale aggressore, ha ancora molti modi per eseguire codice dannoso nel tuo computer, una volta che può farlo può anche esfiltrare i dati nel suo C2.

Mi chiedo quale scenario stanno effettivamente aiutare con o se è solo una cattiva soluzione.

La crittografia dei dati aiuta nello scenario dell'archiviazione dei dati ed è un concetto di difesa in profondità. Guarda solo l'anno scorso quante aziende sono state violate e se i loro dati sono stati rubati, pensa a tutte le password / numeri di carte di credito archiviati in chiaro. A mio parere, la crittografia dei file dei dati sensibili è un must e dovrebbe essere un modello di minaccia per tutti.

Hai menzionato la maggior parte di esso, mitm, accesso di familiari / amici ai file, perdita di dispositivi.

Un'altra cosa che la maggior parte delle persone ha trascurato sarebbe sul lato aziendale delle cose, la conformità è un altro fattore da considerare . Politiche di protezione dei dati, ecc.

Che ne dici di ospitare i tuoi file crittografati nell'infrastruttura di un'altra persona o organizzazione? I servizi cloud sono una cosa enorme ora, AWS adotta misure per crittografare & e proteggere i tuoi dati, ma è meglio che tu aggiunga anche il tuo "livello"!

Dove desideri inviare e-mail o condividere (su un sistema di condivisione file o in linea) in cui non ti fidi o non hai alcuna certezza nella fiducia degli amministratori di messaggistica o del file system? TLS tra server di posta non significa che l'allegato sia crittografato nella posta in arrivo *.

In un ambiente aziendale, ad esempio, potresti voler condividere un rapporto del medico con il tuo manager e il team di medicina del lavoro, ma non con Bob di IT.

Oppure, nell'ambiente attuale, qualcuno potrebbe voler condividere una bozza sensibile per la tua revisione, ma a causa di qualsiasi cosa, tutto ciò che hai a disposizione è Dropbox (non per prendersela con loro e altri servizi sono disponibili. )

• È presente in molti sistemi di posta elettronica, ma verrebbe automaticamente decrittografata per qualsiasi utente legittimo, in termini di accesso IT, tu e gli amministratori.

Pensa ai dispositivi sempre accesi. L'esempio numero uno sono i telefoni . Qui, la crittografia dell'intero disco non aiuta molto se il dispositivo cade nelle mani dell'attaccante perché l'unica chiave che consente di decrittografare l'intero disco verrà mantenuta in memoria quando il dispositivo è in tasca. La crittografia basata su file consente un controllo più dettagliato su quali file sono decrittografabili (o tecnicamente parlando, quali chiavi sono disponibili in memoria) in un momento specifico.

Per questo motivo, la crittografia basata su file è effettivamente utilizzato in iOS e in Android. Ciò consente di espellere determinate chiavi per determinati file dalla memoria, ad esempio quando il dispositivo è bloccato. Un post sul blog di Matthew Green spiega tutto questo in dettaglio. Ha qualche anno, quindi potrebbe essere leggermente obsoleto quando si tratta di specifiche di implementazione in iOS e Android, ma le sue considerazioni generali sul modello di minaccia sono ovviamente ancora accurate e pertinenti.

Sono cose molto diverse, quindi è difficile metterle sotto un unico cofano.

La protezione / crittografia dei PDF è una specie di scherzo, davvero. Tutto sommato, non è fatto per resistere agli attacchi reali. Quindi il "vantaggio" è principalmente quello di impedire al tuo bambino di 8 anni (o al tuo genitore di 80 anni) di leggere un documento. La protezione PDF è molto simile a nascondere l'ID chiamante quando si effettua una telefonata. Il dispositivo è pregato di ottemperare alla tua richiesta di negare all'utente determinate funzionalità. Un software a cui semplicemente non interessa rivelerà il documento.
La crittografia PDF, d'altra parte, è una crittografia effettiva (che rende il testo illeggibile e irrecuperabile). Tranne che ... sfortunatamente, stanno usando solo 40 bit dall'hash della tua password (almeno, questo era il caso l'ultima volta che ho guardato), e 40 bit sono, ehm ... beh ... non proprio fantastico. Non è solo qualcosa che potresti con la forza bruta in teoria, è qualcosa che puoi usare con la forza bruta (senza nemmeno ricorrere all'aiuto di un dizionario) in un lasso di tempo molto ragionevole senza cose speciali. Come in, 2-3 ore su un moderno PC desktop in esecuzione a thread singolo. O, beh, un paio di minuti a tutto gas, se è per questo.

D'altra parte, la crittografia ZIP / 7z è in realtà abbastanza buona. Sebbene sia ancora derivato da una password, utilizza una chiave a 256 bit e la crittografia AES. Abbastanza sicuro, poche password, se ce ne sono, hanno così tanta entropia, quindi ... i 256 bit dovrebbero essere visti come "fino a ...". Ma in generale, per quanto riguarda i limiti dell'implementazione, è abbastanza buono. Il resto è una tua responsabilità.

Ora, qual è il vantaggio quando si trasmettono dati su un canale non sicuro come TLS? Aspetta, ho detto insicuro? In effetti, l'ho fatto.

TLS è sicuro solo presumendo che tu possa fidarti della tua catena di certificati. Il che, sfortunatamente, è il più lontano possibile dalla verità. Non solo molti strumenti antivirus sul computer dell'utente finale installano certificati di root personalizzati e intercettano / decodificano TLS (e, a sua discrezione, inoltrano i dati a terze parti si spera affidabili , ad esempio Tomsk). Non solo le CA vengono compromesse. Non solo diverse agenzie governative sovvertono la catena dei certificati, deliberatamente e sistematicamente, solo per decrittografare il tuo traffico. Esistono aziende (che sono anche Root CAs) che hanno impacchettato l'intera faccenda delle intercettazioni in scatole pronte per l'uso che non richiedono competenze tecniche e le vendono a chiunque stia pagando.

Abbastanza sicuro, se non vuoi (o non puoi permetterti) che qualcuno su Internet legga i tuoi preziosi documenti, la crittografia a livello di file aggiunge un vantaggio perché ora, All'improvviso, l'intercettazione non è più automatica, online in tempo reale e banale. Bene, il vero origliare è ancora ... è solo che ciò che ottieni non è molto significativo. Supponendo una buona password ed escludendo un attacco con chiave inglese, è molto difficile accedere ai dati.

Gli archivi crittografati (non tutti, non necessariamente, ma di solito) hanno anche il vantaggio di nascondere metadati come il nome del file o la dimensione, ovvero non puoi nemmeno dire quale potrebbe essere l'argomento o se vale la pena attaccare. Se invii un file crittografato denominato plan_to_kill_president.doc , puoi essere certo di essere monitorato attentamente (o interrogato) presto, indipendentemente dal fatto che i contenuti possano essere decifrati o meno. Se invii un documento patent_application_fusion_battery.doc , è ovvio per un intercettatore che un attacco alla crittografia può valere la pena. Se invii un file stuff.7z , nessuno può dirlo. Potrebbe essere qualsiasi cosa, o niente. Fatto divertente: due archivi identici crittografati con la stessa password non sono nemmeno identici (questo può essere una sorpresa per utenti ignari!).

E la crittografia completa del disco? Beh, questo è sicuramente una specie di ostacolo per un ladro di laptop o un ladro di auto , ma per il resto ... la triste verità è che se riesci a leggerlo durante il normale operazione, probabilmente anche qualcun altro può farlo. Accedere ai dati mentre si è connessi è, rispetto alla violazione della crittografia, piuttosto facile, quasi banale.
Un file crittografato su un volume crittografato è ancora crittografato, se posso accedervi. Certo, ci sono mezzi per ottenere la password, ma è un ostacolo in più che non è tutto banale.

La crittografia a livello di file ha i suoi usi, sebbene di solito si basi su password o passphrase che possono essere l'anello più debole nel meccanismo di protezione se sono brevi o facili da indovinare. Se desideri inviare un file a qualcuno, puoi farlo utilizzando la crittografia basata su file e non necessariamente fare affidamento sulla crittografia dei dati in transito. Inoltre, se il file viene intercettato dall'origine o dalla destinazione, sarà più difficile recuperare i commenti.

Al contrario, come hai giustamente sottolineato, la crittografia completa del disco fornisce la garanzia della riservatezza dei dati a riposo. Se il tuo laptop viene rubato, diventa molto difficile estrarre i dati dal dispositivo di archiviazione, sempre a seconda della metodologia e della forza della password o della passphrase. Da quel punto di vista, lo scambio di un particolare file non crittografato avrebbe la sicurezza del trasferimento suscettibile ai protocolli utilizzati e all'archiviazione sul lato di destinazione (e durante il trasferimento di trasferimento poiché alcuni meccanismi di trasferimento di file sono intermediati da servizi cloud). Quindi, per alcuni aspetti, la crittografia completa del disco e la crittografia basata su file non sono garanzie aggiuntive.