Forgot your password?

Why Not Use Full Disk Encryption on Laptops? 446

Posted by Cliff
from the mitigating-risk-of-data-leaks dept.
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?"
This discussion has been archived. No new comments can be posted.

Why Not Use Full Disk Encryption on Laptops?

Comments Filter:
  • I'm confused (Score:4, Insightful)

    by Umbral Blot (737704) on Saturday October 21, 2006 @06:35PM (#16531655) Homepage
    If the summary answers its own questions why even bother posting comments? Except to be a smart-ass (like me).
    • Re:I'm confused (Score:4, Insightful)

      by eric76 (679787) on Saturday October 21, 2006 @07:06PM (#16531911)
      You might have a point if the summary answered its own question.

      It provided some usual answers, but left plenty of room for debate.
    • Re:I'm confused (Score:4, Insightful)

      by Wilson_6500 (896824) on Saturday October 21, 2006 @07:42PM (#16532139)
      Maybe they're getting tired of the "yes, no, maybe" tags that always show up whenever they ask a yes/no question?
    • by IO ERROR (128968) <> on Saturday October 21, 2006 @07:49PM (#16532199) Homepage Journal

      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 []) 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 [] 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.

      • by man_of_mr_e (217855) on Saturday October 21, 2006 @08:15PM (#16532359)
        Encrypted filesystems are not the same thing as full disk encryption. FDE also encrypts partition tables, boot sectors, etc... everything, and typically requires some kind of hardware assistance like a TPM chip. There is also "mostly" full disk encryption which has an unecrypted boot record but has everything else encrypted.

        The point of a FDE is that your encryption keys are locked in a TPM chip of some sort, and you can't retrieve them with software. Encrypted filesystems require your boot partition have the encryption keys unencrypted so that they can be read, which sort of mitigates the whole point.
        • by MobileTatsu-NJG (946591) on Saturday October 21, 2006 @09:52PM (#16532899)
          Question: Suppose you use FDE to encrypt your disk, then your laptop dies. Is it possible to hook it up to another machine via USB enclosure and recover the data?

          (I apologize for my ignorance, I've never looked into disk encryption before.)
          • by TheNetAvenger (624455) on Sunday October 22, 2006 @02:10AM (#16533862)
            Question: Suppose you use FDE to encrypt your disk, then your laptop dies. Is it possible to hook it up to another machine via USB enclosure and recover the data?

            (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.

        • by Pausanias (681077) <pausaniasx@gmail . c om> on Saturday October 21, 2006 @11:45PM (#16533258)
          No. You should read up on a nifty module (included in the mainline kernel) called FUSE []. It lets a you mount various devices/files as private file systems.

          The most incredibly useful application of this is sshfs [], 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


          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.

          Encrypted filesystems require your boot partition have the encryption keys unencrypted so that they can be read, which sort of mitigates the whole point.
        • by billstewart (78916) on Sunday October 22, 2006 @12:25AM (#16533410) Journal
          Obviously you want to encrypt your user data directories or filesystems, and you may want to encrypt your swap (depending on your threat model.) On Unix, there's no particular need to encrypt most of the file systems that programs live in (e.g. /usr can be read-only unencrypted, though /var should be encrypted.)

          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)

          by TheNetAvenger (624455)
          Encrypted filesystems require your boot partition have the encryption keys unencrypted so that they can be read, which sort of mitigates the whole point.

          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, Interesting)

        by IWannaBeAnAC (653701)

        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?

        • by kasperd (592156) on Sunday October 22, 2006 @01:47AM (#16533740) Homepage Journal
          Why bother encrypting the whole disk anyway?
          If you are using a hardware solution, encryption the whole disk may be the only option. Otherwise, you only need to encrypt those partitions containing sensitive data.

          My instinct would be to just encrypt /home, /tmp,
          Your instinct is not all bad :-)

          maybe /etc and /var,
          You really should encrypt /var, it does contain a tmp directory, and also some spools such as mail spool and printer spool. /etc is not the most important to encrypt, but still I would encrypt it. /usr I wouldn't encrypt unless it just happened to be on the same file system as something I wanted to encrypt. Encrypting just some directories on a file system is less practical. It requires support from the file system, and such encryptions are more complicated and thus more prone to have weaknesses because of bad design or implementation. I'd either encrypt everything but /boot, or maybe put /usr on a seperate unencrypted partition.

          and I guess /swap if I was really paranoid.
          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)

        by Mr_Perl (142164)
        Gentoo makes encryption of your home partition + swap dead simple. Set up your tmp directories with tmpfs (like you should anyhow on a laptop)

        1. Modprobe dm-crypt
        2. emerge cryptsetup, run it once after losetup to initialize your device.
        3. edit /etc/cryptfs based on the examples

        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.
  • by AltGrendel (175092) <ag-slashdot @ e x i t> on Saturday October 21, 2006 @06:37PM (#16531675) Homepage
    What do you mean, you can't reset my password for my hard drive. I need the data NOW!

    Really, we all know that people will forget/lose the password. Or they'll write it down and leave it in the laptop case.

    • by dabraun (626287) on Saturday October 21, 2006 @06:42PM (#16531707)
      Probably should make the password change prodedure for your organization automatically backup the keys to a server at the same time so that your IT department can recover them for you.
    • Re: (Score:2, Insightful)

      Or, you can use a fingerprint reader. I doubt that anybody will forget their fingerprints...
      • by Pharmboy (216950) on Saturday October 21, 2006 @08:02PM (#16532275) Journal
        Did you ever see the Myth Buster episode where they tried to spoof a finger print reader? No matter how hard they tried, everything they attempted worked. Yes, worked. It became a big joke and they had to keep making the method "dumber", but still it kept gaining access.

        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.
        • by bluephone (200451) <grey AT burntelectrons DOT org> on Saturday October 21, 2006 @08:37PM (#16532523) Homepage Journal
          The fingerprint door lock also opened with what was essentially a photocopy of the fingerprint too. A lot easier to store in your wallet and slip by security with than a gelatin finger. :)
        • Re: (Score:3, Informative)

          by risk one (1013529)
          Not that I generally disagree with you, but a couple of points, just to be pedantic:
          * 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)

        by suv4x4 (956391)
        Or, you can use a fingerprint reader. I doubt that anybody will forget their fingerprints...

        Actually he will. All over the laptop, ready to be taken and duplicated.
    • by Junta (36770) on Saturday October 21, 2006 @07:17PM (#16531993)
      I'm going to use LUKS as my example, since the classic cryptoloop and older dm-crypt stuff can't do this.

      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.
    • by Jugalator (259273) on Saturday October 21, 2006 @07:45PM (#16532159) Journal
      Or they'll be half-autistic introvert geeks that have absolutely no problem recalling 10 digit alphanumeric passwords at all!

      I mean... A... friend of mine is like that! Yeah!
      • by Junta (36770)
        Wuss, my passwords are almost always inclusive of non-alpha/non-numerical values and are at least 10 characters long. My strategy is ofter to randomly hit buttons without looking, making generous use of the shift key on the number keys...
        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
  • Vista feature (Score:4, Insightful)

    by dabraun (626287) on Saturday October 21, 2006 @06:39PM (#16531683)
    Doesn't Vista have a built-in feature for full disk (or all but system files) encryption? Can't you even just check off the 'encrypt' option on the properties sheet for your my docs folder (even on XP) ... or your entire user profile (to cover outlook OST etc, though that is already encrypted I believe, or can be configured to be in outlook).
  • by Retardican (1006101) on Saturday October 21, 2006 @06:40PM (#16531687) Homepage
    Most of the key management problems have actually been solved. PGP disk for a long time had the ability to encrypt using multiple keys, fraction keys (eg. 3 out of 5 must have their keys to open), key expiration, etc.

    The real problem is convenience. People don't like to use secure passphrases each time they turn on their computer. How many people actually used the BIOS password feature? An easier thing would be to use some identification based (USB fob, fingerprint scanner) access, but the acceptance rate of those are very small.

    Unless security is important to them personally, people just don't care. (checking under my keyboard for the root password for all the machines at work)
    • by Anonymous Coward on Saturday October 21, 2006 @07:04PM (#16531887)

      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 ;) As of yet, the secure one has never been broken, and only through social engineering has the insecure one been broken. Ive done this for 16+ years now, and I can count on my hand the number of times its been broken.
      • by Inhibit (105449) on Saturday October 21, 2006 @08:23PM (#16532437) Homepage Journal
        "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."

        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.
  • It should be done. (Score:5, Insightful)

    by woolio (927141) on Saturday October 21, 2006 @06:42PM (#16531697) Journal
    I for one, do use full encryption... Suits me just fine...

    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.
    • by PacoTaco (577292) on Sunday October 22, 2006 @12:28AM (#16533414)

      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.

  • by TheSHAD0W (258774) on Saturday October 21, 2006 @06:42PM (#16531703) Homepage
    Boosting system memory is one good way to mitigate the problems of FDE. Eliminating the need for swap space and buffering commonly accessed files helps reduce the amount of disk throughput needed. Sticking browser caches and other temporary file space in a virtual drive would also greatly improve performance. It might even be worthwhile looking to produce slow but inexpensive RAM just so you could make volatile RAM drives for this purpose.
  • IBM have been providing encryption hardware for laptops for a while.
  • by 56ker (566853) on Saturday October 21, 2006 @06:43PM (#16531715) Homepage Journal
    Because it slows it down, laptops can have user authorisation anyway (fingerprint or username/password combo) - and short of physically taking the harddrive out and reading it or booting from a CD there's very little someone can do to access the info on it without that. The point is - people just shouldn't be putting confidential stuff on laptops in the first place because of the security risk not just from theft but from casual users finding something they shouldn't or the computer geek repairing it.
    • Re: (Score:2, Insightful)

      ... short of physically taking the harddrive out and reading it or booting from a CD ...

      its not hard to do either
    • Re: (Score:2, Insightful)

      by Extide (1002782)
      So how is an on the road sales guy supposed to work? I would say in most cases ANY employees email inbox is considered confidential by default. In fact most of the stuff many on the road guys will have on their laptops IS confidential, and they NEED those laptops in order to do business. I dont think there is an excuse these days. We have plenty of CPU power available so doing the encryption/decryption in realtime shouldnt be that bad. I mean where I work everyone has a company laptop, and everyone is going
    • Not a good defense (Score:5, Informative)

      by Junta (36770) on Saturday October 21, 2006 @07:26PM (#16532053)
      All the fingerprint and user authentication in the world is a poor defense against someone ripping out the drive, which is easy if the laptop is stolen. That's why it is generally a larger issue on laptops than desktops. Desktops tied to your desk at work have whatever physical security the company has invested in protecting it, leaving it open only to the possiblity of remote attackers (well, within reason, the physical security can be bypassed, but assume a perfect company for discussion). The whole threat of a laptop is physical security breaches, otherwise the discussion wouldn't be laptop-centered. As to not putting confidential stuff on laptops, it is a good idea, but that is a policy rooted in trusting the user to always be vigilant about the confidentiality of the data set they are working, trusting their judgment, and expecting them not to take convenient short cuts at 5pm on a Friday so they can get it done on the weekend without staying late or looking bad on Monday. I use full disk encryption so I don't have to even think about it. I'm fairly sure I have nothing on my laptop remotely of interest to anyone, but I never have to think too hard about it.
  • by Fyz (581804) on Saturday October 21, 2006 @06:44PM (#16531721)
    Though I'm not very crypto-savvy, there's one thing that I've learned from hard experience about mobile devices and hard drives: they have a very short life span.

    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?
  • by cos(x) (677938) on Saturday October 21, 2006 @06:45PM (#16531733)
    Granted, I am not encrypting the *whole* thing, but /home should take care of most of the sensitive data. I am using GBDE on FreeBSD which is strong enough for the weakest point to be the password. Yes, if I do lose the password, the data is unrecoverable. However, a simple way around this problem is to regularly back up the entire partition. The backup should be unencrypted, of course, so that if I lose my password, I can still get back my data. With GBDE, this is easily done. The encrypted data on my machine resides in /dev/da0s1g and after I have typed in the password, the decrypted content appears under /dev/da0s1g.bde - all I need to do is dump that partition. Certainly, encrypting all other partitions would increase security, but I am feeling pretty safe as it is. Also, FreeBSD is probably obscure enough for most laptop thieves by itself :). One last thing to note is that because the file system on *NIX is well structured, there actually should not be any sensitive data anywhere in /usr anyway - just application binaries and source.
    • increase security, but I am feeling pretty safe as it is. Also, FreeBSD is probably obscure enough for most laptop thieves by itself :).

      Obscure. Nah ...

      FreeBSD/i386 ( (ttyv1)

      Then again, they may be right-clicking for some time ...

    • by croddy (659025) on Saturday October 21, 2006 @07:12PM (#16531953)
      It's also very important to encrypt your swap space -- just think of all the crypto keys, passwords, etc. that are stored in memory. It's much easier to be sure you've secured those if you know they're being swapped to a partition that's initialized with a new random key each time the system boots.

      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 is the user is LAZY. The help-desk, is agitated. And the higher up big-wigs get upset because productivity suffers.

    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)

    by Above (100351) on Saturday October 21, 2006 @06:49PM (#16531755)
    System Preferences -> Security. Click "turn on file vault". A few minutes later, you're done.

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

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

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

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

      FileVault rocks. OSX even includes secure virtual memory (pretty big performance hit, but a real good idea on multi-user machines).

    • You can only reclaim space from deleted files in file vault by logging out of the user account. This can be quite annoying.
  • 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.

    Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues.

    How would that work? I thought the key in the hardware token was constantly cha

  • This makes no sense (Score:5, Informative)

    by sheldon (2322) on Saturday October 21, 2006 @06:50PM (#16531765)
    What do you mean "Why don't we use full disk encryption?"

    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)

      by 4alexnyc (826658)
      Ditto for my company - very large company in FS, all 50,000 laptops are encrypted... Took a while to get senior management on board (come on, all of us in IT knew this was something that should have been done for a while) but once the decision was made, it was implemented quickly and properly (i.e.- force load on initial login).
  • by Anonymous Coward
    Posting anon for obvious reasons, but those of you banking at JPMC may rest assured that we already do use full disk encryption on laptops. Wouldn't be at all surprised to learn other banks do.
  • by DragonWriter (970822) on Saturday October 21, 2006 @06:58PM (#16531841)
    Full Disk Encryption gives you the access overhead that comes with encryption/decryption for every access to the hard disk. Why not just encrypt the sensitive data if you want to avoid leaks of the sensitive data?

    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.

    • by TubeSteak (669689) on Saturday October 21, 2006 @07:14PM (#16531975) Journal
      Why not just encrypt the sensitive data if you want to avoid leaks of the sensitive data?
      Because it is not that simple.

      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)

      by croddy (659025)
      You have to encrypt everything; otherwise they know which data is sensitive. Make them work for it!
  • by zerofoo (262795) on Saturday October 21, 2006 @07:07PM (#16531917)
    keep it off of portable devices. We grappled with this problem at the bank where I used to work. We opted for Citrix/Remote Desktop inside a VPN tunnel secured via RSA token and accessed via Verizon wireless broadband cards. This kept all non-public information off of laptops, securely stored in our datacenter.

  • by Angst Badger (8636) on Saturday October 21, 2006 @07:08PM (#16531919)
    I count on the contents of my thumb drive being easily readable to ensure its safe return if I lose it. I put everything in a directory tree that looks like this:
    /al_qaeda_c ontacts
    That way, if I accidentally drop it somewhere, odds are that it will be returned to me by those nice boys at the FBI.
  • by goldcd (587052)
    because I trash laptops and have to recover data more often than I need to worry about it having been stolen.
    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)

    by omnirealm (244599) on Saturday October 21, 2006 @07:11PM (#16531939) Homepage
    A new addition to the 2.6.19 Linux kernel, eCryptfs, addresses many of these problems: []

    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 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: start.html []

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

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

    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: []

    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)

      by Junta (36770) on Saturday October 21, 2006 @08:35PM (#16532505)
      Based on the readme, it looks like encfs (which uses fuse and openssl). It might obscure more detail (i.e. with encfs you know how many files and directories there are, and their timestamps). How does it differ from encfs (

      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 /boot (which I do). This has benefit for protecting against physical threats and people trying to reboot your system using a live cd or other such attacks. However, the key is always available to the kernel and all the data is visible, so a remote or local attack that acheives root privileges means all the data is exposed since a very coarse grained attack was used. On the bright side, it is also appropriate as a codified standard because users can't generally be trusted to correctly perform risk assessments on every save or understand all the temporary places they may save to, and it's the only way to protect swap patitions. I use dm-crypt with LUKS partitions for / and swap on my laptop, with a small /boot for the kernel and luks-enabled initrd.

      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. /tmp is always exposed and swap is still dm-crypt protected on that system.
      • Re: (Score:3, Informative)

        by omnirealm (244599)
        How does it differ from encfs (

        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)

      by man_of_mr_e (217855)
      What eCryptfs does not solve is the issue of system integrity, and secure temporary storage. What good is it to encrypt your files if they can just scan your swap partition looking for data? or /tmp? or, as someone else said, they trojan other files on your system?
      • Re: (Score:3, Informative)

        by omnirealm (244599)
        What eCryptfs does not solve is the issue of system integrity, and secure temporary storage.

        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).
  • I thought that encrypting just the home directory was a great security idea on my group's laptops. It is very effective in limiting liability against laptop theft.
    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)

    by evilviper (135110) on Saturday October 21, 2006 @07:14PM (#16531969) Journal
    This is slightly off the topic, but in the same vein...

    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.
  • The first time I used full disk encryption was KoH on my 386/25 laptop that ran G2 & G3 to clone those pesky flip and brick Motorola's. As for modern day FDE, the best implementation that I have seen was a friend of mine's laptop who worked for Morgan Stanley in their International Banking division. The OS was Windows XP, the hardware was a ThinkPad and the authentication mechanism was a PC-Card. Without the card, the laptop wouldn't even boot.
  • Stupid idea. (Score:5, Interesting)

    by kosmosik (654958) <konrad.kosmosik@net> on Saturday October 21, 2006 @07:17PM (#16531991) Homepage
    To encrypt entire disk it is a stupid idea. Few points:

    - 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.
  • by jahurska (883728) on Saturday October 21, 2006 @07:32PM (#16532093)
    I work as a SW consultant for the mobile sector and all laptops in our firm have encrypted hard drives. The system is so that username and password is asked right when the laptop is booted kinda like bios password and after windows is loaded it automatically logins you to windows with those credentials. It's easy to use, no need to remember any additional passwords and also added benefit is that the administrators can login into it with their credentials if a user forgets his password.

    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)

    by rickb928 (945187) on Saturday October 21, 2006 @07:47PM (#16532179) Homepage Journal
    ...for a 7 week gig at a semiconductor maker. IBM (yeah, now Lenovo) Thinkpad, and I had to enter a password at boot. No sweat, they asked me to give the password to the tech who received the equipment when I turned it in, but it could have been reformatted since I kept nothing on the local drive worth saving.

    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.
  • by Simon Garlick (104721) on Saturday October 21, 2006 @07:49PM (#16532205) d=749efb5b59855bac7e1a06eda016e4a9 []

    If you need a reason why people aren't encrypting their disks, visit the PGP Whole Disk Encryption forum and take your pick.
  • context (Score:5, Insightful)

    by pruss (246395) on Saturday October 21, 2006 @08:03PM (#16532279) Homepage
    In a number of contexts, loss of data is a more serious concern than loss of confidentiality. For the vast majority of self-generated data on my hard drive, I would be seriously inconvenienced by the loss of the data, but would not at all mind the data becoming public. For a significantly smaller amount of data, I would seriously mind the data becoming public, but I would more mind losing the data. Only a very small fraction of data on my computer is such that I would mind the data becoming public more than I would losing it.

    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.
  • .. and that's "What happens if and when something goes wrong with the encryption solution and you lose all your data"?

    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)

    by chill (34294) on Saturday October 21, 2006 @08:15PM (#16532357) Journal
    There is absolutely no need to encrypt the main hard drive. What? You afraid of someone stealing C:\WINNT?

    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:\.

  • won't matter... (Score:3, Interesting)

    by tomstdenis (446163) <tomstdenis AT gmail DOT com> on Saturday October 21, 2006 @09:53PM (#16532909) Homepage
    AES-256 + disk encryption + password="mittens" == moot.

    How about we train people who hold sensitive data on how to manage it?

    There's a shocking cool idea...

  • by nologin (256407) on Sunday October 22, 2006 @01:16AM (#16533596) Homepage
    That's the question that needs to be answered... A security-minded entity (corporate, government, personal) has to ask that question and seriously look at the risk vs. reward of storing the data on a portable device. If the entity in question doesn't look at this perspective of the issue, they ultimately don't care about security in general or enforcing a data storage policy in particular.

    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)

    by Tom (822) on Sunday October 22, 2006 @05:24AM (#16534738) Homepage Journal
    We don't encrypt the entire disk because it's total utter nonsense (except if you try to sell a product).

    Most of the data on most machines is neither secret nor special - it's the OS and applications binaries, libraries, graphics, etc.

    Encrypting /home (or /Users for us Mac-heads) is sufficient for most machines. So look into system settings and Security and you'll find File Vault. Activate, done. No need to buy some snakeoil some idiot is trying to sell (*).

    (*) 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.
  • by AmiMoJo (196126) <mojo@world3. n e t> on Sunday October 22, 2006 @07:11AM (#16535312) Homepage
    For years now, it has been possible to get hardware encryption for ATA drives that operates at above maximum ATA spec speed, i.e. it is totally transparent and does not cause any reduction in performance.

    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... []

"An open mind has but one disadvantage: it collects dirt." -- a saying at RPI