Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

What's Missing From File / Disk Encryption? 177

Posted by Cliff from the features-wanted dept.
lockDrive asks: "Every month, we read a news about personal information leak. Most of the time, either a laptop or a hard disk that contains sensitive information is stolen from a government or corporate office, and the data are not encrypted. Recently, Department of Veterans Affairs had lost a laptop which contained confidential information for 26.5 million veterans. The data were not encrypted. There are many products that provide a solution to such a problem. Microsoft Encrypting File System (EFS), which comes with Windows 2000 and later, encrypts data in a file system and seems to have a decent key recovery system in Windows 2003 Server CA. Products like SecureDoc and DriveCrypt encrypt an entire disk. I have tried some of them and they are not that difficult to use. What is holding people who handle sensitive information (government, health-care, insurance ...) back from encrypting their data? Are the products still too hard to use? Are they concerned about performance loss? Are they not convinced with the security gain? Are they just not adopting the technology quickly? Is there anything missing in the technology?"
This discussion has been archived. No new comments can be posted.

What's Missing From File / Disk Encryption? More

What's Missing From File / Disk Encryption?

Comments Filter:

  • Time (Score:3, Interesting)

    by suso ( 153703 ) * on Thursday June 01, 2006 @09:44PM (#15450494) Journal
    Time is what is needed. :-D

  • encryption is a speed bump. (Score:4, Insightful)

    by ecalkin ( 468811 ) on Thursday June 01, 2006 @09:47PM (#15450506)
    it will slow people down. maybe long enough to recover the data or somehow make it less useful (change ids, passwords, etc). even good encryption will eventually fail. the best you can do is to make it difficult.

        on a positive note, someone suddenly looking for breaking tools might catch some attention. on a negative note, something encrypted tends to be a big red flag that says 'look at me, i was important enough to protect'.

        and one final thought: it you look at the care and attention that people pay to to security, it would not surprise me if most encrypted systems would be compromised by user stupidity (social engineering).

    eric

    • Exactly how do you propose to get at a disk encrypted with a 256 bit AES key? or a 448 Bit BlowFish key?

      -sirket

    • Re:encryption is a speed bump. (Score:4, Insightful)

      by drsmithy ( 35869 ) <drsmithy@nOSPAm.gmail.com> on Thursday June 01, 2006 @10:44PM (#15450796)
      it will slow people down. maybe long enough to recover the data or somehow make it less useful (change ids, passwords, etc). even good encryption will eventually fail. the best you can do is to make it difficult.

      Note that when "eventually" is a timeframe measured in tens to hundreds of years, that's probably good enough for just about anyone.

      • Just the act of counting from 1 to 2^256 at a rate of 1 trillion keys per second would take approximately 2^191 years (3 x 10^57).

        That's 3,000,000,000,000,000,000,000,000,000,000,000,000, 000,000,000,000,000,000,000 years.

        This is WAY longer than the universe has been in existence and probably longer than it will continue to exist in the future. That's just counting the keys. Actually testing them would probably slow your key rate down significantly.

        The math as I see it:

        1 trillion keys per second = 2^40

        2^40
      • However, correct me if I'm wrong, but these numbers are probabilities.

        It could be that your first guess would work. It is unlikely, but possible.

        It is just as unlikely that it will be your last guess that works.
    • it will slow people down. maybe long enough to recover the data or somehow make it less useful (change ids, passwords, etc). even good encryption will eventually fail. the best you can do is to make it difficult.

      "slow people down- _MAYBE_ long enough?" If 2^191 years isn't long enough to change your passwords then the only possible reason is that you are dead.

      Just the act of counting from 1 to 2^256 at a rate of 1 trillion keys per second would take approximately 2^191 years (3 x 10^57).

      That's 3,000,000,000
    • Ok, I know you've seen movies and read books. But the fact is, crypto today mostly isn't about compsci/math geniuses who, given enough caffeine and a week without sleep, will stumble on some inspiration that'll crack the code wide open.

      Crypto today is about brute force. And it's about how you CANNOT brute force a crypto key with current hardware. And this isn't about Moore's law, we need fundamentally different hardware to be able to crack current crypto techinques.

      This is why the only reliable way to br

  • That reminds me- (Score:3, Interesting)

    by sirket ( 60694 ) on Thursday June 01, 2006 @09:47PM (#15450507)
    I've been looking for an encrypted hard drive controller- something that looks to the OS like a normal disk but every single byte written to the disk is encrypted. The moment the power is pulled the key is lost and needs to re-entered when the system reboots. It would look like a disk error but when the "Non-system or disk error" message comes up you enter the key and the system boots normally.

    I would prefer there not be any chance of the OS leaving around un-encrypted information on the swap partition or hacing a back door or any other stupidity. I've seen encrypted controllers but only with 40 bit keys. I'd love to see something with an AES 256 bit key. If nothing is out there I may just have to put together something using an FPGA.

    -sirket
    • All my machines now use encrypted swap files. If you use Gentoo, it's as easy as "emerge cryptsetup" and un-commenting two lines in a configuration file.
      • well, that and /etc/fstab and overwriting the original partion with random bits to destroy the old data... but it's still easy
      • You can do the same thing with OpenBSD (which I run). I guess I would perfer there to be absolutely no way to write to the disk without it being encrypted. I would also prefer the speed advantadges of hardware encryption.

    • -truecrypt? (Score:3, Interesting)

      by acomj ( 20611 )
      We had someone at work talk about this...

      http://www.truecrypt.org/ [truecrypt.org]

      Its not a HW controler, but a mount the file system encrypted. It seems like a well thought idea anyway. And available for Linux.
      • The problem is that some part of the disk is unencrypted - otherwise you would not be able to boot it. If someone gets hold of the disk they will see the unencrypted partition and realize that there is an encrypted partition (because of the partition table / fstab / etc.). With a hardware controller the data on the disk is entirely gibberish. If someone gets hold of just the disk there is nothing sensible on it. If they get it with the controller it shows a non-system or disk error. Either way it reveals no

        • Re:-truecrypt? (Score:4, Informative)

          by Merlynnus ( 209292 ) on Friday June 02, 2006 @01:27AM (#15451582)
          Nonsense. I use Truecrypt, and have encrypted a whole drive. *Nothing* on it is unencrypted. It has no partition table. Any sort of analysis of it would show that it is complete indistinguishible from random noise. Taken out of the workstation that it currently resides in, it would be completely and utterly secure. And, unintelligible. Granted, it's not the boot drive, but so what?

          I also wonder about "...and realize that there is an encrypted partion...". Again, so what? Unless you've chosen an insecure passphrase, or give up the passphrase through some manner of coersion with the strong encryption algorithms, it doesn't matter if someone realizes there might be more to the noise or not. And, if you're really worried about it, Truecrypt allows you to create truely hidden encrypted areas.

          I suggest reading the fine manual that comes with Truecrypt and studying the bit about plausible deniability. And the bit about encrypting whole devices. *Then* come back and bring a informed opinion.

          The fact of the matter is that the technical problems have been mostly addressed. The problem is that the wetware doesn't follow reasonable data security policies.

          • Exactly how the fuck does your god damned BIOS boot your OS if _EVERYTHING_ is encrypted? Would you like to explain that to us laymen? Oh- gee- wait- you said it's not your boot drive. Great- So when Windows writes a fucking temp file to the unencrypted boot disk TrueCrypt doesn't fucking help me. I don't want a single bit to be written to the disk without it being encrypted. I don't even want it to be _POSSIBLE_ to write something unencrypted to the disk- even if someone does a write to the raw disk.

            I sugg

            • Re:-truecrypt? (Score:3, Interesting)

              by Merlynnus ( 209292 )
              Dude: Coffee. Or something. That much stress isn't good for you. You use Truecrypt on your laptop? OOooooh. I bow down to your obvious omniscience.

              Hardware encryption? Hah! Ask the Xbox devs how well that worked for them. Given access to the hardware, it will be broken. But .... you'll have designed it. Oh, I'm sorry, I'm sure that will solve all the hardware encryption problems.

              But mocking aside, check this out: Can I relocate the Windows temp directory somewhere else? Yes. Can I change the loc
              • Uh, you better turn off swap in your host system and also make sure the "suspend vm" never suspends to plaintext.

                Otherwise parts of your virtual machine could end up on the disk in plaintext- e.g. you run out of memory it gets swapped (does happen sometimes).

          • Nonsense. I use Truecrypt, and have encrypted a whole drive. *Nothing* on it is unencrypted. It has no partition table. Any sort of analysis of it would show that it is complete indistinguishible from random noise. Taken out of the workstation that it currently resides in, it would be completely and utterly secure. And, unintelligible. Granted, it's not the boot drive, but so what?

            The really great thing about TrueCrypt, as I see it, is plausible deniability. This means that you can "nest" volumes and o

        • Re:-truecrypt? (Score:3, Insightful)

          by MacroRex ( 548024 )

          I don't think this level of deniability can be done.

          Your system needs to know it should ask for a password before it can access the disk. How can this be done so that a third party cannot deduce from the hardware that the disk contains encrypted information? We must assume that the third party has access to all hardware including any special disk controllers, custom FPGA solutions or BIOSes. IMO this means that a sufficiently smart third party can always conclude that the system contains encrypted data,

          • Hence the random "Non-system or disk error." They would think the disk had failed. The beauty of building this myself in hardware is that no one else would have a similar system.

        • Re:-truecrypt? (Score:3, Informative)

          by peacefinder ( 469349 ) *
          Truecrypt has a clever dodge for this. They offer the ability to make a hidden encrypted volume. They do this by making an encrypted volume, and filling its blank space with random data. Yet inside of that random-filled blank space is another truecrypt container, which holds deniable data. If you don't know the key, you never see anything other than random padding in that blank space. See their page on it here. [truecrypt.org]

          Integrity of the inner volume seems quite fragile, due to the possibility of it being overwritten
          • Integrity of the inner volume seems quite fragile, due to the possibility of it being overwritten through the outer volume, but aside from that it seems like a good plan.

            This could be a plus. If you were ever foricbly made release your key to the outer volume then you could keep "secretfiles.tar" sitting around so that a less skilled attacker would untar it and in the process destroy the inner volume.
            • My first impression was that this is very clever. But the more I think about it, the more I think it probably won't have much protective benefit. The sorts of opposing forces one would need this level of deniability against can probably be counted on to do a complete clone of the drive and work only on a backup copy.

              Of course, by bias is towards preservation of data. The idea of deliberately destroying valuable data gives me the willies. :-)
      • FYI.

        TrueCrypt was recently covered & promoted by Steve Gibson,
        author of SpinRite, in his Security-Now! podcast (no. 41).

        'looks good & fast; is it? :-/

        TIA
    • 1) Encrypt your swap. Not hard especially on Linux. If you must run an OS that can't encrypt its swap, virtualise it. Windows on VMWare on Linux, or whatever.

      2) Don't trust hardware crypto. You didn't write it, can't read it. The NSA probably pwns the keys. Do crypto in software with peer-reviewed open source.
      • If you can't trust hardware, you can't trust anything.

        Think of it this way -- do you regularly dissemble your keyboard and check for keyloggers embedded in it by the manufacturer? Could you tell the difference if one was part of its controller anyway? What about your motherboard?

        And, even then, who built the chip fab? How do you know there isn't someone there changing your design before it actually gets to the silicon? And changing the visual on whatever microscope you're using?

        For that matter, how do y
        • > At a certain point, you just have to trust something.

          So why not make that "something" peer reviewed open source software, rather than some black piece of plastic inside your machine? Sure, the CPU could be specifically looking for your sooper seekret data, but that's not really likely (because it's too hard).

          Crypto is all about mitigating risk, and using software that you can trust is helpful for acheiving that goal.

    • Here's an idea: (Score:4, Informative)

      by Ayanami Rei ( 621112 ) * <rayanami AT gmail DOT com> on Friday June 02, 2006 @11:10AM (#15454197) Journal
      Take a simple linux install disk that uses initrd of your choice and comes with cryptoloop.
      Modify the initrd so it asks for a password before setting up the "real" root device on your harddrive.
      Burn the install CD with the modified initrd. Install linux using this disk (so it installs onto the now-encrypted hard drive)
      In order to use the system, you'll have to insert the install CD and use it as a boot CD everytime. But in this fashion no un-encrypted data is on any of your hard drives. To remove evidence that you can even access it, remove the CD when you're done using the computer, and store it in an inconspicous place.

      If you prefer using windows, deal with linux to the point you can install QEMU or VMWare. Install Windows normally in the virtual environment and it is encrypted as well (including the swap file!).

  • data loss (Score:3, Insightful)

    by r00t ( 33219 ) on Thursday June 01, 2006 @09:51PM (#15450531) Journal
    Can you stick the drive in any PC running the same OS, supply your password, and get the data? If not, there's one less step before you get stuck trying to read crufty old backup tapes/CDs/etc.
    • Oh, recovery via a DIFFERENT operating system is also desirable. Many times the Linux NTFS driver will work even when the Microsoft one gives up. With FAT you could try MacOS even.

      You're screwed if you use an obscure crypto format.
    • How about corrupted data recovery? Say I have a document, and 15 bytes are damaged and unrecoverable. No problem, I still want it because it's important. If it's unencrypted, that is unproblematic. Whatever those 15 bytes were is damaged and I'll have to fix, the rest of it is there. What about the encryption? Can it handle decrypting partially damaged files, or will it fail?
      • Depends, of course, on the format -- but most of the sane systems that I've seen encrypt blocks independently (where a block is something from, say, 512 to 4096 bytes), with an IV that's dependent on the block number, and possibly the filename (depending on the level that the encryption is working at). So given a small error, you would likely lose one or two blocks -- not an entire file or directory or filesystem.
      • If you're worried about your files being corrupted, then you should probably be backing up your data. It is not the encryption system's job to worry about whether or not encrypted data is recoverable. However, I'm sure that they could build in some parity that would allow the data to be decrypted even if some bytes were damaged. This redundancy of data also might make the encryption easier to break. The simple answer is, if you want to make sure you're files aren't lost, then keep backups. Because when

  • The real cause... (Score:4, Insightful)

    by WidescreenFreak ( 830043 ) on Thursday June 01, 2006 @09:51PM (#15450536) Homepage Journal
    I think you missed the real cause -- the IWNHTM Syndrome.

    It Will NeverHappen To Me

  • Ignorance (Score:5, Interesting)

    by Merlynnus ( 209292 ) on Thursday June 01, 2006 @09:52PM (#15450543)
    Clearly the problem is ignorance. And bad habits. And bad security policies.

    It's not a technological problem -- everyone in Windows & Linux land should be using Truecrypt [truecrypt.org] or something similar and being smart about how they handle data. Rather it's a social problem.

  • lack of proper policies (Score:4, Interesting)

    by artifex2004 ( 766107 ) on Thursday June 01, 2006 @09:53PM (#15450546) Journal
    The biggest flaw in these schemes is always the glaringly obvious: nobody bothered to turn them on.
    Without written security policies, nobody knows what they should/can/must not do, and even if they do, they follow the rules inconsistently.

    Take a look at Cisco's SAFE [cisco.com], for example. It explicitly says

    This document presumes that you already have a security policy in place. Cisco does not recommend deploying security technologies without an associated policy. For further information about security policies and their use, consult the SANS Security Policy Project at:
    http://www.cisco.com/go/safe [cisco.com]


    If you don't know what you have, who gets to access it, and when, what good is a bunch of hardware and software? You might as well hand all your workers CDs of your databases and cross your fingers. Which, possibly, actually happens in some of these cases. Sadly, this sort of stuff is Day 1 material for CCNA and MCSE and other certifications these days, so it pretty much looks like whoever is running the show in these places can't follow or doesn't know standard industry practices. That's gross negligence, IMO, and nothing to do with any sort of technical failings.
  • One problem with encrypting information is that in an environment where multiple users need to access the data, you lose central control.

    For example, Department A installs an encrypted file-system for a CRM database; Department B, who work with a portion of that data, allow for offline backups onto their users unprotected laptops, inevitably, one of the laptops is lost or stolen, and someone finds unencrypted data all over it.

    The only possible solution to this is a really pervasive security policy th

  • How about a distro w/ initial install support (Score:5, Interesting)

    by Tiamat ( 25392 ) on Thursday June 01, 2006 @10:29PM (#15450720)
    I would love to a see a distro, like ubunto, that would ask me if I wanted to create a small boot parition, and a larger *encrypted* primary parition, which would then install to the encrypted partiton, and finally give me the chance to burn a CD from which to boot (or USB stick if my system supported that, etc.). Then, on boot (either from the HD small boot part, or a read-only CD), I'd enter my password to access the root partition. As it stands, getting this done requires some expertise, too much time for most of us, and lot manipulating of files, partitions, etc.. Make it easy!

  • What's missing? (Score:3, Insightful)

    by Kalzus ( 86795 ) on Thursday June 01, 2006 @10:40PM (#15450766)
    Common sense and rigour.

    I don't care if your algorithm never exposes a weakness for ten thousand years and your messages are supposedly secret for ten billion. If you keep throwing your scratchpad in the wastebasket and leaving it there, for example, then I'll probably figure out your plaintext.
  • ... every one of our hard drives is encrypted. That's for over 150,000 employees. Every one, as far as I know. Could be that they missed one somewhere.

    There's still the problem with bad employees copying things off on CDs, floppies, emailing sensitive stuff out, but as far as theft of PCs/laptops, we're covered.

    • I worked for a place where the policy was to encrypt sensitive documents before emailing them out. The practice (at least with one HR person who remains clueless) was to helpfully include the password in the same email as the encypted document.
  • For many years, offsite backups have been all about preservation of data integrity, not data privacy. After all, backups are not what's important... restores are what's important. If your offsite backup is encrypted and no one has the key after a disaster, your tape may as well be blank. Now we need to make sure offsite backups preserve privacy as well as integrity, and those are somewhat contradictory goals.

    So encrypting offsite backups is a big step, and unless it's done right it can be seriously counterp
  • I'd just like to be able to store 'personal' or 'private' information on a 1GB encrypted flash drive.

    One of the major reasons that has stopped me from using encryption, however, is the lack of compadibility for diffrent operating systems.

    If I encrypt the drive using AES-256 on linux, I'm unable to read it on Windows. If I encrypt it with one of the Windows tools, I'm unable to read it on linux.

    So I'm stuck between only being able to read my information at home on my linux machine, or only on public/windows
    • Truecrypt does what you want.

      http://truecrypt.sf.net/ [sf.net]
    • You only mention windows and Linux. Truecrypt [truecrypt.org] supports those two operating systems. Future support for OSX is planned.
    • I concur. But there's also the issue of reliability. People here keep naming Truecrypt and I've tried it out, but in the FAQ they specify that if some bytes are lost, then you may loose the entire encrypted partition. Am I the only one to find this totally unacceptable ?!? Losing one file to a disk crash due to a power failure is one thing, losing the entire partition is NOT. Wake me where there's some built in redundancy, and no, don't tell me to put it on a RAID as it's 2 different problems.
      • Losing one file to a disk crash due to a power failure is one thing, losing the entire partition is NOT. Wake me where there's some built in redundancy, and no, don't tell me to put it on a RAID as it's 2 different problems.

        As I have said elsewhere in this thread, there's a natural conflict between pivacy and integrity of data. Any redundancy built-in to the encrypted contaner would weaken privacy by making cryptanalysis somewhat easier. (Possibly much easier.) If you need to bother with encryption in the f
        • OK, I understand the issue of redundancy causing lowering the security, but at the same time I think it should be possible to have an encryption designed in a way that a wrong byte corrupts a single file within the container and not the entire container... This happens often enough.
          • "... it should be possible to have an encryption designed in a way that a wrong byte corrupts a single file within the container and not the entire container..."

            Of course. Just encrypt each file separately. Obviously that's not very convenient, but if that's what you want an encrypted container is probably not the right solution for you.

            Maybe you need to use a lot of small containers that each hold a few files, so the damage caused by container loss is never excessive. (For some value of excessive.) If you
    • I'd just like to be able to store 'personal' or 'private' information on a 1GB encrypted flash drive.

      I'm assuming that you're talking about things like passwords, bank accounts, or other textual information.

      My solution is low-tech. I have a GPG/PGP key with a decent length passphrase (and a 2-year expiration date). The private keys and the passphrase get kept in the safe-deposit box downtown as a backup. (Key management is generally the "hard" part and usually where things get screwed up.)

      For ever
    • So I'm stuck between only being able to read my information at home on my linux machine, or only on public/windows computers.

      If you're decrypting your data at public computers, the whole encryption thing is essentially pointless. You don't know what's on that computer that could be snooping your passphrase and copying plaintext from ram.

  • Key Management (Score:2, Insightful)

    by gadzook33 ( 740455 )
    Any organization handling truly sensitive data doesn't have the luxury of using third party key management. As soon as you have to manage keys, the difficulty of encrypting data goes way up. For these applications, a six letter password isn't going to cut it. Security has little to nothing to do with encrypting data. You can just as easily lock the data in a safe. If you encrypt the data and lock the key in a safe, what's the difference? There is none. People often equate encrypted with secure and th
    • > As soon as you have to manage keys, the difficulty of encrypting data goes way up. For these applications, a six letter password isn't going to cut it.

      So keep your private key on a smart card (I use an OpenPGP card from Kernel Concepts). All the encryption/decryption takes place on the card, which requires a passphrase to use. If you type the passphrase wrong a certain number of times, the card melts itself, destroying the key.

      This gives you all the convenience of a short password, with all the secur
  • I used to work for a therapist practice where all the therapists would do their notes on their laptop. Unfortunately, that mean HIPAA-regulated client data was floating all around on their laptops. Should one of them get stolen, there goes privacy information. The problem is, therapists, and barely computer-literate people in general, do not have the patience nor the technical inclination to encrypt their personal laptops. These are usually their personal computers as well, so we say that it's up to them to
  • I remember fooling around with encrypted partitions at some point, and I remember having a Windows glitch cause all my data to be lost - unlike when a few bad sectors could be manually worked around with various disk tools, if an encrypted file is "damaged", the whole thing is smoke - or at least it was back in 1998.

    So, I think just the paranoia of having files being much more "destructible" has kept me from encrypting my hard drive on my laptop.

    On the other hand, now I use OS X and Linux, and have multiple
    • I have been using an encrypted RAID5 drive in my machine for months. I have had a few disc failures and recovery is easy enough - I just remove the disc from the raid, and the new one back, and it fixes itself. Encrypting everything is easier than encrypting only parts, because there's no granularity at present to ensure you don't accidentally copy or move "safe" data to "tainted" areas - ewncrypting everything ensures there's little chance for accidents.

      Making the disks encrypted is even easier than making
  • I know I'm far from the norm here, but I don't use full disk encryption -- despite being a security-industry paranoid -- because it's simply unavailable to me.

    Because I use a Mac. As do at least half of my laptop-wielding coworkers.

    Once a stable solution exists, I will be all over it, but at this rate I'll likely have to write it myself.
  • The "problem" with encryption is not that it takes a few extra clicks, a little extra training and a more effort to work with third parties. Though, those are issues. To me, the real problem is that we're lazy and there is no benefit... at least until something bad happens.

    I've recently been part of a outsourced payroll provider transition. As the IT guy for the customer end, I've been telling our folks to put a password on sensitive Excel* files (full of SIN's and other stuff like that) that get emai
    • We use a product called HandyBits EasyCrypto to send sensitive information over email. The nice thing about it is that it can create self-extracting .exe... so you just make your .exe, rename it to .000 (so email servers won't choke on it or delete it), call up the party you're emailing and tell them the password and how to rename the file back to .exe. I haven't come across anybody yet who isn't computer literate enough to decrypt one of these.
  • EFS is VERY buggy and limited, according to Microsoft technical support representatives.
  • The problem with disk encryption as it is implemented today is twofold:
    1. it doesn't scale - all the various products today can be used for small deployments and still be useable. However, try to scale it to a large enterprise with thousands of machines and you have an administration headache. Microsoft EFS has various flaws in it like this. For instance, if somehow a user's _local_ profile on the machine with the encrypted data is erased, all his data is gone or has to be recovered by the backup operator (

Slashdot Top Deals

Receiving a million dollars tax free will make you feel better than being flat broke and having a stomach ache. -- Dolph Sharp, "I'm O.K., You're Not So Hot"

Close