Slashdot Mirror
Resisting the PGP Whole Disk Encryption Craze
alaederach writes "I run a lab in a non-profit academic life sciences research institute. Our IT recently decided it would be a good idea to use PGP whole disk encryption on all of our computers, laptops and servers and picked PGP's suite of software. The main reason is that a small subset of our researchers work with patient information which we obviously are mandated to keep confidential. My lab does a lot of high-performance computational work (on genes from Tetrahymena, no humans here) and I am concerned that the overhead of complying with our ITs new security policy will be quite detrimental to my research program. For example, dynamically reallocating a partition on a PGP encrypted disk is apparently not possible. Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption. Interestingly, it is hard to find any negative articles on PGP, probably because most of them are written by IT pros who are only focused on the security, and not usability. I therefore ask the Slashdot community, what are the disadvantages of PGP in terms of performance, Linux, and high-performance computational research?"
Whole disk encryption is excellent for security, but it will bog you down in disk access times. Depends on a lot of things, but reading and writing files can slow down up to 50%, but usually the slow-down is much less. If you are doing something that involves a lot of disk access and it doesn't need to be encrypted, then create a special, non encrypted partition for that.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
An IT policy is a general rule which has to be interpreted and adopted. It's not supposed to be followed by the letter. Ask your IT department what they want to accomplish with the policy, and how you can help them accomplish that without having your work ruined.
You've got a good case for an exception from this policy. Just follow the exceptions process and have your management sign off on the risk. Case closed.
It took 2 days to encrypt an entire 160gb ide hard disk with a K6-2 400mhz processor, and afterwards the computer could only server files at about 400k per second. With a 2ghz processor the performance difference is negligible, and could serve at full speed with only tiny cpu usage. So I think full disk encryption overheads is irrelevant on modern cpus.
As for not being able to resize a partition, well that's good because if your hard disk is to contain anything of importance then you would have to be inept to resize partitions and expect data to maintain it's integrity, no matter what the file system format or brochures on partitioning programs try to tell you.
in these type of departments all the computer are on all the time anyways and whole-disk encryption is 100% vulnerable to hard-boot attacks. It may be remotely useful on laptops but for desktops its entirely useless
if you want to actually protect your data you need to encrypt only whats sensitive and only mont it when neccicary. also PGP is closed source and what are you going to do if they stop supporting, use truecrypt or LVM, etc. Also dont neglect network protection where the real data is stolen
Surely what is required is to isolate the sensitive information, so that it can be protected.
That's a great idea that in practice will leak your information. The reason is that _every_ application that touches your data needs to know that it should keep your data confidential.
Broswers know to not cache data transfered over https. It knows the data was encrypted, it knows to be smart with it [for "protective" value of smart].
When you have a program that reads a file through a transparent layer of encryption, it never sees the "please-be-careful-with-this" label, and so the desktop search engine will index all the strings, the editor will write backups to . or /tmp, and so forth. All the apps think they need to do is respect what you meant by your mode bits (if you're on *nix), so it'll chmod/umask the /tmp copy the right way. If someone grabs your disk and you didn't encrypt /tmp, you lose.
And no, encrypting /tmp won't fix it: you need to know that everything the user of the data can write to is encrypted if you want to be sure. I only know one way that I can somewhat confidently say solves the problem: encrypt everything. [and then there's the network, but we'll save that for another decade ;)]
Only encrypting the sensitive data is like carrying water in bucket used for target practice: stuff will leak.
Their product doesn't seem to run on Linux.
There is better, cheaper F/OSS software to do the same thing though; Ubuntu and FC9 already include a whole disk encryption option at install. (It's better because it's much less likely to have an NSA back door, although obviously never completely certain).
As for performance, when I tried it (luks encryption) on a desktop machine, it wasn't noticeable; but I wasn't moving hundreds of gigs around.
The question now is what are they trying to protect. Encrypting laptops is sensible, and in fact, given how easy & cheap it now is, it's rather stupid not to do it. On desktop PCs, it's not that clear. Whole disk encryption will only protect you against someone with physical access to the machine turned off. It certainly won't protect you against trojans or browser based vulnerabilities. So the question is, do random strangers roam your offices?
And encrypting servers/clusters? That's just silly; unless you expect the men in black to storm in your building.
Someone will write the passphrase down anyway. Isolate the data.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
I've worked with people during various research projects who decided to encrypt, for some very good reasons. I've had one admin die, and one researcher have a stroke. In both cases they had information necessary for the project that nobody else could get to, even when their hard drives were retrieved. The results are that after several years, the stuff is still sitting somewhere unusable because the people who attempted to get to it were stymied. Enforcing PGP on an entire network could multiply this problem. I would think that enforcing PGP on users not needing it would be a royal pain for them.
What we've done and thought of since:
Have only those with sensitive information encrypt. Have them work on machines not connected to the net. If they need net access, have them connect only for the time necessary, and mandate pre-encryption back ups prior to connecting.
Preferred, but resisted, keep the sensitive machines off the net and have the researchers connect to the net via a different machine without the sensitive info on it. If they want to use it for transfers of such info, make them use sneakernet between the sensitive and connected machines. In this scenario, they only need PGP for what they're going to transfer to the connected machine and thus to outside. Both admins and researchers expect full connectivity throughout their net, but the best security is a nackered line.
I use the sneakernet method exclusively. What I transfer when necessary is hundreds of MB to tens of GB of data. It takes me 10 to 30 minutes to encrypt, burn the data to DVDs and carry it to the connected machine. Like most researchers, I'm busy and don't want to spend my time doing this, but I have assistants I can put the task on.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
For my company, data has to be kept secret. Yet we do not do encryption. The fear for corruption of data is far bigger than the chance that a cracker gets access.
As to personal experience: With TrueCrypt, changing between accounts (on a Mac) with TrueCrypt open can wreak havoc. The data can be copied but the secure thingie has to be re-created from scratch. We cannot have encryption working properly 99% of the time. It must be 100.00%.
Bert
"But: do the measurement in your own world. My software, hardware and artificial measured usage pattern may differ from yours, subtly but enough that my conclusion doesn't transfer. Be scientific about it :)"
Best advice I've seen - try and build up a representative sample of a day's work (or just a random sample if that's not easily determinable), copy it, run one copy on unencrypted disks and one on the mandated encryption.
If there's a significant difference take the evidence to your IT dept. or supervisor and hope for a favourable decision.
My concern with encrypting an entire disk would be fault tolerance. If a sector goes bad on a non-encrypted drive, you might lose a file. If it goes bad on an encrypted drive, do you risk losing more data or even the entire drive?
Of course, one could say that's why you make backups. But presumably the backups would also be using encryption. Therefore, they would be susceptible to the same effect. If there is a greater chance of total data loss on each device, the chance of multiple device failures leading to unrecoverable data also increases.
I'm not sure that assuming that just because somethings done in hardware, that it happens in zero time (or even near zero time) is at all accurate. A review I read of a different encrypted drive, said it was 5-10% slower than it's non-encrypted equivalent. It wasn't the Seagate you're talking about, but I doubt that even hardware encryption can do it instantly, so I think your "zero" is an exaggeration.
Linux software RAID 5 uses 2% CPU under heavy load.
Given the fact that you can always recover your data with any Linux livecd gives it a definite edge over a hardware raid solution where you need a similar model to read the data.
In the time you spent writing this post to Slashdot, you could have written a friendly letter to your IT department stating that you want some machines to not use this encryption, because these machines need maximum performance and anyway do not store any kind of personal information.
Every expression is true, for a given value of 'true'
The only protection that Full Disk Encryption gives is if someone physically gets their hands on the machine that they can not boot the machine and read its contents. This make perfect sense for laptops but makes little sense for any pertinently fixed location workstations. A laptop will physically leave the premises so it leaves itself open to theft, but a workstation (assuming you have some decent form of physical security) is much less likely to need this protection. Once a workstation is booted and the disk drive unlocked digitally then any hacker that gets a foothold on the system would then have access to it, so all that overhead of full disk encryption does no good unless the encryption is done per-user-session. When you need assess to the data you authenticate and start decrypting then, and keep it encrypted across the network. Yes, that data that you speak of should be encrypted, but you must encrypt it at the correct level to actually increase its security rather than just slowing down the machine. Anything short of that level of control and you are just fooling yourself into thinking you have protected the data. Fool-Disk-Encryption is not always the answer.
The submitter is in a research institute. Some labs in that institute have patient data, and therefore require significant security like disk encryption.
His lab works with a protozoa, and has massive computational requirements. There will never be any patient data near his lab, because the people who work with patients are in a different lab (think different department in business). They do not need disk encryption.
You say Truecrypt has "1% overhead", PGP presumably has some other "% overhead." The submitter is asking what the details of that overhead for PGP, truecrypt etc are. Whats the CPU usage, memory usage? Are disk performance penalties constant, or are they dependent on average file size, number of files, format of those files, etc etc etc. "1% overhead" may hide whopping huge performance penalties for specialist users.
I have serious doubt we even need hardware RAID anymore with current CPU speeds.
At some point in time I believed the same thing. I did a test a few years ago to see if it's still worth it to bother with hardware RAID and configured an system with linux and software RAID.
This was for a fileserver in a high performance cluster so speed mattered. I don't have the exact figures here right now, but from what I remember two years ago the software RAID solution was between 7 and 15% slower. Once you start hitting the performance limit your processes hit I/O wait and your performance goes down. When I added LVM to that back then performance got shot to hell.
Now, it's not as bad as it seems, you still get decent performance (especially considering that your setup suddenly costs a lot less and can be done on commodity hardware), and with a fair bit of tinkering with blockdev and your read-ahead buffer (provided you have enough RAM, and your usage fits that particular pattern) you can still get some very nice performance.
The reason that we went with hardware RAID in the end was because hardware RAID isn't all that expensive, and the performance gains were noticeable especially on systems that have to run 24/7 at maximum throughput.
Again, for consumer systems and services where performance isn't a primary concern software RAID is an attractive option, especially if you're on a budget.
As for overhead with encryption: it would make a nice experiment but I think 1% overhead is very optimistic especially on a busy system. The only way to be sure is to compare your performance now to the performance when you encrypt the entire disk. The only time I tested truecrypt I got a throughput of 80MByte/s, while unencrypted I got 120MByte/s, and it's been a while since I tested this. Those truecrypt tests weren't finetuned either, it was basicly a test to see if it was easy to implement.
Anything I mention here has to be taken with a grain of salt since a lot of time has passed and a lot has changed since those tests.
If policy dictates that you have to setup X, the best way to become an exception to this policy is to prove that that policy is detrimental to your project and might end up costing a lot of money. Policy doesn't care about performance, but it cares greatly about money and lost time. Do your tests, do the math, add a pricetag and talk with your manager.
"There is lots of cpu cycles left"
Uhm. You are losing 30% cpu cycles, that is quite a lot. Yes there is amble power left for your office apps etc. but original poster says he is doing high performance computing - losing 30% of your throughput for reading data is a lot!
It depends a lot on what you're doing with the data. If you've got a single-threaded process that's consuming 50MB/s and you can read 100MB/s from the disk and run 100MB/s decodes on the other core, you won't notice the speed difference. If you're doing random access then you will have, say, a 9ms seek time to get the data and then a few more ms to decompress it. If your process is already I/O bound (many scientific computing tasks are) then a 9ms decode per block will halve the speed of your computation.
The correct solution for this lab seems to be to borrow a policy from most defence-related sites. Have a secure and an insecure network. The secure network is allowed to access confidential data, the insecure network isn't. Run encryption on the machines on the insecure network, don't bother with it on the insecure machines. If one of the insecure machines is compromised or stolen then nothing confidential is lost.
I am TheRaven on Soylent News
The submitter is in a research institute. Some labs in that institute have patient data, and therefore require significant security like disk encryption.
Repeat after me: "The first line of security is physical."
If the servers are locked in a room with limited access (like, oh, say, 95+% of servers in the corporate world), then the probably not.
Data security is about securing the data using reasonable compensating controls. If no one can get to the disks, and those who can comprise a limited list of, say, trusted sysadmins, then it doesn't matter whether they're encrypted or not.
Requirements, if properly written, never specify implementation details -- the means. They only specify what is needed. How that is achieved is irrelevant so long as it the requirement is achieved completely.
So other than for devices that are not in access-controlled environment (like laptops or, in some cases, workstations), the need for whole disk encryption at most places is nil.
My blog
Considering the type of data that the OP is working with and the choice of the product to use, it may be that they fall under the government mandate of using encryption and that it HAS to be FIPS 140-2 approved. In this case TrueCrypt (as much as I like it) is not a valid choice, as it is NOT FIPS 140-2 approved.
Only encrypting the sensitive data is like carrying water in bucket used for target practice: stuff will leak.
Yes, that's why he said isolate.
Example- you have a research lab. All the equipment in the lab is NOT connected to any outside network, period. The only people allowed in the lab have access to the data anyhow, just password protect the terminals.
Now, once you need to store the data for backup, or access it outside the lab, then is when you encrypt the data.
Everyone compresses before they encrypt. Everyone. That's why I think the whole compression issue is bogus.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
You pop in the boot/recovery CD the encryption app forced you to create before it'd encrypt the drive? At least that's how it works on TrueCrypt.
Les Miserables Volume 1 now up with my reading of
RTFA FTW!!!
The Submitter him/herself doesn't work with sensitive info, just other dept's. IT is enforcing an overly broad solution on everyone, with considering the downside. I agree with you that sensitive data needs to be secured, but rolling out disk encryption to everyone in a company when a subset of everyone is dealing with sensitive info is maybe overkill, and the impacts to the primary activity of other depts needs to at least be quantified and considered.
Comment removed based on user account deletion
Encrypted partitions are excellent for their intended purpose: To safeguard the confidentiality of sensitive data. But an "across the board" policy of encrypting every HD in a whole shop is simply nuts. In addition to the performance problems with intensive computation requiring constant read/write, the way to recover from a file system corruption problem with an encrypted partition is very often "Kiss your data goodbye, it is gone forever, period." So, add the cost of a major upgrade in your offsite backup process, in money and network and in-the-box processing overhead, to whatever the PGP license costs /and/ the vastly increased risk of major data loss.
After you have done your analysis as to how much productivity is lost, be -certain- to equate that to a dollar figure, so it can be extrapolated over the quarter and over the year. Nothing will make or break a project more than being able to assign a hard-dollar figure to it.
If it takes you an additional hour a week to preform tasks, and your value is $100/hour, then you effectively cost an additional $5,200 a year for lost productivity. Multiply that times all users in your lab. Managers understand cost and budget impact more than passionate resistance.
Good luck!
Awk! Pieces of eight. Pieces of eight. Pieces of seven... ERROR: General Protection Fault. [Paroty Error.]
Considering that much of your hard drive consists of non-private data, like the operating system, program install files, and spurious user junk, why bother encrypting the whole disk? Why does anyone bother? Just have an encrypted directory, partition, or even a second small hard drive and save all super-top-secret files in there.
So the best solution is to encrypt every drive on the campus? You can have security policies that are more specific than "PGP on every machine" vs "no disk encryption at all."