Basics of Cryptographic Filesystems

mix_master_mike writes "Found a good article over at security focus: cryptographic filesystems: design and implementation. Nice piece on this level of security that isn't being used very effectively in the industry."

Hmm...

[sniser2]

Now combine that with E [erights.org] ?

encrypted swap space

[TheSHAD0W]

I know I'm going off on a tangent, but I think it's relevant... One of the big problems with PC security is swap space. Unencrypted data often finds its way onto the disk when memory space is swapped out. The simplest solution would be to just load the system up with a huge amount of RAM and disable swapping entirely, but that can get expensive.

Are there any crypto schemes designed specifically for use on swap files and volumes? They'd need to be blazingly fast so as not to slow the machine down, but would also have to be strong enough to protect anything that gets dumped to the drive. Maybe a big (2 meg plus) hash table generated randomly on boot, with a few extra operations to keep block comparisons from working?

Re:encrypted swap space

[PD]

That will not get expensive. Swap space is usually only twice as big as your RAM, but if you've got way more RAM than you already need, you don't need it at all.

Just add the RAM and be done with it.

Re:encrypted swap space

[Orthanc_duo]

Just add the RAM and be done with it.

Not that simple in practice. I'm not sure why but some OSes (Windows and MaxOS at least not sure about *nix) don't perform well without swap space even if you are not using all your physical memory.

Re:encrypted swap space

[PD]

Even simpler. Make a ram disk out of some of that extra memory and use it as your swap. No need to make it too large. 64 megs ought to be enough to satisfy any perverse need for speed supported by swap.

Re:encrypted swap space

[Monkelectric]

Most kernels including Linux and Windows need to be able to page out things like inodes (or their windows equivalents) regardless of how much ram there is.

Re:encrypted swap space

[SagSaw]

Linux doesn't need swap to run. I don't typically turn on swap on my desktop linux box, because the amount of physical memory present is normally pleanty to hold all running programs while still providing a decent file-cache.

Re:encrypted swap space

[snowtigger]

Very good point.

And that's why the swap space of OpenBSD [openbsd.org] is encrypted. Fortunately some programmers already thought of this =)

encrypted swap space - question

[BortQ]

Wouldn't any OS disallow random programs from accessing the swap files? And when the OS is shut down all the swap files get destroyed.

So then the OS is the only thing that can get to the swap space, where is the security issue? If you're running a hostile OS then you're pretty much fucked anyways.

But I'm no swapspert, so please explain if I'm being stooopid.

Re:encrypted swap space - question

[cyb97]

What if I yank out the powercord ?
How is the OS gonna cope with that, then I dissect your computer and connect your harddrive (including your swapspace) into my computer and find all the little pieces and nuggets of information that I need to fry your ass ;-)

Re:encrypted swap space - question

[Orthanc_duo]

If you are really worried about security...

Deleted files can be recovered with an Electron microscope even if the blocks have been overwritten multiple times.
The question you have to ask is weather your data is valuable enough for a compditor/govenment to do this. For most people the answer is no.

Either that or look at the previous reply... OS's crash!

Re:encrypted swap space - question

[ComputerSlicer23]

Pulling the plug on a machine, makes it really hard to get the bits off the disk. Destroying a filesystem takes a really long time ( I mean making it unreadable to a determined person who has access to the drive).

The point of encrypting a drive is so that if the drive mechanism itself is stolen your safe. There is some saftey in having data encrypted on a life filesystem, but the saftey of the files is limited unless you encrypt each file/directory/partition with a different key. If they all use the same key, I'll just compromise the OS and read it if the filesystem is mounted. Otherwise, I just compromise the OS and wait around for you to access the encrypted filesystem, and steal it after you put the key in.

Encrypting the filesystem is also handy for drive disposal. If you always write to the encrypted drive, then you can just give the drive to anyone you want and they can't get any data off it. Which means that hospitals or other places with sensitive could feel a lot safer that medical data isn't being given away every time they auction old computers off, or everytime a laptop gets lost.

Swap has a lot of stuff on it. Lets say I know that your using ssh-agent, this stores the decrypted private keys in memory so it's never written on the disk (the private key is normally stored encrypted via a password on disk). So if I pull the plug on the computer, it was in RAM so it's gone now I have to know your password. However, if I can load up enough stuff into memory to force that to be written to swap, now if I pull the plug, I just steal the swap disk (or boot into single user mode and copy the swap partition). Granted this is predicated on me having physical access to the machine, but if swap isn't secured, I've got a legitimate attack on your machine to get me enough information that I can be you, and all I had was a regular user account (or access to an open console), and physical access.

