OS con RAM crittografata?

I also would like to know if it would be theoretically possible (whilst obviously difficult) to translate an existing JIT compiler (e.g. .NET CLR) that produces code that automatically encrypts its user-mode memory.

Potrebbe essere piuttosto difficile per il sistema operativo fare per conto di un programma. La ragione di ciò è che le pagine virtuali allocate dal sistema operativo sono infatti controllate dalla CPU: il sistema operativo istruisce la CPU su ciò che vuole in termini di aree di memoria e la CPU calcola quindi gli offset su quella base per ciascun programma e applica direttamente il risultato. Leggi la MMU e Paging on 86 .

In breve, quando il tuo programma esegue il calcolo mov eax, [edi+something] , MMU / paging gestisce la traduzione degli indirizzi e genera un errore di pagina quando la pagina non viene trovata. Ciò ti consente di caricare la pagina fuori dallo spazio di archiviazione, se necessario.

Quindi l'accesso alla memoria non passa attraverso il kernel di per sé e come tale non può essere agganciato ed elaborato come un file in lettura o scrittura (le tue letture e le tue scritture vengono tradotte attraverso le appropriate chiamate di sistema nel file system appropriato In questo modo, il sistema operativo vede i dati mentre passa. Non è necessaria una chiamata di sistema per scrivere in RAM. È possibile crearne uno, ma funzionerà solo con i programmi che lo chiamano e quindi non con la maggior parte dei programmi).

Tuttavia, ciò non significa che un processo JIT non potrebbe farlo a nome di un'applicazione, o l'applicazione stessa non potrebbe mantenere i dati crittografati fino a quando non è necessario caricarla nei registri, decodificandola mentre passa sopra i dati.

In questo caso, sei interessato al problema SteveS copre bene - hai un problema di archiviazione chiave. La chiave stessa deve essere anche nella RAM da qualche parte. Questo è un problema di tartarughe fino alla fine - fondamentalmente è impossibile mantenere la chiave "sicura".

Infine, poiché essere in grado di leggere la RAM di un'altra applicazione richiede l'accesso in modalità supervisore alla CPU (ad esempio lo spazio del kernel), probabilmente si hanno problemi più grandi se si tratta di intercettazione del software. Se la tua preoccupazione è l'hardware, penso che la sicurezza fisica potrebbe essere un modo migliore per mitigare il rischio.

Modifica ho cercato documenti. Eccone uno chiamato CryptKeeper . La loro tecnica consiste nell'avere un grande "disco RAM" crittografato come file di scambio e scambiare tutte le loro pagine con quelle non utilizzate:

We mitigate this vulnerability with Cryptkeeper (CK), a software-encrypted virtual memory manager. Traditional pro- cessors cannot operate on encrypted data, so CK segments RAM into a smaller working set called the Clear, and a larger encrypted RAM device called the Crypt. As the working space fills, pages are automatically swapped into the encrypted portion of memory, and are decrypted on demand.

A quanto pare, le prestazioni non sono male, ma non penso che ci siano ancora implementazioni di questo.

Modifica 2 Quindi risulta che CryptKeeper ei meccanismi di crittografia OpenBSD Swap funzionano a un livello molto simile; in realtà non crittografa la memoria fisica ma utilizza la memoria fisica come una struttura di swap, forzando gli errori di pagina e crittografando / decifrando i dati in risoluzione.

MODIFICA dall'autore delle domande, dicembre 2018: AMD ora supporta l' estensione del set di istruzioni per le PMI che consente la crittografia hardware delle pagine RAM, oltre a TSME per la crittografia a piena memoria e SEV per l'uso con la memoria crittografata nella virtualizzazione. Ciò sembra abilitare la crittografia della memoria dell'intero sistema sulle moderne piattaforme AMD64.

Il OpenBSD sistema operativo include la crittografia automatica della memoria virtuale; è abilitato di default dalla versione 3.9.

Senza una CPU con hardware di crittografia incorporato, i dati in cache e RAM fisica non possono essere realmente crittografati, perché la CPU potrebbe quindi non usarla; ma la "memoria virtuale" come in "i blocchi di RAM copiati sul e dal disco" è sotto il controllo totale del sistema operativo, e quindi il sistema operativo può crittografarlo a piacimento, che è ciò che fa OpenBSD. In una certa misura, la maggior parte della RAM potrebbe essere mantenuta anche crittografata, usandola come se fosse un disco (cioè un file di scambio su un disco virtuale basato su RAM - funzionerebbe!) .

Si suppone che il contenuto della RAM scompaia automaticamente quando viene interrotta l'alimentazione (in realtà richiede circa un minuto, a seconda della temperatura).

Sarei curioso di sapere se esiste anche qualcosa, ma non sono del tutto sicuro che si possa esistere senza l'intervento dell'hardware.

La mia logica è che per poter crittografare la memoria, la chiave deve essere conosciuta da qualunque processo acceda direttamente, il che a fini di discussione sarebbe solo al livello del kernel. A un certo punto, la chiave deve essere spostata nella memoria non crittografata in modo che le cose possano essere crittografate o decifrate, poiché il processore non può manipolare direttamente i dati crittografati. Una volta che questa chiave si trova nella memoria non criptata, puoi accedervi in due modi: dump della memoria, driver del kernel, analisi fisica, ecc.

In teoria è possibile impedire che i dump della memoria vengano scritti sul disco e potrebbero impedire l'installazione dei driver, e si potrebbe bloccare il dispositivo in una cassastrong e farlo cadere nell'oceano (preferibilmente una custodia impermeabile) rendendolo fisicamente inaccessibile, ma che cambia drasticamente l'uso del sistema.

Bene, fammi riformulare la mia prima affermazione, una potrebbe esistere senza l'intervento dell'hardware, ma non sono sicuro di quanto sarebbe sicuro.

Per quanto riguarda la tua altra domanda, sarebbe possibile, ma hai ancora lo stesso problema di base. Dovresti modificare il compilatore e modificare l'interprete JIT e l'exe memorizzerebbe la chiave nel proprio spazio di memoria. L'exe dovrebbe consegnare la chiave all'interprete per gestire la crittografia. Il problema con questo è che devi ancora conservare la chiave da qualche parte nella memoria non criptata. In effetti, se la chiave è codificata nel file exe, potresti semplicemente aprire il file e cercarlo.

Tuttavia, sarebbe qualcosa di interessante da guardare.