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?"
I'm confused (Score:4, Insightful)
Re:I'm confused (Score:4, Insightful)
It provided some usual answers, but left plenty of room for debate.
Re:I'm confused (Score:4, Insightful)
Because it's a pain on Linux (Score:5, Interesting)
Encrypting your whole disk on Linux is somewhere between a minor pain and a complete nightmare. Support for it doesn't even exist on certain high-profile commercial distros (Red Hat [redhat.com]) which you would THINK would have had it long ago because it's something their customers would want.
I had to put together my own unofficial packages [ioerror.us] to get an encrypted root filesystem on Fedora Core 5. (And then it broke on FC6, so no upgrading yet...) In theory, the support will officially be in Fedora Core 7, but there's still a bunch of code to be written between now and then.
Re:Because it's a pain on Linux (Score:5, Interesting)
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.
Re:Because it's a pain on Linux (Score:4, Interesting)
(I apologize for my ignorance, I've never looked into disk encryption before.)
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.
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: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: (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. Che
It is not a pain if you have FUSE (Score:5, Interesting)
The most incredibly useful application of this is sshfs [sourceforge.net], which basically lets you mount a remote machine as a filesystem without being root (as long as the FUSE kernel module is loaded). This has caused a huge productivity increase for me.
There is also an encrypted file system that runs under FUSE
http://arg0.net/users/vgough/encfs [arg0.net]
So, you basically can have a big encrypted file lying around which you mount as a file system when you need it. The keys are encrypted in a separate control file, so there are no unencrypted keys lying around. You need both the pass phrase and the encrypted key file to mount the big file as an FS.
Full-Disk vs. File System encryption (Score:4, Insightful)
The reason to encrypt the whole drive as opposed to the writable sections is simply convenience - if you've got hardware assistance, it's probably designed to encrypt the whole disk using some crypto chip in the disk controller, and administratively simpler to use, and if you don't have that, it's probably easier to encrypt individual partitions or filesystems, or sometimes directories, rather than hack up some CPU-based driver that encrypts the whole disk.
From a performance standpoint, it's probably faster *not* to encrypt your program filesystems, and as far as encrypting swap goes, you took the big hit when you started to swap anyway, and rotational+seek latency is usually more of a limitation than overall throughput, so if this bothers you, but some more RAM. Encryption chips on the disk controller are probably faster than CPU software drivers, but not necessarily - your mileage is extremely variable.
Re: (Score:3, Interesting)
For the most part you are correct. However there are file level encryption technologies that DON'T leave the keys unprotected even if they are store on an non-protected volume.
NTFS for example has file level encryption, but unless you logging into the system to access the keys or have the key backup, the encrypted files are visible in the MFT but not readab
Re: (Score:3, Insightful)
Using only encrypted filesystems, then the decryption ke
Re: (Score:3, Interesting)
Requiring a password at boot time has a number of problems. First, you either have to give everyone that uses the computer the same password to boot the system, or you need to use a multi-key encryption routine, which might difficult to maintain as you add or remove new users. Then there's the issue of us
Re: (Score:3, Interesting)
Why bother encrypting the whole disk anyway? My instinct (as a programmer, but knowing not much about security) would be to just encrypt /home, /tmp, maybe /etc and /var, and I guess /swap if I was really paranoid.
What does encrypting the whole disk give you?
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: (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.
Oh yea, I can hear it now. (Score:5, Insightful)
Really, we all know that people will forget/lose the password. Or they'll write it down and leave it in the laptop case.
Re:Oh yea, I can hear it now. (Score:5, Insightful)
Re:Oh yea, I can hear it now. (Score:5, Insightful)
Re: (Score:2, Insightful)
Re:Oh yea, I can hear it now. (Score:5, Interesting)
They lifted a finger print from a soda can of the "owner", then using common chemicals (like acetone), etched a copy out to a circuit board, used that as a reverse and simple ballistics gel to make a fake finger print cover that fit over their own thumb. Not something a petty thief would have, but it wasn't rocket science either. If I could get your laptop, I could get your fingerprint. Maybe even OFF the laptop. This is like writing your password down on a postit note you keep with the laptop.
Finger print readers are probably one of the worst biometric devices you can have for security. Oh, and the device they tested was a VERY expensive door lock system, not some $100 USB device.
Re:Oh yea, I can hear it now. (Score:5, Informative)
Re: (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
Re: (Score:3, Interesting)
Actually he will. All over the laptop, ready to be taken and duplicated.
For a corporate environment... (Score:5, Interesting)
The solution is for IT to have a person perform the install (already was going to be hard not to do so with the current state of installers). The IT person makes a master copy of the key using the company's chosen password, and uses a different key slot for the employee-known password. When password changes occur, IT people have to go and change the IT-friendly key slot to the new password, but leave the employee's alone. Then IT can recover data from laptops at user requests. This doesn't guarantee data recovery from a system if the user who can change the password on their own key slot doesn't want them to, but if the user wants to play nice to keep IT able to assist them it can work. If the user botches the IT key slot and needs recovery, tough. Data on a laptop in that circumstance should be relatively transient if remotely important, with the real copies on file servers where IT can manage backup and recovery as they see fit.
At work the mandate for Windows laptops is to use the built in encrypted folders mechanism, which is a lot like encfs. If they loose their user password for the account the data is gone, and this is just a fact of life they have to live with. One person went further and put some third-party whole disk encryption on their Windows laptop, a la dm-crypt, but I don't know if it is like classic dm-crypt setups where the key itself is simply a hash of the password, or if it is LUKS style, where the key is random (or at least psuedo-random) and itself is encrypted using the hash of passwords, allowing for trivial password changes and multiple valid passwords.
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:Oh yea, I can hear it now. (Score:5, Funny)
I mean... A... friend of mine is like that! Yeah!
10 digit alphanumeric?? (Score:3, Interesting)
Example: cS#e(k5L@^
(note: not an actual password, but generated in the same way I generate passwords)
Maybe I'm >50% autistic then since I can remember these...
On some occasions I wuss out and if appropriate to the password parsing/entry technology, make a mostly coheren
Re:Oh yea, I can hear it now. (Score:5, Insightful)
#1 The unions would never go for it. I've worked at governmental agencies that couldn't make basic computer literacy a condition of employment, because of the union.
#2 It attempts to solve a problem by demanding that people be responsible for their own idiocy. What happens when the Big Boss writes down his password? Trust me, the only guy getting fired for that is the IT guy who tries to enforce the policy.
Re:Oh yea, I can hear it now. (Score:5, Insightful)
You are not a manager, clearly. Termination of someone's employment will cost your company a lot of money, time and lost opportunity (unless you wanted to get rid of that employee anyway; then you have your excuse.) People are trained to do their jobs, and they are not as replaceable as an elevator operator might be. Some people train for years to do certain things, and they become really good in their area of expertise. They may be highly paid (and valued) engineers, leading designs and themselves managing projects. If such a person forgets the password what do you do, fire him and cancel the already announced release of a new product, which the customers already paid for and the delivery is due in weeks, and penalties for failure to deliver would be immense? If you fire the guy, you will be kicked out of your job so hard you will overtake him on your trajectory to the door.
What a real manager does is this. He tries to understand how this happened, and then does his best to prevent this from happening again. This may require a private chat with the person, or an official department-wide training. The data... the data is lost already, and it's foolish to make it worse by firing the guy who is best to recreate it. Your job, as a manager, is to get the job done. Firing people in a fit of rage is not the way to do it.
Vista feature (Score:4, Insightful)
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:Vista feature (Score:5, Informative)
Re:Vista feature (Score:5, Interesting)
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."
Security vs Convenience (Score:5, Insightful)
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)
Re:Security vs Convenience (Score:5, Interesting)
People don't like to use secure passphrases each time they turn on their computer. How many people actually used the BIOS password feature?
because BIOS passwords are extremely insecure. If were talking about mobile devices, and you have a BIOS password protecting valuable information, its as easy as removing the CMOS battery, waiting 15 seconds, and popping it back in.
An easier thing would be to use some identification based (USB fob, fingerprint scanner) access
Yes but these things are generaly expensive. When you have to buy 1000+ laptops (as I have to do) an extra $30-$40 per laptop quickly adds up, not to mention the added cost of Software (Unfortunaly, linux isnt always an option when dealing with custom propritary software required for bussiness)
The real problem normaly stems from over-zealous Managers who insist on changing passwords every 30 days, which leads to people (ie the common work drone) unable to remember ever-changing passwords. IMHO, it would be much more secure to have everyone figure out a strong SINGLE password for their important files, and not change it very often, say every 6 months. This gives them time to memorize it, and NOT write it down.
For example, i have two passwords I use everywhere, (and various modifications of such passwords for various purposes) my crap one I use for fourms, internet stuff, and my secure one I will probably take a good 10 minuites of torture to give up (low tolerance for pain
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.
Re: (Score:3, Interesting)
I used to have a screen saver password, that I had just recently turned off. When I got back to my computer, my screens were on power save mode, and I was used to just moving my mouse, and typing in the password. Instead, I typed the password in an IM window, that happened to be in focus.
I have also seen some people in my high school steal the bios password, by swapping key boards between two adjacent PCs. While one was waiting for the password to be entered, the
It should be done. (Score:5, Insightful)
But then again, I use linux. Encryption is actually pretty simple under it for people who actually know how to admin a Linux system.
At one time, I even ran Win2k under VMware from an image on the encrypted disk. Which means the *ENTIRE* win2k "partition" was encrypted -- something that I understand to be impossible when run natively.
The real reasons why most don't do it?
1) Ignorance -- it is not a built-in feature in Windows
2) Hassle -- overtasked IT professionals aren't going to incur extra liability for encrypting a disk, handling lost passwods, etc. (It would be really bad to forget the password)
3) Performance -- Encrypted disks aren't good for high I/O apps... Fortunately, most apps aren't!
I sleep much better, knowing that my data is safe even if I loose possession of it. I have no qualms about storing tax returns, financial records, etc on my laptop.
Re:It should be done. (Score:5, Funny)
But then again, I use linux. Encryption is actually pretty simple under it for people who actually know how to admin a Linux system.
Likewise, constructing plasma weapons is actually pretty simple for people who actually know how to build compact fusion reactors.
Re: (Score:3, Informative)
Re: (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
more RAM (Score:3)
Hardware aided encryption anyone? (Score:2)
Re: (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
So, why don't we encrypt all our HDDs?" (Score:3, Interesting)
Re: (Score:2, Insightful)
its not hard to do either
Re: (Score:2, Insightful)
Not a good defense (Score:5, Informative)
I can think of one reason... (Score:3, Insightful)
Anything with moving parts is bound to break, and if you move it about it'll just break all the faster.
So can't it be a serious problem if your data is encrypted and bytes get knocked out here and there?
Also, mobile devices are usually much slower than stationary ones and will only get slower if it has to apply complex algorithms to all data that goes in and out. And that would probably also put a real big penalty on your battery life.
It boils down to one thing: You have to select a cost-effective level of paranoia. It would make your life infinitely complex to secure yourself against every possible scenario. How important is the secrecy of your data?
Is the juice worth the squeeze?
Re:I can think of one reason... (Score:5, Insightful)
Works fine on my laptop (Score:3, Interesting)
Re: (Score:2)
Obscure. Nah ...
Then again, they may be right-clicking for some time ...
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.
The Real Problem...USERS (Score:2, Insightful)
Besides, how many laptops would then have the password for FDE engraved into them, or with a nice post-it note on them? And what would this password be? Their mother's name? Their birthday? Their dog's name? The street they live on? Users are notorious for using horrendously uncomplicated passwords.
on the other hand, if someone were to use say MdLg25GvNtUp35
Then yea,
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.
Re: (Score:2)
FileVault rocks. OSX even includes secure virtual memory (pretty big performance hit, but a real good idea on multi-user machines).
Re: (Score:3, Interesting)
FileVault (Score:4, Interesting)
On my systems, I have symlinks set up between ~/Music and
If you do it this way, FileVault doesn't carry too huge a performance hit. It also has the advantage of allowing you to back up your documents in a secure fashion pretty easily: you log in as a different user, and just back up the File Vault sparseimage as a single file.
The "do you want to recover space" logout screen is fairly obnoxious, agreed; I hate it just because it stops the shutdown process with a dialog that requires human interaction. I wish it had some sort of a 30-second-countdown-to-default timer, so that if I hit "shutdown" and walk away, the process doesn't get hung up and just sit there, unsecured, forever.
File Vault has free space issues (Score:3, Insightful)
Re: (Score:3, Interesting)
I haven't clicked on the link, but he's talking about LMHASH passwords. Why don't you look up the last version of Windows that used LMHASH? I am often asked to recover forgotten Windows Admin passwords at work, and I haven't run into an LMHASH password fo
Password encryption is not very good (Score:2)
Unless you plan on memorizing an extraordinarily long password, the encryption you're going to get is not going to be very good. Better than nothing if you don't have anything too important on your drive, but if you have anything important on the drive then you're gonna have to consider it leaked when your laptop goes missing.
How would that work? I thought the key in the hardware token was constantly cha
Re: (Score:2)
I guess that's slightly more secure than just carrying the key on a regular USB key - if the token is relatively tamper-resistant.
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.
Re: (Score:3, Informative)
At least one bank does (Score:2, Informative)
Why Encrypt Everything? (Score:5, Insightful)
Plus, a lot of the recent newsworthy leaks would be avoided or minimized by using encrypted access to sensitive databases via an application on the laptop, rather than people copying large databases of sensitive data to their laptop to take it home and work on it, and then losing the laptop.
Re:Why Encrypt Everything? (Score:5, Insightful)
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.
Re: (Score:3, Informative)
Comment removed (Score:3, Insightful)
Encryption enshmiption (Score:5, Funny)
Simply (Score:2)
If you do need to ensure something isn't stolen and you absolutely have to have it on your laptop without a net connection, then there are plenty of utilities that allow you to mount encrypted partitions.
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.
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: (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 do
Re: (Score:3, Informative)
Re: (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: (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]
incremental/differential backups (Score:2, Interesting)
Except that every day's incremental backup becomes a de facto full backup. So you have to start the backup as soon as you get to the office if you want to leave on time.
Physical Security... (Score:5, Interesting)
I continue to wonder, after every major laptop theft, why NOBODY is working on physical security.
Notebook hard drives are easily pocket-sized, and the only thing keeping the hard drive from sliding out of most laptops is the thin plastic shell of the unit. Build laptops with a very simple hinging door over the drive would be absolutely trivial. You probably also want to add thin aluminum shell around the drive to protect it from static discharge and other abuse.
Then, you tell employees to keep the drive in their pockets when they go into public. If it's really critical data, attaching a retractable cable (as seen attached to your janitor's keyring) between your belt and the drive will stop all but the most skilled, equiped and determined theives.
It's as if everyone in IT has forgotten the lessons learned from the past several thousand years of (physical) security developments.
Obligatory I'm more Old School than you post (Score:2)
Stupid idea. (Score:5, Interesting)
- Performance - encrypting everything (cache, program files and so on) is a serious hit on performance, now you can say that hardware/performance it is not a problem. But don't say it to me when I see brand new laptop booting long time since you can login and launching MS Office in *few* seconds.
- Anyway why encrypt everything when it is the data (and not all of it) that you want to encrypt?
- Hassle - I mean when it is an option to just tick "encrypt my harddrive" checkbox it is paradoxically way to easy. You can imagine every clueless marketing staff member just ticking it to encrypt their worthless data. It is good that hard encryption is bit "hard" (like you need to provide a password and a key and have a clue what is going on) so people will use it only when they need it, so they will probably remember their passwords.
My boss asked me for this feature. I've just installed TrueCrypt for this. Told him to click on this icon and *remember* his password (probably he wrote it down and locked in a safe - perfectly normal and wise) so he can get his "special safe disk" for his important documents.
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
I already did... (Score:3, Interesting)
For what it's worth, this gig was all wireless on campus too, with VPN inside and outside the firewalls. I'm doing a long-term gig with a major financial firm now, and they don't use FDE. And they have NO, repeat NO NO NO wireless. The security team trolls constantly for unauthorized wireless and anything that transmits is confiscated as soon as they find it - cut out and trashed.
Both these firms suffer the same risks for their data. Either would suffer financially and risk complete failure if a critical breach ocurred. Just different ways of doing things.
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.
context (Score:5, Insightful)
In such a context, given that FDE makes data recovery harder and more time-consuming, it can make sense to encrypt only that tiny fraction of data where one would more mind its becoming public than one's losing it. In other contexts, it will be different.
Theres another question not being asked (Score:3, Interesting)
When I was issued a company laptop, I jumped right on the encryption bandwagon. I used Linux, so I encrypted umy home directory sing loop-aes. Unfortunatly I was usin Gentoo at the time, and this was early in the 2.6 kernel series, before loopback encryption was standard in the kernel. So I was using some kind of third-party kernel AES crypto module (still not exactly sure what it wasusing, emerge took care of the details).
Anyways, months later, my OS install goes haywire. For what reason now I don't remember. No big deal I thought, I will just re-install.
Problem was, with the current Gentoo, I couldn't decrypt my drive.
Skip ahead 4 days later. I have tried *everything* to decrypt this data - posted in forums, talked to crypt developers, even tried writing an AES routine myself to get the raw volume at least. Nada. I ended up giving up and starting over - after all, nothing *important* was lost, but I did lose 2 years woth of archived emails I really would have liked to keep.
Oh, what about backups you say? Well security-consious as I was, I decided to back up the encrypted volume.
Needless to say I remain very wary of full-disk encryption in any form. And I always back up unencryupted. Secure? maybe not. But at least I know that if I have a filesystem crash I can use standard ext2 recoveryt ools to get my essential files back.
Halfway (Score:3, Insightful)
The simply solution is to use USB disks/keys with encryption and stick all sensitive data on those. You can get 4 Gb solid-state and larger if you use something like an iPod. How many people really need > 4 Gb of secure data available off-net? The vast majority would be fine with fast USB 2.0 memory sticks.
Key escrow solves the "I lost my password" as well as employees that leave without telling their boss/replacement the passwords.
For super-secure stuff, make them call home first to check a CRL and validate they still have permission.
For those that don't like the USB stick solution, then partition hard drives and just don't encrypt C:\.
Charles
won't matter... (Score:3, Interesting)
How about we train people who hold sensitive data on how to manage it?
There's a shocking cool idea...
Tom
Why is the data on a laptop in the first place? (Score:3, Insightful)
When I do consulting work (especially with regards to security), I often compare putting sensitive data on a laptop to putting the company's main database directly accessible on the Internet and hoping that whoever attacks it can't exploit it or guess a username/password combination. That will usually scare a few people into thinking about what they are doing, and the others who think that it is alright probably deserve nothing less than getting hacked.
As for disk encryption, it works well IF it is transparent to the user and IF the overall security is indeed strengthened by such encryption, because a weak link like a poor password adds no actual security value where it is expected.
nonsense (Score:3, Interesting)
Most of the data on most machines is neither secret nor special - it's the OS and applications binaries, libraries, graphics, etc.
Encrypting
(*) and he's conveniently not telling you that encryption isn't the end-all solution. There are plenty of ways of breaking even the best crypto without actually breaking it. Getting the key is often easy because people write it down or treat it carelessly.
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]
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
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.
SUSE Howto for encrypted root (Score:3, Informative)
Thankfully not hard.
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
If someone steals the laptop and can't access the data, all you lost was the laptop, your access to it, and your modifications of the contents (you do have it backed up at the office, don't you)?
If someone steals the laptop and the data is available, you've lost the laptop and your access to it. But you might be able to retrieve your modifications of the contents when they are posted across the I
Re: (Score:3, Insightful)