Slashdot Mirror
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?"
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?"
Really, we all know that people will forget/lose the password. Or they'll write it down and leave it in the laptop case.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Most of the key management problems have actually been solved. PGP disk for a long time had the ability to encrypt using multiple keys, fraction keys (eg. 3 out of 5 must have their keys to open), key expiration, etc.
The real problem is convenience. People don't like to use secure passphrases each time they turn on their computer. How many people actually used the BIOS password feature? An easier thing would be to use some identification based (USB fob, fingerprint scanner) access, but the acceptance rate of those are very small.
Unless security is important to them personally, people just don't care. (checking under my keyboard for the root password for all the machines at work)
Will the War in Iraq get better or worse in 2007? Vote here
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.
That would be BitLocker.
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.
/, and didn't notice a problem at all.
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
XML is like violence. If it doesn't solve the problem, use more.
A new addition to the 2.6.19 Linux kernel, eCryptfs, addresses many of these problems:
k start.html
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/quic
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.
An unjust law is no law at all. - St. Augustine
Sensitive data gets dumped to the swap file, Your word/spreadsheet/e-mail/other client will dump backup/temp copies in unencrypted places, etc etc etc.
It isn't enough just to encrypt sensitive information, you have to make sure every application that touches the info will not compromise your efforts.
[Fuck Beta]
o0t!
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.
-----
PGP Key ID 0xCB8FF658
Mac OS X has had filevault for years now...
Hard Drive encryption on the fly, and "Company administrators can set up a computer-wide master password as a safeguard in the event someone forgets his or her login password. This can be useful for computer or system administrators whose users either forget their passwords or in corporate situations where an employee is no longer with the company and the data left behind needs to be recovered."
Encrypted filesystems are not the same thing as full disk encryption. FDE also encrypts partition tables, boot sectors, etc... everything, and typically requires some kind of hardware assistance like a TPM chip. There is also "mostly" full disk encryption which has an unecrypted boot record but has everything else encrypted.
The point of a FDE is that your encryption keys are locked in a TPM chip of some sort, and you can't retrieve them with software. Encrypted filesystems require your boot partition have the encryption keys unencrypted so that they can be read, which sort of mitigates the whole point.
If you need web hosting, you could do worse than here