paranoid idea(?) protect RAM from data recovery

Discuss and suggest new grsecurity features

paranoid idea(?) protect RAM from data recovery

Postby Raf256 » Tue Apr 04, 2006 7:11 am

It is for-paranoid-admins idea, but well perhaps it might be usefull.

Consider stolen laptop with imporant company data - even if disc was encripted, the keys might be in RAM. And it is possible (expensivem but still) to try to recover data from RAM after PC is turned off.

It seems the solution would be to
1. randomize a bit memory layout on startup, so in example some early-booting things (like on-boot read loopaes password) will land in different parts of phisical RAM each time (so they will overlap with other data and will be hard to read)

2. shuffle around pages of data in memory in IDLE time - so they will change position from time to time - and in result data will not be in one place long enought to leave (readable) "footprint" to be recovered from the chip

I dont know much about kernel internals, but 1. seem to be duable but simple allocating random amount of memory on bootup in few places, and 2. - perhaps swap in and out random pages of memory from time to time?

Btw, more usefull things:
A) I liked the idea of swap prefetching (in IDLE time, when RAM is free, swap data is swapin back to RAM, actually it is mirrored into RAM afair, so when RAM would be needed again, the re-read data could be just delated - no neede to swapout them, since the swap copy is lest on hard disc).

B) perhaps randomizing the layout of data on swap (simmilar to 1. and perhaps even 2. mentioned above) would make the XOR loopaes encryption of swap enought for most purposes

So, my suggestion: how about trying to improve ram/swap handling considering the above ideas? To have a nice kernel that integrates swap prefatch with randomizing of data layout in both RAM and swap?
Raf256
 
Posts: 72
Joined: Mon Sep 19, 2005 8:38 pm

Postby Thrawn » Tue Apr 04, 2006 8:02 am

As far as i know loop-aes has such an function which prevents recovering keys from ram.

http://loop-aes.sourceforge.net/loop-AES.README

If you want to enable encryption key scrubbing, specify KEYSCRUB=y on make
command line. Loop encryption key scrubbing moves and inverts key bits in
kernel RAM so that the thin oxide which forms the storage capacitor
dielectric of DRAM cells is not permitted to develop detectable property.
Thrawn
 
Posts: 35
Joined: Wed Nov 23, 2005 9:54 am

Postby Raf256 » Tue Apr 04, 2006 8:12 am

Thrawn wrote:As far as i know loop-aes has such an function which prevents recovering keys from ram.
http://loop-aes.sourceforge.net/loop-AES.README

If you want to enable encryption key scrubbing, specify KEYSCRUB=y on make
command line. Loop encryption key scrubbing moves and inverts key bits in
kernel RAM so that the thin oxide which forms the storage capacitor
dielectric of DRAM cells is not permitted to develop detectable property.


Thank you, that is very interesting :)

Well, then I suppose the prefatching part of idea would be most usefull, since building +grsecurity +ck kernels is hard AFAIR, and I find swapprefatching most usefull feauture.
Raf256
 
Posts: 72
Joined: Mon Sep 19, 2005 8:38 pm

Postby Carceru » Tue Apr 04, 2006 6:17 pm

I haven't checked what loop-aes does, but a method I have heard is used often, is simply to flip the bits of the key in RAM once every second or so. When the key is needed, a flag keeps track of whether or not the keybits should be flipped before being used for encryption or decryption.
Carceru
 
Posts: 12
Joined: Tue Jun 21, 2005 8:24 am


Return to grsecurity development

cron