Slashdot Mirror
Seeking Current Info on Linux Encrypted FS?
slick_rick asks: "I'm looking for info on encrypted file systems under Linux to help my employers company move away from Microsoft centric solutions. However the latest HOWTO is two years old, the latest kernel patch dates back to April (and 2.4.3) and even the Sourceforge project has nearly zero documentation and appears to be very dead. Are slashdotters using encrypted file systems? If so, what are your experiences?" We last talked about this topic, just
over a year ago, in this article.
It's been a long time since I set it up under FreeBSD...but, as I recall, it had a very easy-to-setup system for creating an encrypted filesystem. I just 'cattach' it when I boot the machine...and I'm the only user than can look at the contents. It's really quite nifty. And I've never been able to find a good Linux equivalent.
Have you tried the loop-AES patch? It isn't exactly an encrypted FS, but you can create encrypted virtual drives with it.
It's a fairly decent encrypted filesystem implementation. I'm certain is has it downsides, but besides being non-free, I haven't found any others.
BC allows you to create encrypted volumes up to the max size of your harddrive, and encrypts anything therein with your choice of encryption schemas. It also comes with a 'Wipe' command that will allow you to delete a file or clean a drive with a 7-stage delete process.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin.
Note that this filesystem based encryption, not user based. I.e. you must enter a password to mount the filesystem, but after that it acts as a normal filesystem (but slower due to the aforementioned encryption).
The way that SuSE do it is to have an encrypted block device, so that you can throw anything you want on top of it. Typically this would be a filesytem ;-)
From the SuSE webpage:
... take a look at "man losetup", which has a good example of setting up an XOR encrypted loopback filesystem. XOR is pretty crappy encryption however.
- Have a picture
Encrypted filesystems are useless without deniability. Rubberhose gives you that: http://www.rubberhose.org
"The invisible and the non-existent look very much alike." -- Delos B. McKown
...and at least 10 ways to encrypt your data:
http://koeln.ccc.de/~drt/crypto/linux-disk.html
gives them.
Cryptfs is fully functional, though it was indented mostly as a proof of concept. The point is that such file systems are not hard to build, should someone want to maintain one. Here's an undergraduate programming assignment in which the students build a fully-functional cryptographic file system as an NFS loopback server.
The kernel patch you refer to is not outdated. There just is no reason to release new versions. Here's how you patch your kernel with the international patch.
/usr/src), do...
/usr/src/linux/Makefile.rej. It shows you what lines failed. You can easily fix this by adding (under the DRIVERS line)
:) Also, make sure you build the loopback device as a module, and then add crypto support. I assume you know how to load modules
/dev/loop0 /dev/hda3
/dev/loop0 with your favorite file system (I prefer ReierFS because I've had trouble with ext2 fscking of encrypted file systems -- data loss most notably whenever I mistyped my passphrase). Do something like
/dev/loop0
/dev/loop0
/etc/fstab
/mountpoint reiserfs defaults,loop,auto,encryption=serpent 0 0
/. question. But that's just my opinion.
One level up from your Linux source tree (typically
zcat ~/patch-int-2.4.3.1.gz | patch -p0 -E
You'll notice a chunk fails. The ONLY problem here is patching the root Makefile. Look at the file
CRYPTO = crypto/crypto.o
And changing the line
SUBDIRS = kernel drivers mm fs net ipc lib
to...
SUBDIRS = kernel drivers mm fs net ipc lib crypto
Now your kernel should be properly patched. Make it mrproper, then configure as needed. Add the proper cyphers (I'm sure you can figure this out). Typically, serpent and blowfish are the best choices. Also, build them as modules so you can harvest a little extra entropy.
Now for the easy part. Once you have the kernel modules built and loaded, make sure you have the latest mount tools (including losetup). Pick the device file you want to use as an encrypted file system. For this example, I'm going to use hda3 with 256 bit serpent encryption for shits & giggles.
losetup --keybits 256 --encryption serpent
It will prompt you for a pass phrase. Use a PHRASE and REMEMBER this. You cannot change the passphrase of an encrypted fs after you set it. Get it right. Next, format the device
mkreiserfs
Now, destroy the loopback device...
losetup -d
And add the following line to your
/dev/hda3
Now, every time you boot or mount that file system, it will ask you for the key length and the pass phrase. And there you go. Encrypted file system. Yea.
You can see how trivially easy that was and if you had put about half an hour's thought into it, you could have realized that the "outdated" howto hasn't been updated because the process is pretty much unchanged and you would not have wasted our time with yet another linux newbie Ask
Why bother.
Like I said, it's not a filesystem, but it might get you by. I personally don't care if /etc is encrypted or not. But I might care if /home was encrypted. It's easy enough to mount a BestCrypt container file at /home, so that might be enough.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Maybe you need deniability, but out here in the real world a lot of people should be using encrypted file systems just to ensure that sensitive or confidential information is not exposed to others if the disk is stolen, the cleaning people are bored, etc.
Personally, I don't want my doctor to have deniability about his records regarding me. Or my lawyer. Or my accountant. And most especially not my banker, financial adviser, etc.
In fact, for these people deniability makes a solution look much less attractive. People get *really* nervous when their accountant or lawyer has strong deniability about what the advice they gave you, about where your money went, etc.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Do a search on google for CryptoAPI. That's the new encrypted filesystem interface for linux. The pathes for 2.4.3 are old. I have an encrypted file system working with 2.4.16 patched with GRSecurity. You no longer need to patch the kernel with CryptoAPI, it just creates kernel modules that you install. It's pretty easy to do.
For the past two years, I've been using it in several distributions, manually applying the kernel patches and compiling the necessary programs (utils). But with SuSE (>7.2), kernel encryption is built in which has saved me a load of time compiling it into the kernel.
SuSE uses twofish as the encryption algorithm which is good enough for me. I would prefer to use serpent, but not enough to recompile everything. Both twofish and serpent were finalists in the U.S. Federal AES competition, both losing to rijndeal. Of course, W2K/XP use weak 56-bit DES in their EFS and have administrator back doors, so it barely qualifies as encryption.
If you want fast, reliable, and easy to use enrypted file systems, choose SuSE!
good thing that you have the ultra-secure, no government backdoors UBER-MS encryption there, right...
sigh...
"its encrypted because we say it is, and trust us on that"
... hi bingo
For the truly paranoid, or as used to be my case, for laptops that travel a lot and hence are very prone to theft, the cool thing to do is to encrypt your (almost) entire disk, with your root filesystem on an encrypted loopback device, and no swap at all (because swap can't efficiently be encrypted, and RAM is so cheap anyway nowadays). Of course you still need to keep a small unencrypted boot partition to host your kernel, and an initrd image. The initial ramdisk must have a script that will setup the loop device -- prompting you for your passphrase -- before proceeding with system boot.
For additional protection, you might be tempted to keep this boot partition on a business-card size CD-R, thus making sure that nobody can insert code to steal your passphrase, but if they have access to your system for long enough, they could install a hardware keylogger and you're screwed anyway ^_^... Still, might be worth it to put some tamper detection right after the root fs is mounted (i.e. an md5sum check of your entire boot partition)
In any case, I've used such a laptop on a day-to-day basis for over a year and it worked great -- but do expect a huge performance loss on disk access.
On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...
"Words have meaning, and names have power." -- Lorien
Bzztt... wrong...
Turns out that NTFS cannot be used on removable disks, even though the NTFS semantics are better suited (think what happens when a disk is unmounted unexpectedly.
The main reason I use an encrypted disk is that I have a lot of client sensitive info on my machine, including high level strategic plans for a Nasdaq 100 company.
Encrypted disks should be used as a matter of course on machines used by lawyers, doctors, accountants, anyone with a professional confidentiality duty. Laptops get stolen, machines get sold with confidential information still on the drives.
I am more skeptical about the need for encrypting file systems for geeks, after all most sysops would do better to keep less secrets rather than more.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
By setting just one sysctl (vm.swapencrypt.enable=1)OpenBSD encrypt its swap using AES.
You just have to uncomment one line in /etc/sysctl.conf to activate it permanently.
It has the code for it, but it isn't enabled by default.
Enabling swap encryption is easiest, you just modify you /etc/sysctl.conf (it's labelled well in that file) and/or use the sysctl command.
i use swap encryption on my 1.2 athlon, but not on my 486's running openbsd.
Enabling filesystem encryption requires a kernel build (you need to add "option TCFS" to your config) and some commands to be compiled and run. i found this article to be helpful.
i just did this to see what it'd be like. the documentation is rather minimal but it is workable. You have the option of using 3DES, RC5 and Blowfish. Check out that link for more info.
-f
www.blackant.net
Can anyone fill us in on this windows folder/file encryption? How does it work? What does it use as a key, and how is that key accessed?
I read it uses AES
I would assume a key/certificate/whatever is stored in the user account profile....
But what prevents Administrator from changing your password, and signing into your account to read your files? I suppose this leaves a trail... but still.
The certificate is stored on the user's workstation. If they use multiple workstations, the user must carry their certificate with them. EFS works using 128-bit DESX. A symmetrical recovery key is generated and is encrypted using the Recovery Agent(s) public key, so that those people designated as people who can decrypt other's files can do so.
For those who still can't understand this, and think that a cracked account/BO Trojan and other absurd conditions are going to make a difference, the answer is Very Little. An agent still needs the certificate installed on the workstation that he/she is going to be recovering files from. Microsoft even recommends that a certificate be generated, the public key added as a recovery agent, and the certificate kept on removable media and stored securely until it is needed. They also recommend storing the certificate as a PKCS#12 cert since you can lock the private key with a password.
An Admin can't just change your password and sign in as you, unless he can do it at your workstation or wherever you have your certificate installed. He may be a designated Recovery Agent, though in which he can look at your files anyway. But this has always been the case on windows network, but even on Unix/Linux nobody can stop root from reading a file, right?