Slashdot Mirror
Encrypted Filesystems With Linux?
"First let me say that I know little to nothing about cryptography, and I wouldn't know the first thing about good vs. bad options, so any statements I make here are based on what I've read and may be completely erroneous. What I'm looking for a way to secure my (Debian) Linux laptop, since physical security is an issue (I can't keep it locked up in my house all the time). So I went out looking for a way of encrypting my filesystem.
The easiest method appears to be to install Loopback Encryption, but from what I can figure out this is a bad solution because (a) its very poor performance, and (b) there is no way to do key authentication. Another option is CFS (a quick howto can be found here), but this is also reported to have poor performance (even with blowfish, or the NFS related TCFS) and it also appears to be abandoned. (Okay TCFS may not be abandoned, but it hasn't been updated for over a year). People seem to rave about CryptFS, but this appears to be a prototype developed for a research paper that has gone no further. Of the last real options that I've uncovered PPDD (which is a device-driver rather than a filesystem) seems like it may be the most promising (though it doesn't seem to have been updated since January, and I can find no indication about testing it with the 2.4 beta kernels)."
Blowfish, and presumably twofish, are very fast after they generate your sub keys. Basically, they take your key and encrypt it multiple times, and use the results as keys for the actual encryption/decryption scheme. Once you get the sub key overhead out of the way, encyption/decryption is pretty quick. I wrote a paper on blowfish last year for my school's Cryptography course.
garc
I don't think the iButton is supported under Linux, though. Check out Schlumberger (here, here or here)smart cards; apparently, they have a Linux SDK out somewhere. Pretty slick cards, too--support CRYPTOKI (PKCS-11) pretty well, nice form factor (same size as my credit card), ISO-7816 interface. Getting them set up is a little bondage-and-discipline, but once you get past that they're sweetness and light.
No, I don't work for Schlumberger. I've just been doing some dev work on them (for Win32) and have been moderately impressed with them. They're the best crypto tokens I've used so far.
Probably the best thing would be to stop downloading porn altogether :)
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
In Linux, the source code is open, but your data is securely locked away. In Microsoft, the source code is securely locked away, but your data is wide open.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
I set up my keyboard to use the Dvorak layout, and didn't change the key caps around. It's better, because a lot of people know how to touch-type on QWERTY, but most people don't even know about the existence of the Dvorak layout. Here's "su":
/etc/passwd":
# og
and "cat
# jay z.yjzlaoo,e
I don't think that it really works that well, though. It just slows them down and really annoys them.
To get something done, a committee should consist of no more than three persons, two of them absent.
To pick just one obvious example, any files you have from your employer should be on an encrypted FS. Even the company's phone list can be considered "confidential" if it includes employee's home address and unlisted phone numbers. Anything legally recognized as IP (non-published source code, client lists, etc.) should definitely be protected.
You could PGP each file individually (hah!), or just encrypt the entire directory tree/FS.
If you have information on third parties (e.g., financial or medical information on clients) then encryption isn't often isn't even an option - it's <b>required</b> by some of the recently passed privacy laws.
Overall, I would say that it's a tossup whether a fixed system (at either the office or home) needs encrypted filesystems, but there's no doubt that laptops need them.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I just removed the keys, and then replaced them incorrectly, foiling anybody but a touch typist. For instance, some cracker gets my laptop and tries to su, but they type this instead:
/etc/passwd file, but end up typing this:
.wrx.osaaqes
# ay
ay not found
Then they try to get to my
# fs
Really, this work!
It seems like everyone is interested in encryption lately, particularly with fascinating books like "The Code Book" being available on the market. It seems like level of encryption should be a core issue here.
For example, if we're talking about keeping marketing people from getting on your machine to try and play Solitaire, your encryption needs are minimal and not processor-intensive. However, if you're worried about someone stealing your laptop, taking it to a lab, hacking into it with vast resources and smarts, and extracting your highly sensitive information, you will need more powerful encryption that, by its nature, will slow down the machine in general.
I use BestCrypt. BestCrypt uses a "container" file to hold the encrypted data. You can create any filesystem inside of the container, and then "mount" the container (of course using bestcrypt to do the mount). The file can be encrypted with a variedy of algorithms including des, twofish, and blowfish (but no rijndeal yet). The container can be copied and moved like any ordinary file (including onto CD, zips or floppies). I have a laptop (PII 266) and I don't see any performance problems. I can play MPEGs, RealVideo, and MP3's from the encrypted system.
But beware of a problem that I have. When you create a big (over 170MB) container, and create an EXT2 filesystem inside that container, once the data exceeds 170MB the system hangs (SOLID!!!!). I don't know whats magic about 170MB, and I have tried to debug but to no avail. It happens every time. And for me it has happened under RedHat 6, Mandrake 7.0, 7.1, and beta 7.2.
The fact that no two snowflakes are identical should tell you something important about God's will.
- The filesystem is a fixed-size file, thus unnecessarily eating diskspace when it's not filled and not being extendable as soon as it is full.
- It's closely tied to the Linux kernel and thus may break with future kernel upgrades. Not good IMHO for data where security is top priority.
CFS's major drawback is the performance penalty because it works over NFS (also internally). That said, I don't notice performance issues when working with CFS-encrypted text files on a Pentium I and an AMD K6. Moving data to CFS directories is slow though. BUT:- Since it's a userspace implementation, it doesn't depend on kernel code; indeed, you can flawlessly exchange CFS-encrypted between Linux, *BSD and any other *nix flavor.
- The cypher files reside in the original file/directory structure (with encrypted names) on any filesystem. This makes it possible to burn CFS data on CD-ROMs, use it on DOS-formatted floppies etc.etc. It's also great for backup, because the backup software doesn't need to copy the whole crypto filesystem every time (as with the loopback solution), but only the files that were changed.
A very promising solution is ReiserFS, as soon as the plugin API has been implemented. Crypto plugins for ReiserFS will probably the fastest and easiest way to securely store data (although CFS data will still remain more portable).(remaining anonymous this time because I don't want the whole world to know that there is CFS-encrypted data on my computers)
It's for keeping your kids (or spouse) out of your pr0n collection - make them build their own.
But why shouldn't somebody want to encrypt their whole partition? There are actually a number of reasons why doing so might very well be a better idea than encrypting selected files:
In general, I think that the valid question is not "why should you bother to encrypt your /home partition" but rather "why should the default behavior be to let anyone be able to read the data off the hard drive". The existence of file permission bits in Unix already implies that the right to prevent others from reading your data is a good thing. Why not back it up with a mechanism that can't be trivially avoided by reading the raw data off the disk?
There's no point in questioning authority if you aren't going to listen to the answers.
This is a topic that has caught my interest lately as well. What I am trying to do is use a Sony 8MB Memory Stick in a PCMCIA adapter card as an encrypted filesystem. I have only done some of the preliminary work (update bin_utils, compile loopback and encryption into the kernel, etc.), so I can't report on how well it worked yet. Has anybody tried this? I figure if it works, I can upgrade to a larger capacity memory stick. Memory sticks are easily carried and hidden, and right now I don't have over 64MB of files to encrypt, so I could conceivably get it all onto a memory stick. Cheers, hussar
hussar
Bureaucracy loves company.
Another thing to take into account is that you only need to encrypt data, not binaries. Encrypting /usr only gives an attacker more known plaintext to try to crack the key with.
/usr only gives an attacker more known ciphertext. A good encrypting FS will encrypt the filenames, the directory structure, the whole nine yards. They'd have a lot of known-ciphertext and a lot of cribs ("we can predict there will be an /sbin directory off the /usr directory"), but that's not the same as a known-plaintext. Like I said, you're just slightly off, but I'm so anal-retentive about these things that I have to be fastidious about correcting. :)
Slightly off. Encrypting
Even were it to be a known-plaintext attack, cryptanalysis of any modern, strong cipher is mind-wrackingly difficult. I'd feel safe encrypting my entire HD with 3DES (three independent subkeys) and turning a copy of the contents over to my business competitors, the Feds, organized crime, you name it. (Wouldn't turn the originals over--scanning electron microscopes can pick up the most amazing things off hard drives, including cleartext that was recently erased and low-leveled.)
I don't think they could do it. If any of the above really want to know what's on my HD, they're not going to cryptanalyze my drive, they're going to cryptanalyze me.
They might Van Eck my monitor, they might grab me in the parking lot and have a fellow named Guido talk to my kneecaps, they might blackmail me, they might... etc.
Using strong ciphers in strong configurations, you can raise the difficulty of a cryptanalytic attack so high that it's by far more efficient to cryptanalyze the person instead.
You can try rubberhose - http://www.rubberhose.org/. From the homepage description: "Rubberhose transparently and deniably encrypts disk data, minimising the effectiveness of warrants, coersive interrogations and other compulsive mechanims, such as U.K RIP legislation. Rubberhose differs from conventional disk encryption systems in that it has an advanced modular architecture, self-test suite, is more secure, portable, utilises information hiding (steganography / deniable cryptography), works with any file system and has source freely available. Currently supported ciphers are DES, 3DES, IDEA, RC5, RC6, Blowfish, Twofish and CAST." It is not quite true that all filesystems are supported - do not use a journaling filesystem such as RieserFS, JFS or XFS.
There are a number of good places to look on the web, including:
Info on Loopback Encryption
Information on using CFS (useful)
Faster Option and another. These people have gone about it a different way.
you start off with a virgin disk and encrypt your page files. Any disk that undergoes forensic analysis would probably be suseptible to recovering previous data, even if a filesystem is encrypted afterwards. Of course in Windows everything is placed in one filesystem so you don't have to worry about this. FDISK once, install Windows, and encrypt.
Why do you bother with gaming on Li
The usefulness of an encrypted filesystem is limited to removeable media and pseudodisks (e.g. those created using the kernel loopback driver). It's been pointed out that many people actually want to encrypt their entire hard drive (or an entire partition) which seems to me to be the biggest waste of cycles there is. But then again, as soon as we classify hard disks as removable (like there aren't hardware locks with similar effectiveness) media it seems to quickly become warrented.
/etc/passwd and friends). if you need more protection, you're going to go slower (encrypting swap), and slower (encrypting the entire disk), and slower still (embeding your laptop in a cement block and droping it into the ocean).
Of course, this makes a nasty assumption that if you're going to encrypt your disk, you've already got the reason for it. But before I go too far into that, let me quickly point out that network filesystems and encrypted filesystems cannot be considered complimentary. NFS, AFS, and CIFS (all commonly referred to as network filesystems) bear no resemblence with block devices for the very reason that (all) network block devices themselves are extremely ineffecient. Not only is it a waste of bandwidth, but also a waste of cycles for the client (assumed: servers usually have more cycles than clients. if they don't, you have other problems).
But crypto on NFS and friends all involve themselves with encrypting the network traffic, instead of the individual segments of the files, or the disk-blocks they refer to.
Mr. Blue mentions that he wishes to encrypt his laptop disk for the sake of security. And being a laptop it can immediatly be considered removable media (snicker). And while the most common reason that laptops are stolen are infact for the hardware (e.g. resale), the lap-jacker may be technologically inclined (as is becoming more common) and wish to sneak out creditcard numbers and other goodies out of the disk before sale.
So now that I have finally established both cause and reason to encrypt, I can finally target a technological issue of performance.
By simply creating your disk IMAGE, you are slowing down your system. The goal is to slow it down the least. The the least way is to (on login, presumably) decrypt the entire image into a ramdisk (or other element that will be nuked on reboot - such as a swapfile) and use the decrypted image instead. Before anyone says this is a stupid idea (what if they use a boot floppy), remember that unless you have a lot of ram, your decrypted secrets would be in your swap ANYWAY.
So bypassing the obvious of disabling floppy boot, the attacker can still take out the hard disk and put it in another machine. Since your data hasn't been wiped by boot (and/or is still in swap), you
would then need the filesystem and the swap to stay in ciphered form (to make sure all of your data is protected). So in addition, you must keep your swapfile in cipherspace (snicker) so that the bad people can't get there either.
Which still allows us to keep most of our "work data" in unencrypted space (ramdisk) because when portions of our ramdisk need swapping, they'll be reciphered anyway. And if you weren't thinking about swap, you're faster still.
So, the short answer (if you read this far, you deserve it by now) is that your filesystem will go as slow as you need it to. That is to say that if you are protecting from your laptop being stolen,
using a ramdisk for sensitive files is probably good enough (my portable penguin uses PGP to store my ramdisk when sleeping. the ramdisk was 24m which was good enough for my ssh password lists, keys,
Peter Gutmann wrote an outstanding paper on recovering data from various media, especially hard drives. Bottom line: once it's written, you can almost always get it back eventually.
His paper is http://www.fish.com/security/secure _de l.html and is a good read.
Favorite fact: Freezing your RAM (like, -60 degrees C) makes the data easier to recover. Yeah, that's right, I said the RAM, not just the drives. Go read the paper. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Would anyone know if there are any hardware level encryption devies that Linux supports?
As with most things, using hardware instead of software is faster (sometimes *much* faster), so this would not only be an answer to the speed problem that was posed, but also it would be very reliable (as opposed to encryption daemons that may die when the system runs out of swap, etc).
The other advantage is that hackers can't touch it. What if a hacker recompiled the binaries for your software encryption with a backdoor? Bad news, your formally encrypted partition is now fully accessable to the hacker or anyone who is aware of the backdoor. With a hardware solution, it's almost impossible to trojan and/or modify the hardware.
Ideas on the hardware solutions for disk encrption that are out there, and if so, which ones does Linux support?
You might want to look at StegFS. It's a stegagnographic filesystem. It supports multiple "levels" of security, and the nifty thing is that nobody can tell exactly how many levels of encrypted filesystems there actually are. I.e., you can have 3 levels of encryption, and even if the first level is broken, there is no way for the cracker to get to the other levels, or even find out exactly how many levels of encryption there are. Check out stegfs by clicking on this link . -Laxitive
I have my homedir encrypted with the loopback driver. It's worked like a charm for around a year, when i decided to try it just for fun. No dataloss, no crashes.
:)
/usr only gives an attacker more known plaintext to try to crack the key with.
/dev/urandom on all my computers)
Some observations:
It's not noticeable slower. I havn't run any benchmarks, but there's absolutly no noticeable slowdown of any kind. Even when copying 0.5gb files between encrypted and unencrypted dirs - the harddrive is the limiting factor, not the encryption algorithm. Granted, i have a speedy CPU (Athlon 900mhz) and only a IDE hardrive (a 7200rpm deskstar). Just if you missed it, The speed difference isnt noticeable. There, now i've said it three times
Another thing to take into account is that you only need to encrypt data, not binaries. Encrypting
As for the other drawback you mention, i think having no key authentication is acctually an adantage: There's no fixed header the Bad Guys can use to prove that it isnt a 2gb big chunk of random data. Think plausible deniability. (even tho it's a long shot: i swear officer, i always keep 2gb of the outout from
As for algorithms, i think they're mostly irrelvant, as long as you use an algorithm with no known secure holes and a long enough keylength (128bits should be impossible for just about anyone to bruteforce). Cracking fingers (if you just want the data) or the passwords (if you dont want anyone to know you stole it) is most likely a lot easier than bruteforcing the algorithm. So the main advice here: Choose a good long password!
I havn't tried any of the other available methods, but i doubt any has a lower overhead than the kernel level loopback filesystem.
I feel reasonable safe about entrusting all my data to the loopback fs encryption. (i even reviewed the code before compiling - just to be on the safe side. Me, paranoid? Where'd you get that idea from?)
-henrik