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.
ÖcéqêK8N& #9561;fö,á>c GîIkU 96;:á9fYé7$¼F~ ÿeCCLìM& #9616;ÿ4- ;êå0#0_R'λ 3;lf'\@& #9524;te1q :Æ¥ôä&# 9580;Eüb#
;Æ>ÿ"w╚ ;å+íÅ ï8XRO"# )Wÿ'fò^òY╣ ;Kñ2">[.0	 786;0Z
/ñlöúi;`ν 1;r÷\^"Ç SHNHÄN$RiDeb"&# 9492;3@É-'ϗ 5;úïfM¼fzϒ 8;
÷¥ä=jN¥ká╟
.¥c◘
ÿ!(VIi±(Av#;d}x övëëúóî|KÖ9&# 9792;9Jq]@2Oü-ö @[WcáÅU3 j
http://www.thehungersite.com
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.
ftp://ftp.kernel.org/pub/linux/kernel/people/hvr
:)
Try that
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.
Apart from that I never had any problem with it, but I admit that I never did much testing.
It works well. I'm no security expert buy I can see a couple of problems with it. Firstly it uses triple-DES. Probably secure enough, but not so fast. There are certainly more suitable ciphers out there.
The key comes from a pass phrase. cfs forces you to have a pass-phrase with at least enough bits to fill the DES keys, but obviously unless you like memorizing long strings of random charcters there will be far less entropy than required in the key.
Secondly meta-data is not encrypted. So, although Eve can't tell what is in a particular file, she can see the directory structure (but not filenames) and when a file was created/modified/accesses.
Apart from these criticisms it seems quite good. Users can create/attach/detach encrypted filesystems without special priveledges. You can specify a timeout on a file store so it is dettached after a certain period.
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
The install for SUSE version 7.2 professional had it built into the install. Select expert partitioning and it was a check box selection in the mount-point, file system type dialog box. You could edit the boot sequence to remove the prompt to mount the file system and then mount it only when you wanted it mounted. Once mounted it was visible in unencrypted form but you could un-mount anytime. Reading and writing is done via a loop back that decrypts /encrypts during read/write. It is visible as a standard file system once mounted to all programs by all users.
SUSE 7.3 has this to say http://www.suse.com/us/products/suse_linux/i386/se curity.html
Watch the space in security, comment dialog box is too small to fit url without it injecting a space.
I tried to use win2k's efs, and it ruined me.
Tell them that!
Ever heard of a File Recovery Agent? There's one set up by default on every Win2k system. And it gets better... you can add more!
The Rubberhose encrypted filesystem might be more suitable for individuals.
Read about it at www.rubberhose.org. It's primary feature is deniability, (from their web page)
Rubberhose is a computer program which both transparently encrypts data on a storage device, such as a hard drive, and allows you to hide that encrypted data. Unlike conventional disk encryption systems, Rubberhose is the first successful, freely available, practical program of deniable cryptography in the world. It was released in an earlier form in 1997, but has undergone significant changes since that time. The design goal has been to make Rubberhose the most efficient conventional disk encryption system, while also offering the new feature of information hiding.
Rubberhose is a type of deniable cryptography package. Deniable cryptography gives a person not wanting to disclose the plaintext data corresponding to their encrypted material the ability to show that there is more than one interpretation of the encrypted data. What deniable crypto means in the Rubberhose context is this: if someone grabs your Rubberhose-encrypted hard drive, he or she will know there is encrypted material on it, but not how much -- thus allowing you to hide the existence of some of your data.-- Too lazy to get a lower UID.
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.
It's easy to implement a crypto filesystem, but hard to do it *right*.
Some quick examples:
1) Is a standard cipher used? (easy, now that libraries are widely available)
2) Is a standard cipher used *correctly*? (e.g., no ECB mode!)
3) Does the same data in two blocks encrypt to the same ciphertext? If not, how are you randomizing them? What happens if you copy an encrypted FS from one media to another, e.g., via backups?
4) How do you detect an incorrect encryption key?
There's then the whole issue of key management, the truly hard part. How do you generate the key from the password? How do you support multiple users on the encrypted file system? (N.B., this is cryptospeek for "how do you prevent disgruntled employees from encrypting your data then walking away?" This usually means secondary and even tertiary keys automatically inserted by the system.) How do you handle system reboots?
Finally there's the mundane. Top of that list - how do you handle backups? Can you back up the encrypted data? Can you deny backups of the unencrypted data?
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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
Sorry to everyone who was offended by my last comment in this post. I did in fact mean to help, but I just though that the original submitter of this Ask /. question could have done a little more work figuring this out. Hell, even I managed to get my file systems encrypted with that outdated HOWTO.
Nonetheless, I'm sorry for spoiling something informative with some elitist babble. It's just a knee-jerk reaction from time to time.
Why bother.
Comment removed based on user account deletion
I don't see why this question is relevant. I have been using CFS for 3+ years on FreeBSD 2, 3, and 4, without a hitch. There does not seem to be a need for being 'updated'. It works very well.
When you are at the partitioning stage there is a box you can check that allows encrypted filesystems.
Something needs to be done about the block size problem - the solution from cryptoapi doesn't seem "the right way"
The best things about kerneli are the possibility to choose between different encryption algorithms and that it's not filesystem dependent. Though I miss the oppertunity to use the encryption algorithms in userspace programs. (Same thing about the digest algorithms, do thay have any function except for enlarging the kernel size?)
I'm currently testing a pam module that mounts kerneli encrypted home directories, release scheduled a few weeks into the future.
normal:
cryptoloop (cryptoapi), loop-aes, cryptfs, bestcrypt, crypto-patch (up to ~2.4.12, you have to change the Makefile -> better use cvs-cryptoapi)
steg:
stegfs, vs3fs
network:
cfs, tcfs, sfs, vpn solutions
I'm not following the lists at the moment, but I'd hazard a guess that cryptapi is the replacement for kerneli, which has been in a coma for ages.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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/
Yup. The last I read, there was only a slight performance hit, and very acceptable for the truly paranoid.
This is quite different to quite a lot of other methods. It allows to backup encrypted files to e.g. CDROM and still have them mountable from there. Works quite well.
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.
The only way you'll ever be sure is if you write your own
Or get the source code for an existing cryptographic application and audit it. A good programmer and a good mathematician working together could probably produce a reasonably trustworthy audit of the cryptographic functions in a given application.
Of course, this requires that the source code be availble for inspection and that the code can be compiled for actual use in the production environment. It's pointless to audit source code that is then carried off and you are subsequently handed a binary-only application "supposedly" based on the audited code.
If you're a zombie and you know it, bite your friend!
What about StegFS is a steganographic filesystem for linux. It encrypts the data and hides it. Although it does not work with 2.4.x kernels, a decently patched 2.2.20 kernel should do well enough. If that's not you particular cup of tea there is always cfs tcfs.
Fighting for Peace, is Like Fucking for Virginity
Fighting for Peace, is like Fucking for Virginity.
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
I use loopAES:
http://loop-aes.sourceforge.net/
It works wonderfully, and has worked on every kernel I've tried it on. It doesn't patch the kernel and require a rebuild (except that it requires you do not use the kernel's standard loop device).
It requires a little bit of extra work in that you need to patch util-linux. I used to use cfsd, but I've not been able to get it to work on recent kernels, so I've moved my encrypted volumes to loopAES. I've had no problems at all with it.
Jason.
Given the NSA's history with various companies (Crypto AG anyone?) and their encryption software, I think the opposite proof is required. All proprietary products must be assumed to have back doors unless they can somehow prove otherwise. BTW, good luck with that proof without releasing source code.
Also, Microsoft has a pretty bad history (their VPN software for example) of making things that really are secure in the cryptography arena. So again, I think the burden of proof is the other way.
All Microsoft software is only as secure as it absolutely has to be in order to sell it, and history (and knowing the average buyer) shows that's not very secure. Trusting Microsoft with security is like trusting an unregulated S&L with your money.
Need a Python, C++, Unix, Linux develop
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?
Don't forget that if you put your laptop to sleep and it's stolen in that state that your encrypted filesystem may be left wide open.
:)
Unmount encrypted filesystems before you sleep the laptop and put a password on your screensaver in case you get lazy. (don't count on a password-protected screensaver to protect you though -- maybe someone will create a screensaver that unmounts any encrypted fs and prompts for the access password...
Hopefully! this is my data, not my lottery ticket! i need a bit more reliability than a "hopefully".
i haven't used StegFS, though, so perhaps this hopefully works out to be more theoretical than it sounds, but i'd still like a guarantee that my data will be there unless i choose to delete it. Yeah i know that's tough given the whole deniability thing, but still, i'd like that guarantee.
-f
www.blackant.net
I started poking around, and at http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING there was a url listed for "more recent patches. Going there revealed stuff for 2.4.6, 2.4.8, 2.4.10. 2.4.15, and 2.5.0... I plan to check it out myself when I get some free time.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
when was the last windows EFS release that was not just a vulnerability patch?
by the way, when was the last vulnerability patch?
I have been using this for a year. It works on windows and linux, ok its not free, well infact the source code for the linux one is available for all. It works as a loop back fs, so the "containers" (fikes) for the encrypted data can be copied between machines easily. What filesystem is on the container is up to you, ext2, reiserfs or even msdos. It works on the lastest kernel versions, and has very active support, from jetico and the community. It works using kernel modules so no patching of the kernel is required, having the data in regular files, means its easy to get rid of too. Anyway give it a try http://www.jetico.com
James
I've been working on a project that would be able to do this (one day - hopefully) on Windows, Linux, Solaris, and Mac OS X (Those being the platforms that I have.)
I'm not a crypto whiz and am having serious trouble finding enough information about how filesystems work in order to implement all of the required interfaces. Does anybody know where this information is, or should I look through Linux/BSD sources - and hope that BSD is applicable to OS X?
My current version is pretty much a library that allows you to like apps against it, but doesn't support native operation. The next release will add networking support, but I really need to go native to make it useful to people.
Also, can anybody help decrease the usefulness of the algorithm for decryption so that I can GPL the thing? You can see what I've done from here.
- Malcolm
Or how about a better link, one that explains the issue and how and why it may not be a problem:
l
http://www.safenetworks.com/Windows/syskey2.htm
Basically the way they "hacked" EFS was to reset the user password, and Microsoft already has a mechanism to prevent this, if needed.
Uh, the question was about encrypted file systems which has little or NOTHING TO FUCKING DO WITH NEWBIW INSTALLATIONS OF THE FUCKING OS. In fact I'd go so far as to venture that wondering about encrypted file systems is something no newbie to any OS would ever wonder about. The original topic has nothing to do with fucking configuration apps. Not to mention the dude also suggest Solaris which is pretty easy to install on supported hardware and it has a mature encryption system. Geez man don't attack someone who dares question the omni power of Linux.
I'm a loner Dottie, a Rebel.