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?"
So, why don't we encrypt all our HDDs?" (Score:3, Interesting)
Works fine on my laptop (Score:3, Interesting)
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
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.
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.
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.
Re:OSX Makes it Easy (Score:2, Interesting)
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.
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:We're too stupid (Score:0, Interesting)
As if data encryption and "the environment" (evidently having a verbally abusive workspace isn't considered an important social and environmental issue) are more important than treating half the population like people instead of objects.
Asshole. May your penis wither and die a sad, sad death. If you haven't already beaten it into submission by yourself.
Crypto is mandaroty (Score:2, Interesting)
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: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."
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.
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:OSX Makes it Easy (Score:1, Interesting)
there were dire warnings from burned users that it was buggy and might eat all of your data.
And from then until now, I have not seen a report that the bugs have been fixed. Have they?
Flawed encryption schemes (Score:2, Interesting)
The software has a feature called "Pre-boot Authentication", by which the encryption software is loaded after the bios, but before the (generally Windows) operating system. The user's password is used to generate the decryption key, so theorhetically not even the NSA could decrypt the laptop without the user's password.
Here's the flaw - the software has a checkbox to disable Pre-boot authentication. What this does is generate a default user with a random password, and then store this random password obfuscated but in clear-text in the same disk area decryption software. When you talk to the sales-people, they sell this as a feature, in fact about half of Utimaco's customers (so I'm told) run it in this mode because the encryption becomes transparent and it is much less intrusive on the user. (Basically the disk is automatically decrypted each time the laptop is booted, but you have to have a valid Windows login to get in.) Buried in the help documentation are warnings "For security reasons, you should Never disable pre-boot authentication". So the engineers and the company know the weakness of disabling pre-boot authentication, but they don't tell their customers when they sell the software.
Today it seems to break into these laptops with pre-boot authentication disabled you would need somewhat sophisticated tools and techniques, basically the same tools and techniques people commonly use to "crack" commercial software today. But I'm guessing that it won't be very long before someone takes the time to build this crack and releases it, rendering the laptop encryption useless to anyone who can Google for "Utimaco Crack", etc. Basically all the crack would need to do is grab the default user's password off the disk and use or duplicate the decryption algorithms that are also in clear-text on the disk.
I've talked to a number of IT security folks, and basically it seems like most people trust the sales folks and don't understand that its basically impossible to have strong encryption without having the decryption key stored off the disk (like on a smart card, or in the brain of the user.)
Re:Security vs Convenience (Score:2, Interesting)
So the only way to recover the data on your hard-drive is to pay some company a bunch of money to reset the password. This provides very little security against someone actively trying to gain access to your data, but given that probably every single case that's been in the news with regards to missing laptops with sensitive data on them had the laptop stolen by some punk with no technical skills, it's no big deal. They'll try and start it up, there'll be a password, they'll take it down to the local dealers and try and pawn it off, maybe get $20 for it or something and that'll be the end of it.
Or if they are someone technically competent and realize how to fix it, chances are they'll drop $100 to buy a new hard-drive before they drop $300 or something on recovering the current one.
ND
Re:Oh yea, I can hear it now. (Score:3, Interesting)
Actually he will. All over the laptop, ready to be taken and duplicated.
Re:OSX Makes it Easy (Score:3, Interesting)
Re:Because it's a pain on Linux (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, Interesting)
(I apologize for my ignorance, I've never looked into disk encryption before.)
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
Re:Because it's a pain on Linux (Score:2, Interesting)
Re:OSX Makes it Easy (Score:3, Interesting)
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 coherent sentence 64 characters long or so, which I believe is still an order of magnitude more secure than a mere 10 characters of even complete garbage, but it is much quicker to type 10 garbage characters than a whole sentence...
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.
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.
Re:Security vs Convenience (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 other one was already running, with notepad open. When the teacher came to type in the password, he just thought the computer was broke and assigned the student to a different computer. Needless to say that ALL the bios passwords were the same in the entier school. It didn't take long for someone to install remote controle devices on the teachers PCs, as well as set up servers to host games in the janator's closets.
During college, I did on site tech support. While I was working on probably over a thousand machines over that timeperiod, I've guessed a couple of windows passwords, and it's not like I was trying every time. Sometimes you can pick up quite a bit in a brief conversation and a couple of questions. (Do you have pets, when's your birthday,
Re:Because it's a pain on Linux (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 readable.
Full volume encryption is the most secure obviously, but doesn't mean that you can't make use of file level encryption for sensitive data as well.
Re:Because it's a pain on Linux (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 users having to enter two different passwords (for security, you wouldn't want them to be the same) just to log in.
What you want is for the machine to boot and automatically decrypt the public filesystem information (the OS, and various other directories) securely (ie, it is tied to the machine via a TPM chip of some sort) without the need to identify the user, since you need a valid username and password to login this shouldn't be a security risk over and above any other security risk of someone stealing your laptop and having as much time as they need to fiddle with it.
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.
Re:Because it's a pain on Linux (Score:2, Interesting)
And since it's you saying that, it must be true! Who the hell are all these arrogant people who actually want to see proof, or at least some sort of reasoning behind your statements? Arrogant pricks! You say it's not viable, you have a slashdot account, you are absolutely correct in, and let me emphasize this: every fucking thing you ever say, even in your sleep!!!
Anyway, me being an arrogant prick n' all... Why exactly do you reckon entering a password at boot time is not a viable solution? Remember, we're talking about people with sensitive data on their company laptops, which must be unaccessible under any circumstances should the laptop ever be stolen, so if your whole argument hinges on the "but they're elderly morons who can barely use Windows" line of reasoning, don't waste our time replying.
Which quickly becomes a logistical nightmare in the context of the original question: "Why not use FDE on mobile devices?"... Imagine each and every user of my personal company laptop needing his own personal password to boot the device... Or the trust issues raised by sharing the single password (in case we don't want to go the multi-password route) with all the other users of my personal company laptop. It basically boils down to one of two choices:
- I create a new password for... let me count them... not a single soul on this planet...
- I share my password with, and thus must evaluate the trustworthyness of... let me count them again... nobody!
It's not like I haven't got anything else to do, you know? My shedule is pretty hectic already without all this extra hassle...Because we all know the contents of /tmp, or the logfiles on the computer are utterly worthless without the data in your home directory... The whole friggin' point behind encryption is you leave no possible attack vector uncovered for potential attackers to exploit! You want to make it as hard as possible to get to any data on the harddrive at all, except for a well chosen subset of files on a separate partition needed to boot the computer into the "query for decryption password" stage. On Linux, that means the only partition you don't encrypt is /boot; all the rest, even swap, should be encrypted if security means anything to you.
If, however, "security" means nothing to you, like in your case, why bother with encryption at all? Do us all a favor, and leave this topic to those who actually know something about it, instead of spreading your dim witted halftruths as the holy gospel, ok? There's enough misinformed morons in this world already without you having to dumb them down even more.
Re:Hardware encryption is the solution (Score:1, Interesting)