Why Not Use Full Disk Encryption on Laptops?

Saqib Ali asks: "According to the 2006 Security Breaches Matrix, a large number of the data leaks were caused due to stolen/missing laptops. Mobile devices will be stolen or lost, but one way to easily mitigate the harm is to use Full Disk Encryption (FDE) on all mobile devices. So, why don't we encrypt all our HDDs?" "Cost, and performance impact are the usual arguments.

Analysis shows that the access time increases by 56%-85% after FDE. As HDDs fills up the fragmentation increases and so will the file access time. With FDE, the swap file (system's virtual memory) gets encrypted as well. This will impact the system's performance noticeably when the virtual memory is being used more often.

Encryption key & password management blues follow. What happens when the user forgets his/her new FDE password? How to manage the encryption key backup files? Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys? Who can access the system and its encrypted files? How frequently does the password need to be changed? How to prevent the user from writing the passwords down? Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!

Cost for Full Disk Encryption solutions ranges from $0-$300.

Is it not worth using Full Disk Encryption on mobile devices after all the data leaks we have seen in the last few years?"

Comments

OSX Makes it Easy

[Above]

System Preferences -> Security. Click "turn on file vault". A few minutes later, you're done.

Also check "Use secure virtual memory" (aka encrypt swap) on the same tab.

Now swap and your home directory (so all important data) is encrypted. The OS and applications are not. As a result performance degredation is minimal.

In the business enviornment the business can set a recovery password in case the user forgets, dies, whatever. The user's login password is the only password they need.

Free. Easy to use, you do nothing. Minimal performance impact. So the real reason most people aren't doing it? They are stuck with Windows bloatware or are ignorant.

Re:Vista feature

[Adam9]

That would be BitLocker.

Some data and personal perspective on that point.

[Junta]

This post written from a laptop with a LUKS-root filesystem. I catted a 280 MB file into dev null, it took 17.8 seconds. I copied that file to a filesystem on the exact same drive, umounted the filesystem, remounted it, and tested that, it took 12.5 seconds Top showed the crypt activity as taking about 50% of my cpu in the first case, my Pentium M at the time of measurement clocked only up to 800 MHz to accommodate the load. This test was repeated a few times with a small degree of variation.

Anyway, those metrics are actually more different than I would have expected. I was hoping to demonstrate that the difference isn't that much, but objectively it is disk io performance hit. In general use I don't notice it. I already had a crappy hard drive that was dog slow, and in the end adding encryption made it... still a crappy hard drive that is dog slow, and the extra slowness I didn't even bother perceiving until I tried to measure it. I used this laptop for a few weeks with no encryption, and on the next install did encryption from the get go on everything from /, and didn't notice a problem at all.

eCryptfs

[omnirealm]

A new addition to the 2.6.19 Linux kernel, eCryptfs, addresses many of these problems:

http://ecryptfs.sf.net/

eCryptfs is an actual filesystem operating at the VFS layer of the Linux kernel. It stacks on top of other filesystems like ext3 and encrypts files one at a time, with each file getting its own key.

Who cares about encrypting libc or the x.org libraries? People want to encrypt their financial, medical, and other such data. eCryptfs makes it easy to encrypt only what users want to encrypt.

Some ways that eCryptfs deals with the issues raised:

What happens when the user forgets his/her new FDE password?

The best answer is, ``You're screwed.'' That is the way it should be; without the secret, nobody -- not even you -- can get to the data.

Now, out here in reality, things can't be quite that convenient. Try telling the CEO that his third-quarter reports are lost forever. The next-best thing is intelligent key escrow. I tend to recommend (m,n)-threshold sharing, wherein a certain number of people in a group need to collude (say, 3 out of 5 people in the company) in order to reconstruct the secret value.

eCryptfs userspace tools have a pluggable key management infrastructure, and thus it can keep the secret value in any token device for which a module exists. These hardware devices do not need to be expensive. In fact, Thinkpads come with TPM chips built-in, and a TPM key module already exists for eCryptfs:

http://trousers.sourceforge.net/tpm_keyring2/quick start.html

How to manage the encryption key backup files?> Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys?

All of these are addressed with something like (m,n)-threshold sharing:

http://en.wikipedia.org/wiki/Secret_sharing

Also, because eCryptfs encrypts on a per-file basis, an incremental backup utility can just access the encrypted files on the lower filesystem. All of the information needed to decrypt the files is right in the header of each file; all you need is the key.

Who can access the system and its encrypted files?

This is a semantic security problem that the tools should definitely address. eCryptfs, in its current form, provides fairly flexible key management options, but the design goals of eCryptfs are much more ambitious, and they seek to address these sorts of issues:

http://ecryptfs.sourceforge.net/ecryptfs.pdf

How frequently does the password need to be changed?

Ideally, one would use eCryptfs in public key mode, so that is largely a non-issue. The secret can remain locked in a TPM chip, and the key can be escrowed.

How to prevent the user from writing the passwords down?

There is nothing wrong with writing passwords down, as long as the paper on which the passwords are written is stored in a location that can be made at least as secure as is necessary to protect the data that the passwords are protecting. In any event, the secret value can depend on a password *and* something else, like a file. The OpenSSL key module can be used in that way.

Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!

Not really; many laptops shipped today have TPM chips built-in.

Oh, yeah, and all of eCryptfs -- both the kernel and userspace components -- are GPL. Give it a try.

PGP Whole Disk Encryption

[Simon Garlick]

http://forums.pgpsupport.com/viewforum.php?f=54&si d=749efb5b59855bac7e1a06eda016e4a9

If you need a reason why people aren't encrypting their disks, visit the PGP Whole Disk Encryption forum and take your pick.

Re:Oh yea, I can hear it now.

[bluephone]

The fingerprint door lock also opened with what was essentially a photocopy of the fingerprint too. A lot easier to store in your wallet and slip by security with than a gelatin finger. :)