Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Full Disk Encryption - Xen, Windows and Linux?

Cliff posted more than 7 years ago | from the protecting-your-data-across-various-OSes dept.

Encryption 49

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? "

cancel ×

49 comments

Sorry! There are no comments related to the filter you selected.

Look at dm-crypt (4, Informative)

Cheeziologist (596855) | more than 7 years ago | (#18909793)

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

Re:Look at dm-crypt (2, Interesting)

phrasebook (740834) | more than 7 years ago | (#18909931)

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?

Re:Look at dm-crypt (2, Informative)

Jah-Wren Ryel (80510) | more than 7 years ago | (#18910223)

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: [saout.de]
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.

Re:Look at dm-crypt (1)

phrasebook (740834) | more than 7 years ago | (#18910255)

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.

Re:Look at dm-crypt (0)

Anonymous Coward | more than 7 years ago | (#18910959)

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.

Re:Look at dm-crypt (4, Informative)

rjforster (2130) | more than 7 years ago | (#18909995)

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.

Re:Look at dm-crypt (4, Informative)

swillden (191260) | more than 7 years ago | (#18910263)

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.

Re:Look at dm-crypt (1)

rjforster (2130) | more than 7 years ago | (#18910377)

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.

Re:Look at dm-crypt (2, Informative)

mangu (126918) | more than 7 years ago | (#18910535)

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.

Re:Look at dm-crypt (0, Redundant)

rjforster (2130) | more than 7 years ago | (#18911463)

In cryptographic terms it is plain text.

Re:Look at dm-crypt (1)

Matthew Bafford (43849) | more than 7 years ago | (#18912017)

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

Re:Look at dm-crypt (2, Interesting)

swillden (191260) | more than 7 years ago | (#18910591)

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.

Re:Look at dm-crypt (1)

rjforster (2130) | more than 7 years ago | (#18911593)

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.

Re:Look at dm-crypt (0)

Anonymous Coward | more than 7 years ago | (#18917071)

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.

looking forward to replies on this one (2, Interesting)

Cybersonic (7113) | more than 7 years ago | (#18909801)

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

Re:looking forward to replies on this one (1)

Paracelcus (151056) | more than 7 years ago | (#18913801)

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 [ce-infosys.com]

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

It occurs to me... (0)

Anonymous Coward | more than 7 years ago | (#18909845)

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

Debian's new installer is spiffy (4, Informative)

deftcoder (1090261) | more than 7 years ago | (#18909953)

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/ [debian.org]

Re:Debian's new installer is spiffy (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18910323)

Debian died like 2 years ago. We've moved on to Ubuntu.

Re:Debian's new installer is spiffy (0)

Anonymous Coward | more than 7 years ago | (#18910421)

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.

Re:Debian's new installer is spiffy (0)

kestasjk (933987) | more than 7 years ago | (#18910729)

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.

Re:Debian's new installer is spiffy (0)

Anonymous Coward | more than 7 years ago | (#18911377)

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.

Re:Debian's new installer is spiffy (0)

Anonymous Coward | more than 7 years ago | (#18912399)

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

Re:Debian's new installer is spiffy (2, Interesting)

kestasjk (933987) | more than 7 years ago | (#18912443)

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.

Re:Debian's new installer is spiffy (1)

Bishop (4500) | more than 7 years ago | (#18916095)

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.

Re:Debian's new installer is spiffy (1)

Bishop (4500) | more than 7 years ago | (#18916007)

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.

Re:Debian's new installer is spiffy (0)

Anonymous Coward | more than 6 years ago | (#18932749)

What about Ubuntu?

These questions always make me smile... (2, Insightful)

Anonymous Coward | more than 7 years ago | (#18910093)

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.

Re:These questions always make me smile... (1)

zCyl (14362) | more than 7 years ago | (#18910289)

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.

Re:These questions always make me smile... (2, Insightful)

hey! (33014) | more than 7 years ago | (#18911745)

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.

Re:These questions always make me smile... (0)

Anonymous Coward | more than 7 years ago | (#18914559)

Shiny things make you smile, you moron.

Re:These questions always make me smile... (0)

Anonymous Coward | more than 7 years ago | (#18914747)

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!

Re:These questions always make me smile... (1)

jsellens (760992) | more than 7 years ago | (#18916029)

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

Re:These questions always make me smile... (1)

Gothmolly (148874) | more than 7 years ago | (#18916523)

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.

Compusec by CE-Infosys (1)

mlts (1038732) | more than 7 years ago | (#18910113)

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.

gordon freeman approves... (4, Funny)

User 956 (568564) | more than 7 years ago | (#18910245)

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. [wikipedia.org] Who needs encryption when you have a low-gravity parallel dimension as a safe-deposit box?

Have you considered Pointsec on Linux? (2, Informative)

swillden (191260) | more than 7 years ago | (#18910271)

They have a Linux version [pointsec.com] . 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.

Re:Have you considered Pointsec on Linux? (1)

Mr2cents (323101) | more than 7 years ago | (#18911865)

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 ;).

Re:Have you considered Pointsec on Linux? (1)

bratgitarre (862529) | more than 7 years ago | (#18914475)

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

Re:Have you considered Pointsec on Linux? (1)

bill_mcgonigle (4333) | more than 7 years ago | (#18915977)

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.

to all the people advocating dm-crypt (1)

Alex (342) | more than 7 years ago | (#18910345)

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

Do you really need full hard disk encryption? (1)

Futurepower(R) (558542) | more than 7 years ago | (#18912167)

If you can accept just having some partitions encrypted, TrueCrypt is wonderful [truecrypt.org] .

Known plaintext attack on encryption (3, Interesting)

Anonymous Coward | more than 7 years ago | (#18912233)

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.

Re:Known plaintext attack on encryption (1)

DanLake (543142) | more than 7 years ago | (#18916131)

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.

Re:Known plaintext attack on encryption (1)

tigersha (151319) | more than 7 years ago | (#18916699)

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?

I wish FDE were more common with UNIXs (1)

mlts (1038732) | more than 7 years ago | (#18912365)

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.

BestCrypt (1)

Sedennial (182739) | more than 7 years ago | (#18912645)

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

Xen + Encryption + LVM + RAID on Debian (1)

Burz (138833) | more than 7 years ago | (#18912683)

Here is a general overview [lxer.com] 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.

Encrypted Seagate Drive (0)

Anonymous Coward | more than 7 years ago | (#18915409)

These are apparently finally shipping

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

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
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?