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?"
Truecrypt Whole Disk Encryption has less than 1% over head. I can't see the problem. Surely the patent and IP information security outweighs this minimal overhead.
Perhaps one answer for storing data securely, but allowing it to dynamic expand is to create a PGPDisk that is dynamically expanding. Then, the data in can be safe, but the file can be moved to bigger RAID arrays if need be.
Surely what is required is to isolate the sensitive information, so that it can be protected.
Blanket encryption may impress some people, but it hardly solves the problem.
Details of how to implement isolation and protection would depend on the data, and which subsets are used in the calculations.
Stephan
http://stephan.sugarmotor.org
Do you have any numbers to back this up or are you just repeating common knowledge from decades ago?
TrueCrypt claim a 1% overhead. With multi-processor machines, I doubt that's even accurate anymore.
How we know is more important than what we know.
It will take longer time to read/write and the CPU will also take a hit.
Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption.
What do you mean by "incompatible"? At first glance, you seem to mean that there are certain file formats, making use of compression, that cannot be stored on the encrypted drive. That certainly can't be true.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
Do you have any numbers to back this up?
Here's some numbers: http://ask.slashdot.org/comments.pl?sid=1012285&cid=25566509
Make of them what you will :)
we're selling a different solution, but some remarks from our real life experiences:
Sincerely yours, Martin
"Marketing is not a science even if its an Open Source project"
Run some tests on a drive. Run TrueCrypt, re-run the tests, look the difference in CPU load and performance and then try and work out where the 1% number comes from.
Personally I think its based on averaging time across when you aren't using the machine.
An Eye for an Eye will make the whole world blind - Gandhi
TrueCrypt claim a 1% overhead. With multi-processor machines, I doubt that's even accurate anymore.
Yeah - with version 6 of TrueCrypt, they introduced support for multiple cores, with almost double speed on a dual core system over a single cores system.
I use a TrueCrypt encrypted USB disk to store and run VMWare virtual machines and I see no difference in speed over using a non-encrypted USB disk (same model).
There are several reasons why a policy of having all disks encrypted is bad:
1. Sensitive data should not be stored on a computer that can be carried away or easily accessed, with or without encryption.
2. Blanket security measures just means that the employees will find ways around them which usually means that you probably end up with bigger security problems.
3. Failing or failed disks goes from a serious problem to a critical problem for recovering data.
4. If you are running I/O "happy" software you are going to take a perfomance hit.
5. It's not a "green" solution since the encryption is done in software and the computer is going to use more power.
Oh, and let me re-iterate: Sensitive data should not be stored on a computer that can be carried away or easily accessed, with or without encryption. Just look on how MI5 left laptops all over the place.
The policy we use when working on sensitive data is that it's all stored centrally with rigorous security measures for accessing it and the only way to access the data is through a Sun Ray thin client. That way we minimize the risks for electronic information leakage, ie. someone mailing information etc.
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
The FBI has already demonstated that it is extremely easy to bypass the security on those drives. I would not use them.
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
I work with the DoD on a classified program. You're right, we don't use encryption on any of our desktops, but the only reason is because you go through 2 security gates with guards, then finally enter a closed room with a giant digital lock with a badge swipe and keypad on the door, not to mention a giant separately digitally controlled deadbolt in addition to the digital lock.
You better bet your ass that we use whole-disk encryption on any machine that would leave the building, though (such as laptops). And those are unclassified!
I wasn't even talking about desktops though, I was talking about compute servers! I have used a few clusters at LANL, and yeah they have separate classified and unclassified machines (or sometimes, sections of machines) that are partitioned off for classified work, but even the classified part never (as far as I know) uses whole-disk encryption. The original question specifically said that they were intending to encrypt their servers as well.
I used to have my laptop hard disk encrypted (using LUKS) but the hardware is getting pretty old now and I was starting to have problems with timing-sensitive applications such as audio and video. I think it was more bad timing interaction between the crypto layer, LVM, ext3 and the memory cache than raw throughput issues. I had a lot of layers and they weren't quite talking to each other right. Most of the time this was fine but occasionally it would add a tiny bit of latency to a disk request and audio would skip or video would jitter. It drove me round the bend.
Now, with everything else the same but minus the crypto layer things are much better. My laptop isn't as secure but then again I don't move it around nearly as much any more and don't have that much of worth on here anyway. Whether or not to apply something like this depends entirely on the situation.
My windows work laptop went from a fast little Duo Core fairly recent Dell which was quick but felt pretty damn cheap to a complete slow dog.
Not sure if its the software my company used or if its the disk IO overhead or what.
I do know after encrypting my entire disk I now get the PGP login screen immediately after the CMOS screen and before the Windows loader. No Problem.
The real problem is after that. The minute Windows loads up the disk starts churning and barely ever stops.
It just churns and churns and that little hd light just keeps going and going.
And everything just slows right down after that. Oh yes I am not the only one saying this either. Almost everyone reporting the same sort of results.
I actually thought it was a good idea - considering the amount of travel many deployment personnel in my company commit to in a year.
But do your research.
Try out whatever solution with your heavy hitting power users.
Don't settle for security that hampers performance.
ACK
I don't understand people who think that if they encrypt something it automatically becomes secure. For that data to be of any use to someone it will need to be decrypted and relevant people given access, so that destroys the notion of defacto encryption for security right there.
Encryption assumes that bad people are going to get access to your data whatever happens, and if you are using whole disk encryption then you really need to be seriously asking yourself who has physical access to your disks and where your data is located. That needs to be sorted out first, and once it is with data held centrally, I doubt whether disk encryption will be needed. You will probably need some form of encryption between the data and the remote users though. Using full disk encryption gives you something else to go wrong, is a variable in performance impairment you probably can't account, is something else to support for and will almost certainly be unnecessary once you've taken other steps first.
If you're keeping confidential patient information where it would be a Bad Thing(tm) if it ever got mislaid (even if it is encrypted, you don't want a computer with stuff on it lost I assume), in the name of all that is holy, please centralise your data and vet access. Stop people from passing around Excel spreadsheets of data, regardless of when and how it is encrypted.
I really am aghast as to how stupid people are about how and where their data needs to be protected. PGP is the wrong solution here, if you can call it a solution.
actually there's not much disk hit. The CPU loss does exist but isn't awful. I don't do anything that computationally intensive on my laptop.
I ran quite a few tests on my solution; I don't really care if some other software costs you 50% overhead and makes it impossible to use compression software [impressive kernel hack?], for me I lose about 20% write speed 30% read speed, and that's only for sustained read/write.
Day to day use? Didn't slow down a bit. Just as responsive. Battery life? Lost about 10 mins. CPU? Still idles at 0.00.
The cost to me was $20 for the encrypting hdd (that's the differential) and a bit slower for copying massive amounts of data. The upshot? When my laptop with all my financial documents, years of personal email, credit cards, and login credentials for root on some servers I'm responsible for was stolen last year, I lost no data and no one else gained any. The Debian ssl bug hurt me more than that loss (the laptop was actually insured).
The benefit to my using encryption is marginal. So's the cost. The hdd was a toy to play with. The software was a checkbox during installation.
So no, I wouldn't do this to a work computer unless there were a good reason (like being a laptop). But for my personal machine it makes a lot of sense.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
A coldboot attack is trivial on paper and in a controlled environment, but not in real world scenarios.
First you need to get hold of an unattended machine that works and the disks are mounted. You can minimize the probability of that by enforcing certain policies such as never leaving the machine unsupervised, closing access to the computer's case or even locking the case, etc.
Trust me, cold boot attacks are not the greatest concern.
The saddest poem
My 2 GHz Pentium M laptop suffers a severe performance impact from a LUKS AES encryption which I use for internal disks and on external USB disks, and the worst thing is that it becomes 'choppy' during large data transfers, meaning the machine freezes every few seconds when copying from encrypted USB disk to another encrypted USB disk. On single-disk transfers, the machine manages 25 MB/s without encryption, with a very low load, i.e., the CPU is still mainly free to be used for computing, but only 16 MB/s with encryption + very high load and choppiness. Copying from one disk to the other degrades from 25 MB/s to only 10 MB/s.
When using the disks normally for working, this is no problem, however. There's only a problem when transfering high amounts of data to/from the disk. So it depends entirely on your disk usage, of course.
My 3 GHz Core2Duo, on the other hand, does not even seem to notice that disk encrytion is used: no performance impact at all, so it seems. I am sure I could find some degradation when doing precise measuring, but it is not normally noticible when working on the machine. With or without encryption, the machine manages ~30MB/s to/from USB. And 35MB/s is the max. you'd ever get out of a very good USB disk today.
If you've got enough money lying around, you could get a Blet--er.. probably shouldn't use the code name. You could get a MR10is "VAULT" RAID adapter from LSI and IBM (for SAS and sata drives). I got to QA test it, put it through its paces. It seems to be pretty decent (now) and lets you fully, transparently encrypt your hard drives.
They're over $1,000, but if performance and security are that important to you it may be worth it. The VAULT only supports internal drives, but I think a morg--er.. I don't even know what the non-code name for those cards are... I think an encrypted version of the MR10m, which is for external SAS/SATA hard drive enclosures, is in the works.
Skiffy is Spiffy, but Ort is tort.
If they have clusters that are processing classified data then those clusters can only be accessed from classified terminals which are physically controlled. I don't believe it's possible to partition a "section" of an unclassified machine to do classified processing. If classified machines are talking across an unclassified network then they've got Type 1 encryption devices sitting in between them and the network. Protecting classified resources is completely different than protecting unclassified resources since there's already mandatory physical security around classified machines.
Are you sure your gig of zeros are treated exactly like any other data? If I screw up my simulations they usuually end up processing lots of zeros. It's obvious when this happens because they finish very quickly. Maybe you should generate a gig of random numbers instead?
USE THE CRYPTO
and yes, I'm shouting. This has been resisted for too long -- its kind of like garbage collection in programming systems.
The slow part is the physical drive. The crypto can be done FASTER than the physical drive, which means, at worst, that an additional processor needs to be assigned.
Indeed, the ONLY time I recommend crypto not be used is when dealing with US border. There I use file crypto on specific projects, along with dd to overwrite freespace and swap (before crossing).
But, if everyone (looking at US citizens) starts USING crypto, a fully encrypted laptop would not raise suspicion.
Just another "Cubible(sic) Joe" 2 17 3061
I'm not a network administrator, though I used to be. Now I own the company, and the policy stands unbreakable, period. There is no compromise.
In return, 5 years of zero security breeches, zero data loss. I don't know about you, but I like to sleep well at night--and in my position, that's already difficult enough.
And of course the user's needs are seen to, but not to the detriment of security under any circumstances, ever.
It's not just 'a lot', it's unacceptable. HPC usually is about real-time performance or doing huge jobs as fast as possible. In the latter case; imagine waiting 3 years instead of 2 for a calculation to finish. Regarding real-time work, 30% cpu loss may very well be the difference between possible and impossible.
That may have been true prior to Sarbanes-Oxley and other legislation but in the "SarBox" world where Execs have to sign off on controls in place and Auditors audit that policies are complied with considering an IT Policy a flexible rule is likely to get someone quite upset at you.
"Performance" is only a valid topic after addressing reliability.
In my company, we gave up on PGP's whole disk encryption after it consistently locked up (but was ok after many multiple reboots) on both Panasonic Laptops and Lenovo Laptops.
For the last few months, we have been trying TrueCrypt on the above brand laptops and also and HP desktops with no issues (as of yet).
If you load RAM by opening a bunch of simultaneous Windows and then run some mathematical loops that represent the kind of calculations your environment demands, you can then determine whether the overhead of TrueCrypt (or whatever) is worth the security benefit.
Good luck.
No matter where you go . . . there you are. - Buckeroo Bonzai
Live Long and Prosper - Thanks Leonard. You are missed.
I'm a big fan of TrueCrypt, and have used it for about 3 years. In that same time, my company has rolled out PGP Full Disk encryption. Honestly, we've had nothing but positive feedback about how unintrusive the product is. This is easily the security tool with the highest positive employee feedback we've ever deployed, hands down.
Pointing out to the IT helpdesk that they need to implement more security because only-encrypotion is not enough will not help you in preventing you high performance kit to be transformed.
PS, and don't forget to kill anti-virus in the high performance computers. If you think that disk encryption cost a lot of performance, think again, on-access anti-virus-scanning is A LOT more expensive in MY experience.
This works fine when everybody is using fairly standard software.
But it fails miserably when you are in a true R&D environment.
I worked in a Lab when an "edict" occurred that only windows PCs could be connected to the corporate network. Couple of dozen scientists putting in purchase orders to replace old but functional equipment in the $100k to $10m price bracket with the justification "drivers only available for , need to upgrade equipment to get PC support" and firing them up the management chain and someone saw sense very quickly.
It was actually rather amusing to watch (I wasn't affected - my group had our own completely independent network with independent connections to the world and my corporate PC was a bog standard supported (R&D) machine). A few rumbles of discontent when the email came around and then someone had the bright idea of deciding to cooperate with the edict rather than complain to fight it.
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
Fine, as long as you work my hours.
Of course. That's why we're support.
I've gotten up early to make changes, and I've stayed up late to make changes. It's part of the job.
I've never (ten years or so) had a local hardware issue extend into the host network. It seems to be fairly hard to do that if you're not an idiot
I guess you're not an idiot :)
Mostly, I'm talking about PHB-types that bring in a Linksys wireless router and plug one of its LAN ports into the building network. We also used to see issues where people bridge the company wireless network to the wired network, causing all sorts of issues, too.
Don't forget to calculate the increase personnel time required to meet current output rates. This is often many times more $$$ then what some upgrade hardware costs. Then if they're ok with decreased productivity, and therefore higher man hours, then it's purely a management decision. You can also point to this report at a performance review as a reason goals were not met.
Take a patch cable. Plug one end into a switch. Plug the other end into another switch on the same network. Or even the same switch.
Happened twice at my old office, once during an office move, once just by accident. More sophisticated equipment detects this problem, but we just had dumb switches.
So my work did this to all desktops and laptops (though not servers, thank goodness). Of course the ironic bit is these desktops are all in a secured buidling...
This is on Windows boxes so YMMV but we've had lots of complaints. Stupid stuff like opening a new file explorer has a 2-3 second lag each time. Scrolling down a list of files in a directory has a 3-5 second lag.
The worst part though is when the mandatory "noon" virus scan starts. We actually had to move anyone who didn't already have a dual-core system to one so this wouldn't lock up their box for 10-15 minutes. And I do mean lock up.
All in all we've learned to live with it in the way folks learn to live with a persistent rash -- annoying but not life threatening.
Now, as many have said, in a HPC situation it might be different...
I wish I had mod points I could give you. That was pretty much a perfect summation of the way any good IT admin should act and feel.
I can't tell you how many times I had to do a search of 15,000 SQ foot lab floor because some aerospace engineer thought it would be a good idea to plug the private network side of SOHO router into the main network. They just couldn't seem to understand why an rogue DHCP server would be a problem.
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed H
Did you know that PGP WDE isn't officially supported on RAID configurations? I think it says a lot that the product worked in your environment, but a 12-disk RAID 50 configuration isn't exactly the sweet spot for a product targeted at laptop users.
No surprise that performance would be poor given that WDE is neither tested nor optimized for that use case. ...yes, I work for PGP.
I have successfully created a bootable PE cd that can mount PGP Partitions/Drives. This allows for recovery WITHOUT decrypting. A bad block on an encrypted drive is no different. If NTFS becomes corrupted or, heaven forbid, the master file table takes a dump, normally you WOULD have to decrypt first to fix, but not so with a bootable PE cd that can mount the partition. It is business as usual. There is MOST DEFINITIVELY a performance hit when running PGP, but mainly on the CPU. Disk performance itself is not very noticiable (i.e. somewhere between around a -7% in my own experience), but when there is high I/O, whach your system process take off. The filter driver for PGP runs under this process, and there is no doubt about it.