Kirby

Re:encrypted swap space

[JohnA]

BestCrypt [jetico.com] includes swap-file encryption in their latest version. It uses a new key generated at each boot, and is stored only in memory.

physically secure - no need for crypto-fs (or..?)

[harakh]

Maybe its largely unused because servers etc which are the biggest use of "the industry" aswell as workstations are supposed to be physically secure anyways and when in use the crypto-filesystems would be running unencrypted.

Crypted filesystems have their uses but they arent as many as one would imagine. Laptops for instance should have it by default. That should be remedied. But as long as there arent crypto offloading chipsets by default it wont be widely used because of fear to loose speed. Also its not easy enough to use yet..

Catch-22

[clambake]

The problem with encrypted filesystems is that, in order to decrypt them, you need some kind of large, ungainly key. Those keys are not justthe kind fo thing you memorize and type in when you boot up the system, so they have to be stored someshere. If they are stored on the disk, in an unencrypted partition, then you no longer are very secure... if they are stored on some kind of physical key, like a USB token, then you are safe if you turn the machine off and you head home, but unless you plan to paged to come into work and plug in your token every time the machine wants to swap Mozilla out of memory, you're probably going to be leaving it plugged in most of the time, and then you are back to leaving the key around for people to grab. And with all of this, you then have the issue of how to recover the system when your usb token burns out or the partition with your key gets corrupted.

Re:Catch-22

[spongman]

you only need the hey (removable/biometrics) when you boot, the decryption key can then be held in volatile, non-paged RAM until shutdown.

Re:Catch-22

[jareds]

You encrypt the key with a sufficiently good passphrase, and type that in when you boot. There should be several copies of your encrypted key at different locations on the drive, and if they're all corrupted, your drive is probably hosed anyway.

Speed Issues

[HFXPro]

While the idea of securing a whole filesystem by using cryptography is a great idea, I have reservations on how it will effect performance. Most secure algorithms tend to be rather slow in operation. Examples include DES, AES, RSA, etc. While this is not to bad when its just decrypting small files, it seems like this could quickly hurt performance with lots of commonly used small files and larger files.

I do understand that many computers sit around idle many times when having to access disk, but it stil

Re:Speed Issues

[redcliffe]

Motherboard chipsets need to include crypto accelerators. If that was done, all the filesystem encryption/decryption stuff can be done in hardware, and therefore it shouldn't really slow the system at all. If combined with some intelligent caching, it could probably be faster than the harddrive access we have now. Anyone know of a motherboard chipset that does crypto acceleration?

Re:Speed Issues

[simm_s]

The problem with that idea is that you have just introduced a bottle-neck into your bus. Every time you need to do a cryptographic operation you need to access that chipset. Another way to implement a crypto accelerator is to embed the crypto acellerator in the processor. Even if you had cryptographic routines in the CPU you would not want every I/O transfer to go through the processor anyway, since it would increase CPU utilization.

I think a better way to handle it is to have a cryptographic support build

Re:Speed Issues

[Valdrax]

Anyone know of a motherboard chipset that does crypto acceleration?

Sure thing, Skipper! In fact, the wonderful, thoughtful people at everybody's favorite company Microsoft have been pushing for on-CPU crypto acceleration very recently [slashdot.org]! Chip manufacturers from Intel [slashdot.org] to AMD [slashdot.org] to Transmeta [slashdot.org] have all pledged support for this user-friendly [slashdot.org] scheme that will work hard to improve security [slashdot.org] on your system.

Don't you feel relieved knowing that we're all getting what we've been asking for?

Re:Speed Issues

[redcliffe]

DRM != crypto acceleration

Re:Speed Issues

[Valdrax]

What do you think the hardware vendors are building into their chips to make DRM work better? Did you even read the Transmeta and AMD articles where they specifically talk about putting crypto acceleration into the hardware to assist with Palladium? Do you not know that DRM works by encrypting files and controlling access to them?

Crypto acceleration is a part of making Palladium work from encrypting the data they wish to protect to signing and decrypting the programs needed to run them. RTFA.