Why Not Use Full Disk Encryption on Laptops? 446
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?"
OSX Makes it Easy (Score:5, Informative)
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.
This makes no sense (Score:5, Informative)
The company I work for(financial services) has been using this for over a year now. Not just on laptops, but also all desktops in the company.
At least one bank does (Score:2, Informative)
Re:It should be done. (Score:1, Informative)
actually, the Encrypting File System is built into anything WinXP and after.
http://www.microsoft.com/technet/prodtechnol/winx
But the technology sucks because they have no centralized key management that can be done easily for home users. Even in the enterprise its kinda tricky.
It's the encrypting file system (Score:4, Informative)
It's not really "full disk" encryption, as it applies to a single file or folder.
See [microsoft.com]http://www.microsoft.com/technet/prodtechnol/winx
Re:Password encryption is not very good (Score:1, Informative)
Rolling SecurID codes aren't really suited for pre-boot authentication, as you need a working network to contact the ACE server to authenticate your current code (and laptop users are frequently disconnected from their corporate network).
Re:Vista feature (Score:5, Informative)
Re:It should be done. (Score:3, Informative)
Some data and personal perspective on that point. (Score:5, Informative)
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
eCryptfs (Score:5, Informative)
http://ecryptfs.sf.net/ [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 [wikipedia.org]
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 [sourceforge.net]
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.
Re:Works fine on my laptop (Score:4, Informative)
Really, though, it's not even that difficult to encrypt the root filesystem. The new Etch installer has this built in, and if I'm not mistaken, Vista will too.
I'm not sure what use all those software packages are that are linked on the submitter's home page.
Re:Why Encrypt Everything? (Score:3, Informative)
Not a good defense (Score:5, Informative)
FDE is in use in my workplace (Score:4, Informative)
The performance hit is real and noticeable though, but mostly affects hard drive related tasks, so that does not hinder my working too much.
Also all firms that I have been dealing with use encrypted laptops, so in my perspective the FDE is pretty widely used already
Re:This makes no sense (Score:3, Informative)
Re:Why Encrypt Everything? (Score:1, Informative)
"Full Disk Encryption gives you the access overhead that comes with encryption/decryption for every access to the hard disk."
Performance overhead shouldn't be that much, considering laptop cpu speeds vs laptop disk speeds.
I'd personally worry more about the power consumption overhead.
"Why not just encrypt the sensitive data if you want to avoid leaks of the sensitive data?"
Simplicity. You don't have to do a risk assessment every time you save something,
neither do the people who really shouldn't be allowed to touch a computer, yet your company gave them laptops.
Re:It should be done. (Score:3, Informative)
-Key recovery mechanism:
In my case (and most sane companies), the IT dept with respect to this will let you proceed at your own risk with respect to laptop protected data. With any desktop/laptop install, there is a ever present risk of catastrophic disk failure, so IT policies have to dictate how to cope with sudden loss of all data on a desktop or laptop anyway, if it's because the luser forgot their password or because a drive head started skipping across the platter surface, generally it's all the same. In my case we are provided network storage space, where they manage redundancy, backups, and the associated recovery and maintenance. If the data is so damned important, stick it out there.
I also laid out a strategy for this in another post if IT insists on key recovery. LUKS has multiple key slots and by extension can support multiple passwords. Use a key slot for the IT password unknown to the user, and one other for the user password unknown to IT. User can screw it up if they desire, but users can always screw it up if they want to, the goal is to keep a reasonable expectation of recovery, but can never win in the face of user who does not want the data recovered (unless said user is just too stupid to figure it out).
-Corporate standards.
The standards of the company just have to be intelligent. In my case, standards when first published required that all company data be protected, and they recommend ed gpg or windows folder encryption to start with, for linux and windows respectively. Auditors have examined my setup, and I showed them the indicators of the method I used and pointed out reference material for their review. At the end the auditors, (who were almost entirely windows people), concurred it went above and beyond the corporate standards and after my audit, future users who had a similar setup had a simple, straightforward audit.
PGP Whole Disk Encryption (Score:5, Informative)
If you need a reason why people aren't encrypting their disks, visit the PGP Whole Disk Encryption forum and take your pick.
Re:OSX Makes it Easy (Score:1, Informative)
Windows 2000 lets you encrypt folders... right click, properties, advanced, encrypt contents to secure data
Re:eCryptfs (Score:3, Informative)
dm-crypt is a block device encryption tool. eCryptfs is an actual cryptographic filesystem. Files can sit side-by-side in the same directory and be encrypted with entirely independent sets of keys. Incremental backup utilities can access the encrypted versions of the files. eCryptfs is an order of magnitude more complex and flexible than block device encryption tools.
it seems like reinventing the wheel.
Read the paper:
http://ecryptfs.sourceforge.net/ecryptfs.pdf [sourceforge.net]
Re:Some data and personal perspective on that poin (Score:2, Informative)
Give it a try.
Another advantage for corporate types who have to dispose of old disks securely: If all the data that's ever touched a drive has been encrypted you can probably get rid of it without the DBAN hassle. (No offense to DBAN, it's great)
Re:Hardware aided encryption anyone? (Score:3, Informative)
Whatever hardware assisted encryption there is to be had in Thinkpads would be that stuff provided for 'trusted' computing. I have no insight on what it could actually do *for* the user as opposed to against it, but also based on my experience I don't think I need to offload the work as it isn't that intensive for a single user system anyway.
EncryptionPlus Hard Disk (Score:2, Informative)
Not True for All Laptop BIOSs (Score:4, Informative)
I'll inform all the buyers of low cost paper weights on EBay that they're missing this important feature of the IBM laptops.
While yours is a true statement for some laptops, it isn't a blanket statement for all laptops. There are many exceptions to the rule that BIOS/HDD laptop passwords are easy to break.
Looks like... (Score:4, Informative)
encfs is of course per user, and a somewhat nifty thing there is the pam_encfs module which can optionally used to get the authentication token to unlock its key. The implementation (since it's obviously has to be since it's a fuse thing) is more userspace than ecryptfs, but functionally speaking, what's the difference?
I understand well the benefits compared with dm-crypt strategy based on the circumstances and requirements.
With block level strategies, you have to decide the total size of the block device for protected vs. non-protected data. If you don't understand your needs well, it's difficult to apply a finer-grained approach to security, particularly if you are required to codify it into a company standard for people who you definitely won't understand perfectly the needs of. Because of this, the only generally feasible approach is to encrypt everything save for
encfs and similar strategies feasibly allow finer grained policies to go into place without making the tough size decisions as is needed with block strategies. This provides all the protection from theft and such like dm-crypt does. And if the policies are fine grained and the directories are only mounted as needed, a remote attacker achieving root access will only be able to get to file systems currently mounted, which may be a smaller set than the whole. The difficulty here is that when defining a finer-grained policy, you have to know which directories could ever hold sensitive data, If you are to protect swap you can't use a swap partition, but a swapfile in a directory protected by such a scheme, and in the end on a single user system (almost all laptops), effectively no matter what all the encrypted filesystems will be mounted anyway most all the time, so it's really not ultimately much of a functional difference. I make encfs available on a couple of multi-user systems, and generally have pam_encfs there to make their home directories encrypted.
Re:eCryptfs (Score:3, Informative)
Re:Oh yea, I can hear it now. (Score:5, Informative)
Re:Looks like... (Score:3, Informative)
eCryptfs is kernel-native; EncFS is userspace. Since EncFS is userspace and depends on FUSE, shared memory mappings are not possible. Furthermore, FUSE incurs tremendous overhead with context switching between kernel and userspace; keeping everything native in the kernel during the page reads and writes is a big performance boost.
eCryptfs has an entire infrastructure that is geared toward complex cryptographic policies. This work has yet to be done, but for now, eCryptfs is at least as functional as EncFS when it comes to providing data confidentiality, but eCryptfs can provide full POSIX compliance and it does not incur the overhead of continually bouncing between kernel and userspace.
Re:eCryptfs (Score:3, Informative)
Right. eCryptfs currently only provides data confidentiality for persistent storage in the event of compromise of your physical media. There is other software available to provide integrity (SLIM) and secure swap space (dm-crypt with a random key on boot).
Re:Oh yea, I can hear it now. (Score:3, Informative)
* They lifted the fingerprint off a cd jewelcase.
* The photocopy worked on the expensive system, but not on the simple USB device. In fact the reason they kept dumbing down (in contrast to their usual mode of operation to increase complexity as needed), was that the simple methods didn't work on the usb device. Only the second balistics model worked, which was cast from a manually improved version of the captured fingerprint. When they tried the actual doorlock, everything down to the photocopy turned out to work.
Trade off... (Score:5, Informative)
In the LUKS scheme the key material used for the very large data set will probably be more cryptographically sound. With a large data set, cryptographically weak keys could more likely be crackable than strong keys, in a large number of the type of attacks historically seen in cryptography. A small data set (data comprised only of the actual key) is generally more resistant to data analysis attacks, so a somewhat weaker password hash based key may be less exposed in that context. If you ever think a malicious user has had opportunity to get your password (the most likely thing in general for an attacker to get), you can change the password and the old key slot be shredded such that the knowledge obtained becomes useless. Sure, the 'master password' being compromised would mean the disk is irrevocably compromised, but that would be the case in the classical strategy anyway, since changing the password isn't feasible. Now if you want to actually re-encrypt data in the way a password change would require in the previous example, you can always reformat with a different key (or re-encrypt in place if implementation allowed), and have the same degree of 'changing the master password' as you put it.
Keep in mind the 'master password' (or rather the actual key) in this context is probably a random 256 bit value. To achieve a comparable level of randomness, a password consisting of typable characters would have to be about 40 characters long consisting of completely random keypresses. If a person is ever in a position to actually get that master key value, you've already lost the data because before they can get to that key they have to:
-Get root privilges while the volume is mounted to get dmsetup table output, but if it's mounted they could just grab the data anyway.
-Get low-level physical access to your hardware to begin to crack the LUKS header of the partition or the content itself. If they are in a position to do so, they could/would image your entire volume and return your drive. In which case no matter what you do to the copy you got back (re-encrypt, change password, whatever), they can continue whatever crypto-analysis they want on their image of the data as it was when they first took it. You may be able to protect newly written data, but whatever risk of breaking the encryption on existing data is permanently there once imaging is possible.
-Get low-level access to your system and somewhere along the chain insert something to dump the key material to them once available. Again, once this is in play, it's already over no matter what you do, if they can dump that table, they can dump the data directly. In this case, let's assume one of those keyboard bugs slashdot had an article a while back was discovered by you in your system. Knowing that your passphrase is potentially compromised, with the key not based directly on the password, but just encrypted by the password, you can re-encrypt the key once the bug is removed and shred the old slot, and their keylog data becomes useless for the purposes of defeating your filesystem encryption. If the master key is essentially whatever you typed, you are significantly more hosed.
Re:Because it's a pain on Linux (Score:5, Informative)
There are several ways to encrypt the data on the HDD, and everything depends on how it is done. If you used a 3rd party s/w with a key that is generated from your passphrase then you are good. Just use the same s/w on the replacement computer, and it ought to recognize the drive.
Unfortunately, MS encrypted folders use a key that is uniquely generated for your account, and once you lose the account (on the dead computer) you can't decrypt anything. There are ways to add corporate keys to the system, so that in a company setting it's possible to recover the data; however this is /way/ beyond abilities of a typical user.
Finally, if the TCA [wikipedia.org] is used then the TCA engine and the HDD controller can negotiate crypto keys, and the HDD can encrypt and decrypt data as it writes or reads the platters. This method is very secure because it ties several identities together (the TCA core, the internal HDD key data, the user's password, the account's GUID etc.) and I don't think it's worth trying to break. The good news is that I don't know of any computers today that can do this; maybe Vista will offer this.
Re:Some data and personal perspective on that poin (Score:4, Informative)
I've been running lately from a USB Flash Drive (1GB) with everything but
This also allows you to leave a full installation with no private or incriminating data on the hard drive so if they ask to see the laptop......just let them.
Re:Because it's a pain on Linux (Score:5, Informative)
Actually, it's trivial to export the keys so you can decrypt the files from a different machine. The problem is that this functionality is not mentioned the first time you encrypt a folder, so you only find out about it when you lose days.
Re:Because it's a pain on Linux (Score:4, Informative)
Your instinct is not all bad
You really should encrypt
In fact swap was the first thing I decided to encrypt on my laptop. Encrypting swap is simpler and less intrusive than everything else. Thus there is really not much reason not to encrypt swap. No need for complicated key management, just generate a new random key on every boot.
Re:Because it's a pain on Linux (Score:4, Informative)
(I apologize for my ignorance, I've never looked into disk encryption before
A USB or passcode can be used to access the volume with most of the full volume technologies.
Using the newest one in town as an example, Vista's BitLocker, you can use a USB device to backup your key. Bitlocker also will allow a non TP computer to encrypt a volume as long as the computer has a USB drive and the system is capable of seeing it at boot, and then uses the USB device in place of the TP mechanisms.
Most technologies have passkey or other methods that are user accessible, so that a volume will never be lost due to any hardware failures except if the drive itself fails.
SUSE Howto for encrypted root (Score:3, Informative)
Thankfully not hard.
Comment removed (Score:2, Informative)
Re:Because it's a pain on Linux (Score:3, Informative)
If you have an encrypted file from a Windows XP computer, as long as you know the logon password for the account that encrypted the file, you can decrypt the file. Check out EFS Key [lostpassword.com].
Hardware encryption is the solution (Score:3, Informative)
The cheap stuff only uses 3DES and they key is a USB thumb drive type device, not very secure. But you can get AES capable devices which use password hashes supplied by the BIOS. Something like this... http://www.enovatech.net/products/mx_info.htm [enovatech.net]
Re:Because it's a pain on Linux (Score:3, Informative)
1. Modprobe dm-crypt
2. emerge cryptsetup, run it once after losetup to initialize your device.
3. edit
You can do the root fs with a little more effort but most people won't store anything sensitive outside of their home directory anyway.
Re:SUSE Howto for encrypted root (Score:3, Informative)