Perché crittografare i dati in memoria?

In un mondo perfetto, hai ragione: non dovrebbe esserci alcun motivo per mantenere i dati crittografati nella RAM. Il sistema operativo dovrebbe mantenere una strong separazione tra i processi, liberare la RAM quando viene riallocato in un altro processo e, se il modello di attacco consente a un utente malintenzionato di rubare il dispositivo in un secondo momento e di eseguire un'analisi del disco rigido, crittografarlo (o non utilizzare affatto lo swap, che può avere più senso per un dispositivo con memoria basata su Flash).

In un mondo realistico, in cui i sistemi operativi e l'amministrazione del sistema sono tentativi umani e quindi intrinsecamente non perfetti, potresti voler aggiungere alcune salvaguardie, tra cui mantenere i dati crittografati nella RAM e istruire il sistema operativo non per scrivere i dati nello spazio di swap (su sistemi Unix-like, questo è fatto con mlock() ). Tuttavia, questa encrypt-in-RAM è più un rituale psicologico che una vera difesa; la sua virtù principale sta nel far sentire meglio lo sviluppatore.

Non preoccuparti di farlo in Java, comunque. Il garbage collector copierà gli oggetti nella RAM in modo trasparente (questo è parte degli algoritmi GC più efficienti e non puoi impedirlo) in modo che nessun livello di crittografia da parte della tua applicazione garantisca che non esiste una versione chiara delle chiavi nella RAM in qualsiasi momento.

I moderni sistemi operativi funzionano con la gestione della memoria virtuale in modo che per impostazione predefinita non sia possibile per i processi dello spazio utente / modalità utente accedere direttamente alla memoria di altri processi.

Ma in Windows (non so se questo si applica anche a Linux) ci sono interfacce che consentono agli utenti standard di accedere alla memoria di processo di altri processi in esecuzione con le stesse credenziali.

Ci sono molti programmi che usano questa interfaccia. Un esempio molto semplice è HxD - un editor esadecimale freeware che consente di visualizzare e persino modificare la memoria di processo di altri processi.

La memoria può diventare visibile ad altri processi:

1. disponibile una volta che il processo originale che lo utilizza lo ha restituito al sistema operativo. La memoria non viene cancellata e un processo successivo potrebbe eseguire un malloc() e recuperare informazioni appartenenti a un processo precedentemente in esecuzione (nota capitolo 8 dei driver di dispositivo Linux, in particolare la nota a piè di pagina sulla prima pagina)
2. pagine che vengono scambiate su disco dal sistema operativo. Questi possono quindi essere disponibili per un processo che guarda il disco / storage.

Di conseguenza, la memoria non crittografata può diventare visibile ad altri processi.

Questo è un link molto interessante e nota questa citazione:

This volatility depends greatly on the computer in question, however - for when a computer isn't doing anything anonymous memory can persist for long periods of time. For instance in some computers passwords and other precalculated data were easily recovered days many after being typed or loaded into memory

Ci sono alcuni problemi specifici del mondo Java che devi considerare. È una pratica normale che si effettuano i dump dell'heap della JVM se si verifica un problema tecnico. Ho a che fare con un'app che ha anche un'interfaccia utente dedicata per questo. Questo potrebbe essere incredibilmente prezioso per es. per trovare perdite di memoria. E certo - sì - le informazioni sensibili vanno nella discarica. Quindi, se qualcuno interrompe l'app (ad esempio, ignora l'accesso con un'iniezione SQL :)) ...: X. O se l'utente amministrativo è una persona curiosa ...: X

So che questo non dovrebbe accadere nel "mondo ideale".

Inoltre puoi configurare la JVM per fare un dump sulle eccezioni di memoria esaurita. Da Java 1.4 questo potrebbe apparire come questo:

-XX:-HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=<path to dump file>

Un utente malintenzionato può trovare un exploit che fa crashare l'app con memoria insufficiente e può trovare un altro exploit (ad esempio bug traversal del percorso file) per rubare il tuo dump!

L'altra cosa che dovresti pensare è che alcuni dati sensibili dovranno entrare nella tua app in qualche modo. Quindi in certi momenti lo avrai in memoria. C'è poco o niente che puoi fare al riguardo. Ma quello che puoi fare è pulirlo più velocemente. Ad esempio, prendi una password utente. Se lo memorizzi in un'istanza di String, non hai molto controllo su quando verrà raccolto. Pertanto, solitamente le API belle elaborano tali dati negli array di caratteri (char []) che possono essere azzerati dopo l'uso.

Google ha un exploit chiamato RowHammer che consente a utente per leggere il contenuto della RAM adiacente ai dati in fase di scrittura. Crittografare la RAM renderebbe questo exploit molto più difficile.

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.

We don’t know for sure how many machines are vulnerable to this attack, or how many existing vulnerable machines are fixable. Our exploit uses the x86 CLFLUSH instruction to generate many accesses to the underlying DRAM, but other techniques might work on non-x86 systems too.

We expect our PTE-based exploit could be made to work on other operating systems; it is not inherently Linux-specific. Causing bit flips in PTEs is just one avenue of exploitation; other avenues for exploiting bit flips can be practical too. Our other exploit demonstrates this by escaping from the Native Client sandbox.

Il motivo per cui sembra una buona idea è che vorrete proteggere i dati dall'essere rubati mentre risiedono in memoria. Ciò presuppone che i dati nel database reale siano crittografati (come dovrebbero essere tutte le PII) ma che non vengono crittografati in memoria durante l'elaborazione. Questo sarebbe abbastanza difficile da fare per una serie di motivi delineati da altri commentatori e introdurrebbe una grande quantità di complessità in termini di come le applicazioni funzioneranno con i dati crittografati in memoria.

Una soluzione migliore e più fattibile è garantire un adeguato controllo degli accessi al Database / sistema e anche assicurare che il DBMS funzioni con un account utente "normale" e non con un account elevato come SYSTEM ecc. C'è anche controlli detective che puoi mettere in atto come uno strumento di monitoraggio DBMS che puoi configurare per esaminare le selezioni di grandi dimensioni sulle tabelle sensibili ecc. e riportare tutto ciò che è fuori dall'ordinario. In questo modo puoi vedere se c'è qualche selezione o processo che cerca di ottenere grandi quantità di dati.