Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2007/04/10/encfs.html

One of my biggest worries in using a laptop is that data
can suddenly become available to anyone in the world if a laptop is
lost or stolen. I was reminded of this during the mainstream
media coverage¹ of this issue last year.

There’s the old security through obscurity perception of running
GNU/Linux systems. Proponents of this theory argue that most thieves
(or impromptu thieves, who find a lost laptop but decide not to return
it to its owner) aren’t likely to know how to use a GNU/Linux system,
and will probably wipe the drive before selling it or using it.
However, with the popularity of Free Software rising, this old standby
(which never should have been a standby anyway, of course) doesn’t
even give an illusion of security anymore.

I have been known as a computer security paranoid in my time, and I
keep a rather strict regiment of protocols for my own personal
computer security. But, I don’t like to inflict new onerous security
procedures on the otherwise unwilling. Generally, people will find
methods around security procedures when they aren’t fully convinced
they are necessary, and you’re often left with a situation just as bad
or worse than when you started implementing your new procedures.

My solution for the lost/stolen laptop security problem was therefore
two-fold: (a) education among the userbase about how common it is to
have a laptop lost or stolen, and (b) providing a simple user-space
mechanism for encrypting sensitive data on the laptop. Since (a) is
somewhat obvious, I’ll talk about (b) in detail.

I was fortunate that, in parallel, my friend Paul and one of my
coworkers discovered how easy it is to use encfs and
told me about it. encfs uses the Filesystem in
Userspace (FUSE) to store encrypted data right in a user’s own home
directory. And, it is trivially easy to set up! I used Paul’s tutorial
myself, but there are many published all over the Internet.

My favorite part of this solution is that rather than an onerous
mandated procedure, encfs turns security into user
empowerment. My colleague James wrote up a tutorial for our internal
Wiki, and I’ve simply encouraged users to take a look and consider
encrypting their confidential data. Even though not everyone has
taken it up yet, many already have. When a new security measure
requires substantial change in behavior of the user, the measure works
best when users are given an opportunity to adopt it at their own
pace. FUSE deserves a lot of credit in this regard, since it lets
users switch their filesystem to encryption in pieces (unlike other
cryptographic filesystems that require some planning ahead). For my
part, I’ve been slowly moving parts of my filesystem into an encrypted
area as I move aside old habits gradually.

I should note that this solution isn’t completely without cost. First,
there is no metadata encryption, but I am really not worried about
interlopers finding out how big our nameless files and directories are
and who created them (anyway, with an SVN checkout, the interesting
metadata is in .svn, so it’s encrypted in this case).
Second, we’ve found that I/O intensive file operations take
approximately twice as long (both under ext3 and XFS) when using
encfs. I haven’t moved my email archives to my encrypted
area yet because of the latter drawback. However, for all my other
sensitive data (confidential text documents, IRC chat logs, financial
records, ~/.mozilla, etc.), I don’t really notice the
slow-down using a 1.6 Ghz CPU with ample free RAM. YMMV.

---

¹
BTW, I’m skeptical about the FBI’s claim in that
old Washington Post article which states
“review of the equipment by computer forensic teams has
determined that the data base remains intact and has not been
accessed since it was stolen”. I am mostly clueless about
computer forensics; however, barring any sort of physical seal on
the laptop or hard drive casing, could a forensics expert tell if
someone had pulled out the drive, put it in another computer, did a
dd if=/dev/hdb of=/dev/hda, and then put it back as it
was found?