Encrypting RAM

[trilarian]

From previous post I have a netbook from work that I have Debian Squeeze running on and did a full disk encryption (minus the minimal boot loader in /boot) in case it gets stolen. However, with a laptop/netbook it has a battery and I believe the encryption protocol (LUKS - correct me if I'm wrong) uses RAM to store the decrypt key. So if someone is quick they can dump RAM and analyze it until they get the key. Or even if the key is not stored there they could dump RAM which would have recent files cached unecrypted.

So in short, is there an easy process of encrypting RAM while still using as RAM? What I mean by that is I know you could make a ramdisk sort of like how Live CDs do and encrypt that, but at best (that I know of) I can only mount it as swap space. Suggestions are appreciated.

[JohnT]

Intersting read

[trilarian]

Thanks for the reply.

I considered putting a key on a usb stick, but then I deduced it would defeat the purpose knowing my habits. If I'm going on the road for a few days, most likely everything I need will fit into a small carry bag. The most likely location of the usb stick would be that same bag. If the bag is stolen, I just gave away my key. Sure I can keep the usb stick in my pocket, but then I know I'll have the situation of crap I left the usb stick in my other pants and now I'm locked out of my own system. If it is stolen from my home, the most likely place the usb stick would be is in the system so I can boot it. Then comes in potential hardware failure so need the key stored somewhere not encrypted so I can copy should the stick fail. So for me, a long cryptic passphrase that is stored in my head is ideal.

Also, even with the encryption key stored on a usb stick, I believe the key is transferred from USB to RAM at boot time, not accessed from USB each time it is needed. So in effect, all I have done is kept myself from having to manually type out the passphrase - RAM is still used unencrypted. So if the RAM is dumped all my recently open files will be recoverable as well as the key (even if I remembered to remove the usb stick). I'd still like to find an option to encrypt the read and write process of RAM, preferably without having to mount as a ramdisk and use for swap space.

[folkert]

dump RAM and analyze it

Will this only work when the machine is stolen while still running? In that case, I think your data is accessible anyway.

[trilarian]

Will this only work when the machine is stolen while still running? In that case, I think your data is accessible anyway.

I am getting into paranoid levels I agree, but still would like to do it if possible. Well it is sorta possible by one way I know of, ramdisk the RAM and setup as encrypted swap. I'm just trying to get around that if possible. The kernel has different rule sets for RAM and SWAP (not to mention things like video card, etc. DMA access RAM directly will prob break), so I'd prefer encrypt the I/O process between kernel and RAM than try to mimic RAM rules in SWAP space (even if I can get the system stable believing there is 0 RAM). The problem comes in that the kernel exist in RAM, and does it's work there, so the encryption protocol would have to be compiled into the kernel itself and the boot order changed so that the kernel loads unencrypted, encrypts itself, deletes with noise the unencrypted self, then look for /boot. Not ideal, and I think I'm hitting a brick wall on this one.

For the laptop/netbook, the issue is it will hibernate in RAM giving enough time of inactivity. To restore a different password is required, so I do have the luxury of not having a completely open system post boot. In fact, just closing the top will cause xscreensaver to kick in and require a password to restore. If the battery dies, then you need both the encryption password and the user account (or rip the drive out, then just the encrypted password).

Really 99% of thefts would try to boot from a USB and read the disc or just overwrite with a new install to sell. That 1% or any of the government's acronyms would freeze (temperature) the RAM which will allow them to power off the machine, pull the RAM out and place in another to dump the contents. Parsing a few unencrypted GB's of data for an encryption key doesn't take that long in modern non-super computers. Same thing can be done (actually easier with most cases) on a plugged in and on desktop/server.

I don't really have any cause to invite any of the acronyms to my humble abode, but should they ever show up or I get a nerdy thief I'd like to put a kink in their standard procedure. I'm 100% sure I'll never be worth the cost of a super computer parsing my encrypted RAM dump.

[retsaw]

If the computer is locked, the data on it isn't readily accessible. Further, lots of people like to use suspend their computers when not in use, and suspend mode keeps the RAM powered so the computer will come back to a useable state quickly, so the computer doesn't need to actually be left on for the data in RAM to be preserved.

I don't think there is any way to actually use encrypted RAM, but there was this article on Slashdot last year which is somewhat relevant, and at least may be of interest even if it doesn't lead to a way to do what you want.

However, is there really any reason that someone would go to the trouble of dumping your RAM to get your encryption key? After all, the effort required is hardly trivial.

[trilarian]

That is why I prefaced it with I'm delving into the paranoid side at that point.

As I mentioned 99% if not higher of any criminal would just wipe the drive once discovered to be encrypted. The more probable would be LE or one of the government's acronyms as they have the resources. I don't do anything illegal so it is a moot point really, but one I became interested in none-the-less. That article actually seems like a good solution for the encryption key at least. They'll still be able to read some files left in RAM, but at least the bulk of the drive is protected.

EDIT => I only use suspend on the netbook and that is to conserve battery power. All servers and desktops may power down drives, step down a processor, or turn off monitors after prolonged inactivity, but the computer is still running not hibernated/suspended.

EDIT2 => Ah well, after further reading I see too many issues with that method. First the paper is in a proof of concept stage without intention of going past that. So it isn't a guide or even a piecemeal account of a success story, it is an idea I would have to implement. Furthermore, in doing that I would either have to take the easy route of shutting off CPU cache except for storing my key which would cripple the performance, or write a very complex piece of code to have it detect screen locks or exist as a toggle. I guess in the end there really isn't a good solution.

Quick excerpt from a security site explains what I mean (for anyone not familiar with freezing RAM):

Ram similarly has its own 'weaknesses'. RAM is not instantly cleared when it loses power, rather its state decays over a seconds to a few minutes. A clever task force that wants to retrieve data from your system will bring compressed air with them when they kick your door in, and they will remove the ram from your computer and quickly flash freeze it by spraying the liquid in the can (which is extremely cold) onto the RAM chip. This drastically slows the decay of the RAMs state, and will allow them to transfer your RAM chip to a special forensics laptop, and make an image of it. This is particularly dangerous, as it can go around full drive encryption if it is properly pulled off. This is because when your computer is turned on and the encrypted drive is 'mounted', the key is stored in RAM. Thus, it is possible for either your entire key, or parts of it, to be pulled from RAM, even if you instantly power your computer off when you see LE at your door (although they will have to act fast, they have at most five minutes to flash freeze your RAM after power is cut). Even if they only get a part of your key, this will reduce your encryption security proportionate to how much of your key they recovered. If they recovered 99% of your key, it wont be to hard for them to brute force the last 1%.

[trilarian]

For anyone interested, I've continued to look but no one has a clean answer. General rule is physical access, if powered (either directly or by suspend), all bets are off. So if security is that important, either power down every time instead of screen lock or develop a manner of powering off for over 5 minutes without allowing physical access (trip wire to power off, locked and sealed steel cases, etc.). Also turn off booting from anything but your hard disk and password your BIOS.

A decent overview that is not that technical can be read here that shows just how trivial it really is (run a program that can get a key in a few minutes using just a normal laptop).

I'm really thinking it should fall onto hardware manufacturers to do a couple things at the motherboard level.

- Encrypt RAM at the BIOS level with a hardware chip. Chip will have to be able to be flashed to update protocol.

- Process of a reboot is to overwrite RAM with random noise before loading the BIOS itself (can be a toggle in BIOS for those that don't want this feature, but would have to make a jumper BIOS reset set this to default on).

Software wise, I don't see how you will have the ability to disallow a piece of information, once read, to not exist in caches and/or RAM as that is the default nature of the hardware.

[stumbles]

Where BIOS is concerned, I would only be comfortable if it was coreboot (LinuxBios). There are to many back doors/hidden passwords for many of the BIOSes used today. This is just one example; http://www.uktsupport.co.uk/reference/biosp.htm.

To be honest, I do not trust the hardware folks to get the encryption right. Some hard drive manufacturers have already tried to pawn "encrypted" drives only to have them broken rather easily.

[trilarian]

Where BIOS is concerned, I would only be comfortable if it was coreboot (LinuxBios). There are to many back doors/hidden passwords for many of the BIOSes used today. This is just one example; http://www.uktsupport.co.uk/reference/biosp.htm.

Completely agree, but even with coreboot the RAM can be removed while the machine is running and dump on a separate machine. The only reason I said at the motherboard level encryption would be a plus is that other things access the RAM directly - like your video card, multiple core processors, etc. when it does a DMA access to RAM. More and more this is being pushed under the idea of 'zero copy' between components for speed. Hardware encryption is susceptible to proprietary faults, back doors, etc. though, so you fix one problem while causing another.

To be honest, I do not trust the hardware folks to get the encryption right. Some hard drive manufacturers have already tried to pawn "encrypted" drives only to have them broken rather easily.

Yep, not pushing for everything encrypted through hardware, just pushing for an encrypted RAM scheme since the motherboard ultimately will be responsible for I/O between RAM and other components. Even though this could still be compromised, it would be much better than what we have now - wide open unencrypted RAM. I'd like the kernel to control this, but I don't see how DMA would work (at least as coded now) with the kernel taking over the I/O procedure to RAM from the BIOS.

I don't have the answer, is why I made the post. I just know the current methods have a major flaw in them and anyone of reasonable skill can bypass your encryption. It would seem you would need all or a combination of a way to disable DMA (and take the subsequent performance hit), encrypt RAM (either through the kernel or motherboard hardware), have your decryption program push the key out of RAM into your swap (which needs to be within the encrypted partition) once the drive is unlocked, and overwrite the key's RAM location with noise. You still have the issue of CPU caches, etc. because at some point you are going to have to get the key from the drive to use in the algorithm to read and write back to said drive.

The idea of your encryption is only as strong as your encryption key is not new, but it is a frustrating topic... heh.

[stumbles]

Very well put and it is a hard nut to crack. However, it does seem that individual file encryption does have its plus. I of course refer to ; http://g1.globo.com/English/noticia/...el-dantas.html

[trilarian]

I don't know the details of that particular case, but I'd assume either the machine was off long enough to disallow a RAM dump (or the INC failed to attempt when seizing) or the partition/file was unmounted during the raid.

That is another option. Have the entire drive encrypted, then really sensitive data encrypted again within that partition and keep it unmounted except for when you are in need of access. You could even setup cron to unmount it at set intervals during the day in case you leave and forget. That way your machine can still be left on, but your most secure key is not in RAM to steal. Will have to make sure that the key doesn't get cached into swap though.

Hmm... maybe someone will invent 'safe' RAM that has instantaneous memory loss on power failure even in cold temperature.

[bogdann]

I have a partial solution for this problem. However I am not aware of anybody actually having coded it.

As far as standby and hibernation go, the kernel should simply encrypt the ram or the hibernation file respectively. Later, when you power up the machine it will have to ask for the password.

As for the shutdown, that's easy, simply write a program that allocates all the memory and fills it in with junk and add it to the shutdown script.

Also, some bioses have the option of "initializing ram" which basically means zerofilling it upon boot.

[Pafnoutios]

Initializing at boot does not seem effective for the issue at hand. The random wipe at shutdown seems better, then all you would have left after shutdown is the kernel and the memory wiping program (and perhaps init or a few others).

[bogdann]

Thanks for your reply!

Initializing the ram is just about the same, but you have to reboot the machine and then shut it down, say when it reaches the boot manager.

But that's not what I wanted to discuss, the fact is that you can also use sleep/hibernation with encryption but nobody has coded such thing. Of course it's rather complicated, since this will have to be a kernel hack.

So I guess what I'm asking is if there's anybody who has experience with kernel programming that can help me get started.