Slashdot Mirror

← Back to Stories (view on slashdot.org)

Full Disk Encryption - Xen, Windows and Linux?

Posted by Cliff on from the protecting-your-data-across-various-OSes dept.

Bofh To asks: "I'm in an industry that, more or less, requires full disk encryption, and to accomplish this, we use Pointsec on Windows. For the past 8 years, I've been running Linux on my work laptop, and this is the first time I'm running in a Windows only environment. I am interested in changing that, because I want to use Linux as my main platform, and only drop in to Windows when necessary (and use crossover if at all possible). I'm also interested in Xen, and would like to see if I can use that to virtualize Windows under Linux. My thought is that, as long as Pointsec is in dom0 and I use virtual disks for the Windows VM, I should be covered. The problem is that I'd also like a machine that is usable, as opposed to waiting endlessly as the virtual memory, virtual machine, pointsec, and xen all thrash around while I'm working on the machine. Has anyone used Pointsec for Linux, with Xen? "

49 comments

  1. Look at dm-crypt by Cheeziologist · · Score: 4, Informative

    I know you asked about people using pointsec with Linux, but have you considered using the device mapper to do hard disk encryption for you? On my laptop, I have the entire hd encrypted using aes and sha256, using the kernel's dm-crypt abilities and the cryptsetup program. To do this, you need to have a small partition to boot from that contains the kernel (and an initramfs if you don't build it into the kernel). From there you unencrypt the drive, pivot root, and continue booting. Additionally, if your intent is to run the virtual windows encrypted, you can use cryptsetup to manage the the device or files to keep the windows files on. There are many good tutorials on using dm-crypt, and can definitely tell you more than I can easily explain.

    1. Re:Look at dm-crypt by phrasebook · · Score: 2, Interesting

      How's the performance of dm-crypt for you?

      I use it on my swap and /home partitions on my laptop, but when doing heavy writing to the disk, the whole machine locks up for 1 or 2 seconds at a time - no mouse movement, no sound, no cursor - then it resumes. These freezes occur every 10 seconds or so as data gets flushed out to the disk.

      Normal reading/writing load is ok, but doing something like an rsync backup kills responsiveness.

      It seems to get a bit better if I renice kcryptd and kjournald. Any experience with this yourself?

    2. Re:Look at dm-crypt by rjforster · · Score: 4, Informative

      Not knowing the exact details of the requirement, but Pointsec is FULL disk encryption. This matters.

      To the original poster:
      I think this is one of those 'suck it and see' situations. Processors are getting faster all the time. Disks are getting faster too, especially solid state drives. So the trade offs between different performance areas are changing all the time. Eg today you might notice the crypto delays, tomorrow you might not because you essentially have a dedicated core doing disk crypto.

      Last year I ran tests with Pointsec for a different situation and it was pretty good with a flash drive. Not _quite_ as good as a FDE competitor but not far off. This wasn't on a fancy new laptop with decent dual core processor either. For these tests I got a free eval copy of Pointsec. They were nice, helpful guys when I spoke with them, perhaps you could get an eval copy too.

      Another alternative is a hardware solution such as Flagstone from Stonewood. Full hard drive speed and full OS compatibility.

    3. Re:Look at dm-crypt by Jah-Wren+Ryel · · Score: 2, Informative

      I use it on my swap and /home partitions on my laptop, but when doing heavy writing to the disk, the whole machine locks up for 1 or 2 seconds at a time - no mouse movement, no sound, no cursor - then it resumes. These freezes occur every 10 seconds or so as data gets flushed out to the disk.
      From the dm-crypt faq:
      Q: My system hangs for some time in regular intervals when writing to encrypted disks.
      A: You are probably using Linux 2.6.4. Du to the introduction of kthread pdflush is running at nice level -10, which means that the kernels treats dm-crypt writes as a real time task and doesn't allow scheduling.
      Solution: Switch to 2.6.5 or later or renice pdflush manually.

      --
      When information is power, privacy is freedom.
    4. Re:Look at dm-crypt by phrasebook · · Score: 1

      I only started using dm-crypt with 2.6.18 in Debian etch. But kcryptd and kjournald are -5 by default, so maybe renicing those is all there is to it. Weird thing is I've not seen many people mentioning the problem. I can only assume most don't experience it.

    5. Re:Look at dm-crypt by swillden · · Score: 4, Informative

      Not knowing the exact details of the requirement, but Pointsec is FULL disk encryption. This matters.

      As is the proposed dm-crypt configuration. In both cases you have a small unencrypted boot section containing no sensitive data and everything else is encrypted.

      The only difference from a security perspective is that you can't audit Pointsec.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    6. Re:Look at dm-crypt by rjforster · · Score: 1

      With Pointsec only the MBR plus a couple of other sectors are unencrypted. There is no small partition in plain text which is what I understand dm-crypt to be. Please correct me if I'm wrong.

    7. Re:Look at dm-crypt by mangu · · Score: 2, Informative

      This "plain text" partition isn't text at all, it's just a set of routines to load enough decryption software into the system to use the rest of the disk. There's no sensitive data there because it's all public software anyhow.

    8. Re:Look at dm-crypt by swillden · · Score: 2, Interesting

      With Pointsec only the MBR plus a couple of other sectors are unencrypted. There is no small partition in plain text which is what I understand dm-crypt to be. Please correct me if I'm wrong.

      You're correct, but the difference is irrelevant: it doesn't matter if it's a few KB or a few MB that is unencrypted, the key is that all of the functional system and its data is encrypted, including all swap.

      Actually, dm-crypt and Linux can do one thing that Pointsec, AFAIK, does not do, which is to take advantage of a TPM-enabled machine. Given a TPM, TPM-enabled BIOS, TPM-enabled GRUB and Linux kernel, you can bind a portion of the master decryption key to the boot state, ensuring that any attempt to modify the unencrypted portions of the data will simply render the system unbootable. I could have overlooked the TPM support in Pointsec, of course. Please correct me if I did.

      Not to mention the fact that for the really paranoid an OSS solution offers auditability that no closed-source solution can match.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    9. Re:Look at dm-crypt by Anonymous Coward · · Score: 0

      It seems to only be a problem on really, really large commits. When I first setup the machine I thought "hey let's play with this, I might be able to use it for work", and was moving about 200GB of data into the encrypted volume from an old drive, the system actually stalled to the point that X ended up thinking it had locked up and killed itself (pretty neat trick, that). (Bonus points for creating the volume on a md raid1 drive, taking even more processor time)

      Since then, I regularly write 500MB of data into that volume at a time without the mouse so much as twitching.

    10. Re:Look at dm-crypt by rjforster · · Score: 0, Redundant

      In cryptographic terms it is plain text.

    11. Re:Look at dm-crypt by rjforster · · Score: 1

      I would expect a few kB to be easier than a few MB to audit, otherwise your point is valid.

      As for the auditing, I would take closed source but CAPS (or similar) approved[1] over open source non-CAPS. Because it _has_ been audited as part of the approval process. Of course, at this level the rubber hose hack is the best way of getting to the data.

      I don't know about the TPM side of things.

      Cheers

      [1] By CAPS approved I'll take the 'commerical' version of a product certified for classified data use. In other words a realated product by the same company. I believe that in some cases the products are the same at the encryption level, but the differences are things like two factor auth for login and better quality key material.

    12. Re:Look at dm-crypt by Matthew+Bafford · · Score: 1

      In cryptographic terms it is plain text.


      Yes, but isn't it irrelevant plain text? What does it have to do with the encrypted data? It's just a compiled public algorithm, isn't it?

      Maybe I'm missing something.

      At some point something has to be plain text. You can't have everything encrypted without something being unencrypted and runnable (even if it's in a chip or in the boot sector).
    13. Re:Look at dm-crypt by Anonymous Coward · · Score: 0

      Excellent idea.

      I would suggest using dm-crypt (under ubuntu: sudo apt-get install cryptsetup then edit /etc/crypttab) using cipher=aes-cbc-essiv:sha256 - this uses AES-128-CBC with a encrypted salted sector-count IV hashed using SHA-256 (which should be good for a while barring an extension of the SHA-1 attack - we really have nothing firmly better to offer, other than maybe WHIRLPOOL, until after the NIST's Advanced Hashing Standard competition in a few years).

      This cipher mode is not practically subject to any known attack, including known-plaintext, or chosen-plaintext watermarking attacks (which would need to know the salt to be effective).

      This is, incidentally, stronger than TrueCrypt (LRW mode has a weakness if you put a copy of the key inside the container), and almost all of the proprietary volume encryptions, the best of which are only just as good - I'd strongly advise against using any proprietary solution which you can't audit.

  2. looking forward to replies on this one by Cybersonic · · Score: 2, Interesting

    I have not tried out Pointsec yet, but its a solution my company sells so I should learn it :) I certified myself in PGP, which unfortunately does not support full disk encryption on Linux, just Windows and soon OSX... It also does not support dual boot on Windows. (its a shim into ntloader - but after the actual boot loader the 'pgp' os which asks for the decryption key during boot is linux, so I KNOW they have linux expertise...)

    I kind of like the roll your own approach to the Linux full disk encryption scenario, but most large organizations balk at anything thats not a commercial solution

    --
    Cybie! aka Ralph Bonnell
    1. Re:looking forward to replies on this one by Paracelcus · · Score: 1

      I can tell you that Compusec's free security software does the job very well, you cannot use it with an MBR boot manager like GRUB or Lilo as it's loader resides in the MBR. http://www.ce-infosys.com/english/downloads/free_c ompusec/index.html

      As to virtualization, I use VMware to run Windows under Linux.

      --
      I killed da wabbit -Elmer Fudd
  3. It occurs to me... by Anonymous Coward · · Score: 0

    that if you're using this for business, and it's a piece of software that's fairly prolific within your organization, you might well be able to obtain a trail copy, to experiment with. At the very least registering so you had access to their resource pages would seem like to be something to be explored. Baring that, if you're married to this way of doing things, I would imagine a laptop with a hybrid HD would give you the performance boot to offset the losses from the "thrashing."

  4. Debian's new installer is spiffy by deftcoder · · Score: 4, Informative

    The latest version of Debian Stable, codenamed 'Etch', has the ability to set up a fully-encrypted system (except for /boot of course) right from the installer.

    It's amazingly simple to use, and great for laptops. (I'm running it on my dual-core laptop)

    Check it out: http://www.us.debian.org/CD/

    --
    Peace sells, but who's buying?
    1. Re:Debian's new installer is spiffy by Anonymous Coward · · Score: 0

      And of course decent Linux distributions have supported encryption in the setup program for several years.
      They spend their time on real work, rather than political fighting.

    2. Re:Debian's new installer is spiffy by kestasjk · · Score: 0

      Where does it get the key from? If it gets it from /boot then that's no good, and if it gets it from somewhere else but it is read by the kernel in /boot that's also no good because the kernel could be replaced.
      To have secure full disk encryption it has to be full disk encryption. The only real solution that doesn't involve crypto hardware is to carry /boot around with you on a CD.

      --
      // MD_Update(&m,buf,j);
    3. Re:Debian's new installer is spiffy by Anonymous Coward · · Score: 0

      How did this get modded insightful?
      You "key" is encrypted with a "password", which is not stored on the HD, and you can't boot the system without it.

    4. Re:Debian's new installer is spiffy by Anonymous Coward · · Score: 0

      If an adversary has physical access to the computer, he can install a keylogger onto the unencrypted /boot.

    5. Re:Debian's new installer is spiffy by kestasjk · · Score: 2, Interesting
      I thought I covered this when I said

      if it gets it from somewhere else but it is read by the kernel in /boot that's also no good because the kernel could be replaced. If you're protecting against theft having an unencrypted kernel read the password is fine. But if you're protecting against theft why both with full disk encryption; why not just encrypt specific files or use a virtual encrypted drive like TrueCrypt?

      The main reason for full disk encryption instead of alternatives is that it makes it impossible to modify any part of the operating system while the machine is offline; so you can have a system running in an insecure environment, and no-one can power it off and steal your hashes or change things around because everything on the disk is encrypted.

      Now if the machine can be powered off and the kernel can be modified it can be modified to save the password you entered, or simply rootkitted. If you're going to allow that why not just encrypt the specific files/directories you want to protect?

      If you keep the kernel separate (eg on a CD or thumbdrive that you keep with you), and you actually mean full disk encryption when you say full disk encryption, an attacker would have to modify the hardware in the machine. If it was a desktop machine they might add a keylogger, or if it was a server they might replace the BIOS, but it would have to be a more determined and experienced attacker than someone simply swapping out your HDD and modifying your kernel.
      --
      // MD_Update(&m,buf,j);
    6. Re:Debian's new installer is spiffy by Bishop · · Score: 1

      If an adversary can access the hardware then all bets are off. It does not matter if the kernel could be trojaned as the hardware could be just as easily trojaned with a physical key logger or similar. All (consumer) computer systems are susceptible to this attack. Even TPM systems.

      Carrying /boot on a removable device is easy. A tiny USB drive would be sufficient.

    7. Re:Debian's new installer is spiffy by Bishop · · Score: 1

      Full disk encryption and more targeted encryption such as file encryption solve two different pieces of the same problem. Full disk encryption (and all-but-boot encryption) protect against accidental exposures and residual data. Accidental exposures are from copying a file from an encrypted part of the drive to non encrypted part. And residual data are just the little bits of the plain text left from when the encrypted data was decrypted.

      Full disk encryption is convenient security. It is seamless and the performance cost is low.

    8. Re:Debian's new installer is spiffy by Anonymous Coward · · Score: 0

      What about Ubuntu?

  5. These questions always make me smile... by Anonymous Coward · · Score: 2, Insightful

    I always find these types of "Ask Slashdot" amusing. People ask about what security product to use in their enterprise, how it will work with Linux etc etc. All perfectly valid questions, but utterly pointless in a corporate context because guess what? It's the Information Security Policy (& CISO) which will dictate who can and can't authorise new encryption products, changes to production environments, installation of non-standard baseline software (and the list goes on & on). If the OP really does work in an industry where disk encryption is needed (I'm going to take a wild stab in the dark and say s/he's probably in healthcare where HIPPA is concerned, maybe within a financial environment for GLBA/SOX, but even then it's a complex minefield of compensating controls and regulations which don't actually *require* encryption), then s/he should be consulting the Information Security Officer for advice, not asking Slashdot and lining themselves up for being fired for breaching policy.

    1. Re:These questions always make me smile... by zCyl · · Score: 1

      What's wrong with a little public brainstorming? I don't know what business you work in where the IT guys come pre-programmed with all the answers.

    2. Re:These questions always make me smile... by hey! · · Score: 2, Insightful

      Probably a large one.

      If you're talking a thousand or so employees or less, you have about a dozen or so IT guys, so you head over to where they take lunch and you shoot the shit with them, and they can probably agree it would be cool to look at solution X on Linux.

      If you're talking an outfit with a thousand or so IT guys, then the answers are likely to be preprogrammed unless you can get to somebody high enough. Even then they're going to be more interested in keeping their headaches minimized than making a single user happy.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    3. Re:These questions always make me smile... by Anonymous Coward · · Score: 0

      Shiny things make you smile, you moron.

    4. Re:These questions always make me smile... by Anonymous Coward · · Score: 0

      Put down the Gentoo Linux HOWTO for a few minutes, take your dick out of the family cat and get a job with a company where security is taken seriously so you can see how things should be approached. Policies and proper authorization are a reality of controlled environments and modern business in an ever more regulated world, so yes, I'll keep on smiling. But thanks for trying!

    5. Re:These questions always make me smile... by jsellens · · Score: 1

      One "obvious" approach is to run the corporate windows, and then run linux under vmware running on windows.

    6. Re:These questions always make me smile... by Gothmolly · · Score: 1

      While the ISO may _set_ policy, he's usually the last person you want to actually ask about a technical solution to anything. "What does Gartner say?" is not a technology strategy.

      --
      I want to delete my account but Slashdot doesn't allow it.
  6. Compusec by CE-Infosys by mlts · · Score: 1

    I have seen a product for FDE for Linux, although its not open sourced at all. CE-Infosys's Compusec. The nice thing, its usable at no charge, so it may be worth a look on a non-production box. However, I don't know much about it, and have not tested it.

  7. gordon freeman approves... by User+956 · · Score: 4, Funny

    I'm also interested in Xen, and would like to see if I can use that to virtualize Windows under Linux.

    I'm not sure about that, but I'm sure Xen would be a great place to store backups to keep them from prying eyes. Who needs encryption when you have a low-gravity parallel dimension as a safe-deposit box?

    --
    The theory of relativity doesn't work right in Arkansas.
  8. Have you considered Pointsec on Linux? by swillden · · Score: 2, Informative

    They have a Linux version. Then your virtualized Windows image will also be encrypted. BTW, for virtualizing Windows, I'd recommend you get a copy of VMWare, rather than using Xen. The open source virtualization tools are coming along, but at this point in time VMWare will perform much better.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    1. Re:Have you considered Pointsec on Linux? by Mr2cents · · Score: 1

      It's always confusing when they say something like Pointsec for Linux 2.0. Is it (Pointsec for Linux) 2.0 or Pointsec for (Linux 2.0)? It always takes me a few seconds before my mind settles on the first ;).

      --
      "It's too bad that stupidity isn't painful." - Anton LaVey
    2. Re:Have you considered Pointsec on Linux? by bratgitarre · · Score: 1

      I know. The non-associativity of the English language is frequently a problem to me, a non-native speaker. It would help if people would use hyphenation to break disambiguities, e.g. instead of writing "infamous WMD evidence", write "infamous WMD-evidence" (I made this up on the spot, there are certainly better examples).

    3. Re:Have you considered Pointsec on Linux? by bill_mcgonigle · · Score: 1

      The Ask Slashdot probably changed after you posted your comment. As of now the question ends with, "Has anyone used Pointsec for Linux, with Xen?", so he's apparently considering it.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  9. to all the people advocating dm-crypt by Alex · · Score: 1

    It kind of sounds like the poster is stuck with pointsec, and bearing in mind his "industry" requires full disk encryption. I'd imagine he probably doesn't get much choice how its done.

    Alex

  10. Do you really need full hard disk encryption? by Futurepower(R) · · Score: 1

    If you can accept just having some partitions encrypted, TrueCrypt is wonderful.

  11. Known plaintext attack on encryption by Anonymous Coward · · Score: 3, Interesting

    Is full disk encryption a good idea? With the operating system within the encrypted partition, it gives a LARGE amount known plaintext to mount an
    attack.

    1. Re:Known plaintext attack on encryption by DanLake · · Score: 1

      There is not really any known plaintext on the disk. If The disk is 40GB, and the O/S is 1GB, how exactly will you know which bits of ciphertext correspond to which bits of operating system? You wouldn't. Any block of the O/S could be in any block of the disk, possibly fragmented, possibly random data in slack space at the ends of files, different package and kernel versions, etc.

      Known plaintext is when someone tells you here are is 64 bits of ciphertext (i.e. from DES), and then also gives you the 64 bits input to generate the ciphertext. This is the known plaintext. If I five you 128 bits of ciphertext and only 64 of those bits actually even correspond to the input plaintext, well then your job just got about 2^64 times harder.

    2. Re:Known plaintext attack on encryption by tigersha · · Score: 1

      If you take two machines, install both of them right after the other both disks will have the same sectors written, almost guaranteed. File system fragmentation only happens when you write to files and this never happens to the OS (only when you reinstall or upgrade). Having two machines installed right after the other happens a lot and the chances that the OS is on a predictable place if you only stole one laptop is very high. The parent poster is right.

      Is there any way of deliberately fragment a disk during or after install to increase the security?

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
  12. I wish FDE were more common with UNIXs by mlts · · Score: 1

    I sort of wish FDE were more common with UNIXs, where the only real point of attack would be the small amount of code in the MBR. With a TPM chip, even that is protected, so an attacker would have to physically disassemble the TPM chip and pull the key out of its physical RAM cells (which is pretty hard on even an unprotected chip, unless you are a large corp or government with an up to date chip fab.) /boot can be compromised fairly easily with a clever keylogger and some way to store the decryption key covertly until picked up by an attacker. Carrying a "trusted" USB stick or a CD with /boot on it is a kludge. There needs to be a solution out there which narrows the amount of code that can be attacked to the small amount of boot code that takes the password (or decrypts the main hard disk key on an eToken or similar) then passes control to the OS for the rest of the boot process. Preferably, this code can use a TPM chip if its present to ensure that that small attack surface isn't tampered with.

    This is not to say that FDE programs are easy to write. They need a number of major components to be written, and the components have to be rock solid. First, is the MBR code that takes the password or token, decrypts the volume key, then passes control to the OS for the rest of the boot process. Second is the low level kernel driver that has to be loaded before filesystems get a chance to load, and be 100% transparent with all reads and writes. Lastly, there is the control program which encrypts/decrypts the disk, and allows for password changes. All this needs to be virtually 100% bug free, else people will suffer massive data loss on a routine basis.

    However, with all the new corporate regs coming out REQUIRING full disk encryption on not just laptops, but sensitive servers and even some workstations, Linux, BSD, and MacOS will need to start getting a solution to this soon, else they will end up getting edged out of workplaces by Windows, not for technical merit, but legal.

  13. BestCrypt by Sedennial · · Score: 1

    We just finished evaluation of a number of products as we also require full disk encryption. We are purchasing BestCrypt from Jetico. It also handles encryption of pagefile, swap files, swap partitions, and hibernation files.

  14. Xen + Encryption + LVM + RAID on Debian by Burz · · Score: 1

    Here is a general overview of the steps needed to set this up on Debian. Also take note of the responses from Sander.

    It is probably more than you are looking for, since it doesn't sound like you want RAID. But that part is easily skipped. The LVM part I would keep, as logical volumes will make managing the virtual machines that much easier.

    Actually, a lot of this (the LVM and encryption parts) should be doable from the Debian 4.0 installer.

  15. Encrypted Seagate Drive by Anonymous Coward · · Score: 0

    These are apparently finally shipping

    http://biz.yahoo.com/prnews/070312/sfm025a.html?.v =1

    Seagate's Momentus 5400 FDE.2 (Full Disc Encryption) hard drive features perpendicular recording technology to deliver up to 160GB of capacity, a fast Serial ATA interface, and hardware-based AES encryption