Posted
by
Zonk
on Thursday October 04, 2007 @01:06PM
from the seems-to-defeat-the-purpose dept.

A non-mouse Coward writes "PGP Corporation's widely adopted Whole Disk Encryption product apparently has an encryption bypass feature that allows an encrypted drive to be accessed without the boot-up passphrase challenge dialog, leaving data in a vulnerable state if the drive is stolen when the bypass feature is enabled. The feature is also apparently not in the documentation that ships with the PGP product, nor the publicly available documentation on their website, but only mentioned briefly in the customer knowledge base. Jon Callas, CTO and CSO of PGP Corp., responded that this feature was required by unnamed customers and that competing products have similar functionality."

If people complete various "hard" problems on quantum computers then the non-people at the NSA can probably afford to throw two billion (or whatever) at it to crack ALL MODERN ENCRYPTION that doesn't use quantum devices for keys.

When it comes to encryption it is exactly for this reason why I use the "clunky", "hard to configure", "no GUI" Open Source!

Ah, but that's not necessarily a defence against the NSA! Their backdoors might not be hidden in closed source binaries, or in obfuscated source code, or in your CPU hardware, or even injected covertly by your copy of GCC when it recognises encryption code. They might be mathematical backdoors, hidden inside well-known ciphers that are generally thought to be secure. There's the old st

I guess it all depends upon whether you think factoring large numbers is a hard problem, whether special cases might exist, whether huge amounts of investment dollars matter, etc. From there you make your own call about whether or not to go all elliptical (another

A backdoor that's documented, although poorly, that you can disable and requires access to the unencrypted disk beforehand? If it were the NSA they wouldn't have allowed it to be documented and you couldn't disable. However, I can think of several large corporations that would require something like this and would have contracts large enough to justify changing the product for. Paranoia doesn't seem to be justified in this case.

It looks very much like the kind of feature that a random bank or retail store would want - if the power goes out at a store, you want the system to be able to come back up and run the cash registers even though there's nobody technical enough to trust to press the "reboot" button much less connect a console and type in passwords.

If you RTFA, you'll see that it's a feature that you can only turn on if you've already got access to the disk, and PGP did it so it only works once.

Whoever modded that post flamebait is completely ignorant of the standards in the security agency, that commonly used security tools be completely open so that people can point out security flaws. With regards to this article, it sounds like the bypass feature was able to be turned on or off, and if they had documented it and let people know, then they could have taken the necessary steps to use it or not, depending on whether you were their unnamed customer.

This is not uncommon, though the lack of documentation is.... Most such encryption products offer the ability to specify a master encryption key across an organization. The way that works is that your individual crypto key protects a copy of the drive-specific crypto key, which then protects the drive. The company you work for has a master crypto key which is also used to encrypt the drive-specific crypto key. (Usually the latter part is done with PK crypto so the employee can only encrypt contents with

But... PGP has a peer review, open-source process [pgp.com]. They're just a commercial product, too. [In other words, it violates the terms of service for you to compile their source code and use it without licensing it.]

uhh, if you new anything about PGP you would know that all the source is published. If you have a remote office without local IT staff this feature makes sense. Every month you have to patch your windows servers, most of these patches require a reboot and if this feature didn't exist you would have to send someone out to type in a passphrase making remote administration impossible. Anyways the use case that the original article envisions is ludicrous. If you have rooted the box with a trojan you have ac

Seriously, customers require this so IT staff can do remote support and reboot the machine remotely. It is only enabled for one reboot, and you must have cryptographic access to enable this feature. The only threat is if someone where to enable this, not reboot, and then have the machine stolen.

The only threat is if someone where to enable this, not reboot, and then have the machine stolen.

I see what is possibly another. I may enable a hole of this form:

If someone gets access to the disk or its contents before the reboot, they can clone the state of the encryption software - which will do one "unlocked" reboot. Later (up to a point where the encryption key is changed) they can shut down the machine, reapply this state, and bring it up without the password, gaining access to data that has been ad

They need to do unattended automated reboots of thousands of computers. These are enterprise customers.

They have the encryption key, and they want to apply security updates and reboot the computers. When the employees come to work in the morning, they expect the computers to be on and operational, as they left it.

If you don't use the feature, then it poses no risk. If you need to apply unattended updates to computers on a large scale, going to each computer and typing in the passphrase is not practical.

This is a non-issue, and a FUD article. You need to have UNLOCKED access to the encrypted volume to enable this feature.

Normal users using PGPDisk and not using this feature are at no greater risk for it existing.

There are kinds of businesses where all the offices have IT staff on site, and kinds of businesses that don't. Sure, your corporate data center has people there. But think about a retail store chain, where if the stores are small they've got a couple of clerks, or if they're large there's probably a store manager. There's no IT staff there - I've had banking customers, who are more likely to have technically competent people, that still couldn't dependably get the onsite people to plug the "Line" and "Ph

Is it possible, or likely that the NSA/FBI/DIA/DIS/etc. want to be able to ACCESS the encrypted disk/host when the system IS online, and presumably the disk IS encrypted disk? They know they *might* have the keys (by forcing the s/w vendor to turn them over, "or else"), but they want to keep to a minimum the talk that they DO have the keys.Now, assume they can set up a honey net, one which explicitly mimics the targets presumed safe haven. The target logs in, may be operating as root/administrator (and, FTS

Let me just get it straight. It's easier for you to accept that PGP has a malicious backdoor than it is to accept that they have a sensible feature that is quite useful (if ill-documented, but apparently it's mentioned in the knowledge base)?

A small dose of paranoia is healthy, but we're talking about a feature that has to be activated by someone who actually has access to the keys to begin with, that is, supposedly, valid for only one reboot, and that has a very valid use case.

Let me just get it straight. It's easier for you to accept that PGP has a malicious backdoor than it is to accept that they have a sensible feature that is quite useful (if ill-documented, but apparently it's mentioned in the knowledge base)?

With propretary software, there's no way to know. It could have any number of malicious or ill-conceived/insecure features. Why risk it?

With propretary software, there's no way to know. It could have any number of malicious or ill-conceived/insecure features. Why risk it?

Because a backdoor can just as easily be slipped into open source software, if not more easily since everyone's assuming "Oh it's open, someone else is looking for backdoors." On top of that, when things go south there's no one to point the finger at and no one to go to for support.

Look at all the security flaws that have popped up in Firefox over the past two years that co

"We call it a passphrase bypass because that is what it is. It is a dangerous, but needed feature. If you run a business where you remotely manage computers, you need to remotely reboot them."

and

"You cannot enable the feature without cryptographic access to the volume. If you do not have it enabled, you are not affected, either. I think this is an important thing to remember. Anyone who can enable the feature can mount the volume. It is a feature for manageability, and that's often as important as security, because without manageability, you can't use a security feature."

Also, from his wording, it sounded like it is not enabled by default. In other words, you can actively choose to sacrifice a bit of security in order to make it work properly in your environment. Sounds like a nice feature to me.

Yes, it is a nice(TM) feature and might be useful, but that is not the problem.

The problem is that the feature is fricking undocumented. There is absolutely no way to know it is there and how to look out for it. It also means that you can't just know how many of these backdoors are in there. Is it only the first undocumented backdoor ? How many more of the convenience features are in there by customer demand ? How do they affect me ?

When it comes to security software or hardware any and all undocumented features are BUGS! It's a principle, not a convenience!

If I were to evaluate said product it's something I'd like to know, in advance and fully documented, not hidden somewhere. The whole purpose of documentation is, well, to document things not to leave them for someone surfing extra docs on their website.

If they'd been open about it wouldn't even have made Slashdot, so it's a bit of an own goal - now they have to go and explain it all against a tide of misunderstanding. On stuff like this full disclosure is the better path to take IMHO.

If you have a PGP-encrypted drive, and you know the passphrase, you can unlock the drive until the next reboot. But PGP - and others as well, from TFA - have added a mode that unlocks it until the reboot AFTER that.

Most people wouldn't want to use such a feature, because it leaves your drive exposed for a longer period of time. Even PGP calls it "dangerous, but needed" (for enterprise environments that do

I follow you this far. But care to explain why it is appearantly undocumented? A potential security risk in a software, no matter how sensible to exist, MUST be documented so a user not wanting this security hole to exist can plug it. Especially when there are simple switches in place to plug it.

Couldn't a virus or other program running enable this "feature" without the user knowing? Basically you could set up the virus to enable the feature on shutdown, and then steal their laptop afterwards. Then when the thief boots it up, no password required. I would probably be difficult to pull off, but people using whole disk encryption would probably have some interesting data to steal.

Couldn't a virus or other program running enable this "feature" without the user knowing? Basically you could set up the virus to enable the feature on shutdown, and then steal their laptop afterwards. Then when the thief boots it up, no password required.

What also surprises me about the customers that would require PGP WDE to have such a feature is the way they would have to use the feature. Since this is command line driven, this is obviously designed for use in scripting. I have a hard time fathoming an enterprise organization that would, on one hand, require the use of full disk encryption of computers and then, on the other hand, distribute a script with a hardcoded passphrase in it, presumably using a software distribution tool like Microsoft's Systems Management Server (SMS), or similar. The risk of this feature of PGP WDE notwithstanding, we are talking about admins using shared/generic/static passphrases for all or many computers stored in plaintext scripts, set to execute in mass. If the complexity doesn't accidentally disclose the default administrative passphrase, then the fact that fallible humans keeping human readable scripts in N locations used every time Microsoft releases a patch certainly will. An average security conscious IT shop running Windows products (because PGP WDE is a product for Windows) will have at least 12 opportunities per year for devices to get stolen when they are in this vulnerable "bypass" state. Does the use of this PGP WDE (or any full disk encryption vendor as Jon claims competitors have similar functionality) feature increase the risk that laptops will be stolen on the eve of the second Tuesday of every month?

Except that the "virus" is an update script from IT on the eve of "patch Tuesday" (this is basically a Microsoft Windows only product) and the machine gets stolen then.

Note also that even though this password bypass feature must be enabled, there is no way to completely disable it.

You are right. However, it might be easier for the virus to go undetected if all it does is flip a bit on some planned day, when you are expecting to take the computer, rather than acting as a keylogger, or trying to send out data over the network. The less the virus actually does, the less chance it will be detected.

A customer with enough volume to demand such a 'feature' (myself I prefer to call it a bug) surely can justify the addition of a compilation flag as oppose to incorporating into general release. I am incline to think it's more likely to be brown nosing the current US administration.

There is an inherent flaw with many of the commercial laptop full-disk encryption solutions out there. I have the most experience with Utimaco's Safeguard Easy, but I know many of the other big players have the same fault -

The software has a feature called "Pre-boot Authentication", by which the encryption software is loaded after the bios, but before the (generally Windows) operating system. The user's password is used to generate the decryption key, so theorhetically not even the NSA could decrypt the laptop without the user's password.

Here's the flaw - the software has a checkbox to disable Pre-boot authentication. What this does is generate a default user with a random password, and then store this random password obfuscated but in clear-text in the same disk area decryption software. When you talk to the sales-people, they sell this as a feature, in fact about half of Utimaco's customers (so I'm told) run it in this mode because the encryption becomes transparent and it is much less intrusive on the user. (Basically the disk is automatically decrypted each time the laptop is booted, but you have to have a valid Windows login to get in.) Buried in the help documentation are warnings "For security reasons, you should Never disable pre-boot authentication". So the engineers and the company know the weakness of disabling pre-boot authentication, but they don't tell their customers when they sell the software.

Today it seems to break into these laptops with pre-boot authentication disabled you would need somewhat sophisticated tools and techniques, basically the same tools and techniques people commonly use to "crack" commercial software today. But I'm guessing that it won't be very long before someone takes the time to build this crack and releases it, rendering the laptop encryption useless to anyone who can Google for "Utimaco Crack", etc. Basically all the crack would need to do is grab the default user's password off the disk and use or duplicate the decryption algorithms that are also in clear-text on the disk.

I've talked to a number of IT security folks, and basically it seems like most people trust the sales folks and don't understand that its basically impossible to have strong encryption without having the decryption key stored off the disk (like on a smart card, or in the brain of the user.)

This dangerous, because it gives a false sense of security. Its an easy way to make full disk encryption have zero security benefit. Its might a feature that this feature is so obscure enough that security neophytes won't shoot their foot off. I'd be happiest if the feature automatically deleted the decryption key during the reboot. Thats enough to let IT do an unattended reboot and simultaneously discourage people from misusing the feature.

We use Utimaco SafeGuard Easy and we also bypass pre-boot authentication (PBA).

The problem is a company may have thousands of laptops in the wild and Active Directory passwords that expire every 90 days. Because the PBA credentials aren't integrated with AD that means you have a nightmare password management situation. Utimaco does provide a server to try to alleviate this problem, but it's still a major management pain.

It's true that by default the PBA bypass key gets stored obfuscated but in plain text on the hard drive if you bypass PBA. But if you have a modern computer with a trusted platform module (TPM) you can configure SafeGuard Easy to store the key there. You can also bind the hard drive to that particular TPM chip so that it is unaccessible if attached to another computer.http://americas.utimaco.com/safeguard_easy/manual_v430/1-245.html [utimaco.com]

PGP is a hilarious company, these days. My company was going to do some consulting work for them, and they announced that we could not work with them unless we complied with their security "policy." We thought it would be no problem--our security is some of the best in the industry.We read their "policy" and started laughing, however. It isn't a policy so much as a standard, which explicitly requires all computers run PGP Whole Disk Encryption. No other form of data protection is acceptable.

So clearly the encryption system records the running password somewhere outside the encrypted volume if the auto-reboot is selected. One would assume that, upon reboot, the password gets overwritten.We are constantly told that data that's only overwritten once on a magnetic drive is recoverable. So, if one could figure out which section of the drive gets the password written to it (an easy enough exercise given that the boot code that mounts the encrypted volume is in a fixed location and largely static)

If you RTFA you'd see this feature is needed for anyone who remotely-boots their encrypted drive. The feature is not a backdoor - it has to be enabled by someone with cryptographic access to the drive, and it only works once per setting - reboot, and it's disabled. The only way this could be a security issue is if it's enabled, and before the drive boots up again, the drive is stolen. Features like this are needed, as without them, the drive is useless for remote management, and people won't use encryption, which is obviously far more insecure than having this feature and using it correctly.

Yeah, it's a potentially dangerous feature - but some customers want it anyway, and at least PGP implemented it in a way that's less dangerous than it could have been. I'd have preferred to see some additional hardware involved, e.g. require input from a USB dongle or successful DHCP hit or something in addition to the disk-stored info, but it's hard to get that to work portably and reliably.

This backdoor took a bit of time to figure out. The simple fact is that if I buy a product, I expect it it work correctly, in particular, I expect it to work as advertised. PGP says that your data is encrypted and safe. Obviously, it is not.

well, read the other replies. apparantly it is a feature you have to enable yourself, which is useful in some cases, and is no security danger (unless you do stupid things with it).
the entire story seems to be a non-issue... it's no real backdoor, just one you can enable for certain uses.

I RTFA and the comments, and I realize that this constitutes a glaring security hole: even the owner of the data can gain access to it! For a REALLY secure system, I would expect to be barred access to any actual data I put in.

With that understanding, I am developing a new data security system using heretofore unrealized technology, and plan to bring it to market in the near future: look for products from BHS in stores during the month of No-never.

There isn't a backdoor. If you encrypt your hard drive, then lose it, nobody can read it.

If on the other hand, if you've encrypted your boot disk, and you want to remotely reboot your machine, you're going to need someway to feed the password to it before it can bring up the OS (and the networking layer).

This feature allows you to store a password for 1 time use. Then you reboot the machine, and when it comes up, it reads the password and erases it.

It's a useful feature. Doesn't effect you if you don't use it. Even if you do use it, you'd have to set the password then forget to reboot for it to be a problem.

Basically this whole story is a non-issue. The moderation on the grandparent is a reflection of his failure to reason through this.

Yes, great point. Also, how do we know it doesn't also print out the password if there's a printer atttached. Or, failing a printer being attached, how do we know it doesn't search the network for printers, print it out, email it to everyone in your contact list and altering your DNA through radio waves so that your children's first words will be the passphrase.

RTFA or at least TFComments (though that might be difficult in your rush to be first post). As many have pointed out, to turn on the feature, you have to already get past the encryption. It's not a "backdoor" in any sense. Someone who doesn't already know the passphrase can't use it to get access to the drive. Plus, this feature is turned off by default so the user has to actively enable it. You enter the passphrase, reboot the computer and on THAT boot, it doesn't ask you for a passphrase. Next reboot it does.

This actually DOES sound like a very good feature and I would hope other products have it, too. Wish the editors would RTFA, too...

Have to admit, after RTFA, that I'm less inclined to worry about it.Does anyone happen to know if this applies to the non-commercial versions, like 6.02i, or 6.5 user compiled? or is it only the commercial releases?

I can't believe you made such a long post about a moot point. If you social engineer someone to give you the passphrase, you don't even need to use this feature. The passphrase is the whole thing encrypting the disk. If you have the passphrase, you ALREADY GOT THE ACCESS. You don't need any fancy reboot tricks.

And what is the problem with that? If you have access to the machine and can unobserved alter the machine to boot different code, you could also trick users into entering their passphrase in a fake password screen. Whole Disk encryption is normally used to protect the data when the computer/drive is stolen and not against an attacker who has !UNOBSERVED! unlimited physical access to the drive in question.

Either you still don't understand the feature, or you are willfully misinterpreting it. Once again, you must know the passphrase in order to unlock the data on the disk. If you know the passphrase, you already have access to the data on the disk, with or without this feature. Hence it is NOT a backdoor. A backdoor would mean you didn't need to know the passphrase. Knowing the passphrase is the FRONT door.

I unplug your network cable and remove your hard drive,
Plug your harddrive into my system..Get the data and recheck,
the pre-boot authentication. Put the hard drive back into your
computer. Turn it on. it continues the reboot process..
Except for the extra delay.....you never know I just got your data.

You forgot the part where you descend form the ceiling suspended by a wire harness and hang upside down while typing into the console.

The GPG program that you download doesn't do full-disk encryption; it's pretty purely a file/stream encryption program. I suppose you could use it for disk encryption, by streaming data through it on its way to and from a device, but that's not how it's normally used.

There is/was a program around that used GPG to do FDE, called GPGDisk. I'm not sure whether it used your installed copy of GPG to do the heavy lifting, or if it just included the same code, or worked using the same algorithms but had its own totally separate crypto engine. It was reasonably popular for a while, but I think a lot of people who were using it have now switched to TrueCrypt.

However, GPGDisk did offer some unique features, like the ability to encrypt a disk using a GPG key, and some fairly fine-grained access controls that you could set up for multiple users (IIRC). Every once in a while someone will mention it on the comments on Bruce Schneier's blog, so apparently it's still getting some use. But it doesn't offer some of the neater features that TrueCrypt does, like plausible deniability or containers-in-containers, I don't believe.

What, only one referance to Phil Zimmermann? [philzimmermann.com] One of the main reasons Philip Zimmermann created Pretty Good Privacy in 1991 was because of the US government wanting to install backdoors in encryption software.

How much do you want to bet that "unnamed customers" are synonymous with "various federal and state police agencies, DOD, and NSA"?

From TFA, those "unnamed customers" are companies that have the need to remotely reboot their machines. This feature is NOT a backdoor - it merely allows someone WHO ALREADY HAS WRITE ACCESS TO THE ENCRYPED DRIVE (i.e. someone who has already given the passphrase) to grant a one-time certificate that permits a reboot without asking for the passphrase again. The major risk here is that someone will rob your store during the 60 seconds it takes to reboot over the phone, a possible, but highly unlikely scenario.

They shall now be treated as DISHONEST. Lets hope their unnamed big customer can afford to keep PGP in business as they lost mine. They can pay for my business PGP lost. Lets hope they are actually big enough.

From everything that's been said, it seems that the worst that PGP can be accused of is not making clear the security implications of a feature that should have been better documented. And that's arguably quite bad- the worst case is a clueless user turning it on and feeling more protected than they should.

However, the feature isn't enabled by default. It requires cryptographic access *and* knowledge of its existence to turn it on. And if you already have cryptographic access, then the whole issue is academic.

You pompously declaring it "DISHONEST" in capital letters smacks of the typical random-geek's kneejerk first post on a messageboard thread. And FWIW, I don't know how much your oh-so-important business with them is worth anyway; I suspect that the other client probably *was* worth more. (Of course, it's quite plausible that the views of *many* smaller clients who disliked the feature would be a serious counterweight. However, if you're going to act like your *individual* view carries so much weight, expect scepticism).

I don't see how this is a backdoor either. Its intended for a remote admin to be able to reboot a secure machine, knowing that there is a slight risk of attack by a fairly sophisticated attacker in the time it takes from when the machine reboots to when it starts up and Bootguard gets the passphrase, zeroes it out on the hard disk, and continues the boot process.This is needed functionality for a number of places, for example domain controllers at remote sites, which should have everything protected from b

It's a well-protected backdoor - only works if you enable it, and you can only enable it if you're authorized (and being undocumented makes it less likely you'll do that:-), so it's not like an always-unlocked backdoor that only your IT staff and ex-employees and the NSA know about, unlike some products I've seen over the years. But it does still mean that you can boot the system once without typing in the regular password, which means it's still dangerous.

As others have said, some parts of the U.S. government has become completely lawless. The government is requiring access and requiring that access be kept secret. The Bush administration has become a dictatorship. I think U.S. citizens should demand impeachment and that Cheney and the Decider be tried for treason. Why should the really big criminals be allowed to break the law?

I keep hearing that the 2nd amendment would help in this situation but I haven't noticed any militias storming the local branch of

I keep hearing that the 2nd amendment would help in this situation but I haven't noticed any militias storming the local branch of the federal administration. I think the best way to protect Democracy is probably through self-motivated knowledge seeking and political activism on how things work instead of guns, but who can argue with a MP5.

Well, our second amendment rights have been eroded... There's no real way for the people to go to a store and buy shotguns to take on the government when they have pl

The problem with TrueCrypt, and I use it, is that the is no key recovery or remote management faculty. IOW, if you forget the passphrase (and/or lose the keyfile) your data is gone forever. This is considered unacceptable in many organizations, which is why they have this key recovery faculty.It's still a crappy implementation. What they needed is a more sophisticated system that allows multiple keys and access levels. i.e. When a user creates a volume it also tags that volume with a "master key" that the I

IT doesn't need user passwords, just the ability to reset. Bob looses his password, you reset it to "BobRememberYourPasswordNextTime" and force them to change it on next login.Too, IT shouldn't need special access passwords. Each IT person should have their own account with "IT Special Access". Then when that person leaves, that account is disabled/removed. Again, you don't need to change anything. Only a few, Manager/CTO and maybe VP, need root passwords. And when they leave, those passwords can be updated

As others have said, some parts of the U.S. government has become completely lawless.

I have it on Good Word(tm) that there are comms boxes out there (think routers and things like that) have have '2 sets of books', as it were. two sets of mgmt commands and 'user manuals'. one for the normal customers and one for 'special' customers.

I can't add more to this (I actually don't know more than this, thankfully!) but I fully believe it to be true. (I've been in the data comm world for almost 20 yrs now, if th

Okay, so let me explain why I'm telling you the software doesn't work like this. Here's the key thing to remember: the pre-boot lockout is not the thing protecting data on the disk.Here's a scenario:1) Install PGP and encrypt the drive.2) Reboot3) Turn on the bypass for the next reboot4) Shutdown5) Remove the drive and stick it (or copy of the drive) in another computer as a secondary drive6) Try to access the drive

From your posts, it appears you think you'll see all the files. The simple fact is that you