"%programfiles%\PGP Corporation\PGP Desktop\PGPwde.exe" --add-bypass --passphrase [passphrase here]
How trivial would it be for a Trojan to pretend to be an authentication dialog box and apply the user-supplied password as the drive unlocking passphrase!
Imagine this scenario:- Enterprise IT ships out a maintenance patch requiring a reboot.
- Scripted installation also uses PGP WDE bypass to setup unattended reboot.
- Script preps the system for shutdown, but the laptop is stolen.
PGP Corporation should also be in the doghouse for keeping this "feature" so quiet. For example, there is nothing in the current release that documents this feature. Even the pgpwde.exe help option delivers nothing to indicate its existence:
C:\"%programfiles%\PGP Corporation\PGP Desktop\PGPwde.exe" --help
PGP WDE command line tool.
Commands:
Generic:
-h --help this help message
--version show version information
Disk enumeration:
--enum enumerate all fixed and removable disks
--disk-info display information about a specified disk
User management:
--add-user add a user to specified disk
--remove-user remove a user from specified disk
--list-user list all users from specified disk or user file
--verify-user verify a user on disk with specified passphrase
Disk management:
--disk-status display encryption status of specified disk
--instrument instrument a disk with Bootguard
--uninstrument remove Bootguard instrumentation from specified disk
Disk operation:
--decrypt remove whole disk encryption from specified disk
--stop stop an active encryption or encryption removal process
--wipe-disk wipe the content of specified disk
--recover try to recover specified damaged disk
Options:
Boolean:
--fast enable fast mode encryption
--safe enable safe mode encryption
Integer:
--disk specify physical disk by number
--block-size optional specify encryption block size
Strings:
--public-keyring public keyring file
--private-keyring private keyring file
-i --input input file name
-o --output output file name
--passphrase passphrase for disk user or private PGP key
--ap --admin-passphrase admin symmetric passphrase
--rp --recovery-token recovery passphrase
--asc armored key file in .asc format
--admin-asc armored admin key file
-u --user user name
There has to be a better solution for this problem.
UPDATED: You can remove any bypass passwords using the "--remove-bypass" switch and you can check to see if bypass are setup using the "--check-bypass" switch. For example:
C:\>"%programfiles%\PGP Corporation\PGP Desktop\PGPwde.exe" --remove-bypass
Failed to locate user: ☺user
UPDATE 2: Jon Callas, CTO/CSO of PGP Corp, allegedly (because there is no non-repudiation in the comment) left a comment regarding this post. My response is here.
UPDATE 3: Here is some feedback for the slashdot thread. Here is a continuation of my response to Jon Callas.
UPDATE 4: If you're coming here from Jon Callas' CTO Corner article, then take a quick trip here to see my response.
32 comments:
You bring up an interesting issue with the automated reboot feature, but you don't have the details right. I can't fault you for that, as we haven't documented on the web site. Full product documentation should be coming in the next release.
The major inaccuracy you have is that the passphrase bypass operates only once. After the system boots, the bypass is reset and has to be enabled again. Note that to enable it, you must have cryptographic access to the volume. You cannot enable it on a bare running disk.
We are not the only manufacturer to have such a feature -- all the major people do, because our customers require it of us. A number of other disk encryption vendors call this a "wake on lan" feature, which we believe to be misleading. 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.
The scenario you describe is more or less the intended one, and you identify the risk inherent in the feature. If someone enables the bypass and the volume is immediately stolen, then the volume is open. However, this window is usually very small. The people who use it understand the risk.
You do not note, however, that the existence of this feature does not affect anyone who does not use it. It is not a back door, in the sense that cryptographers normally use the word.
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.
You say, "There has to be a better solution for this problem." Please let me know when you have it. I can come up with alternate solutions, but they all boil down to an authorized user granting a credential to the boot driver allowing the boot driver to get to the volume key. We believe that our solution, which only allows a single reboot to be a good compromise. It doesn't endanger people who don't use the feature, but it allows people to remotely administer their own systems.
Regards,
Jon Callas
CTO and CSO, PGP Corporation
This is a necessary feature, IMHO. Many of my clients request this functionality when performing installs. Also, I was made aware of this from backline support a while ago, as many PSSE's I know were also informed.
"Disclosure"?
Seems a nice way to get top on /. or digg though...
A linux specific solution would be to add some code to early shutdown to pass the passphrase to the reboot process, combined with a change to the reboot logic to load the MBR and pass the passphrase to it.
A check over various loaders indicates that the passphrase can be written to a region in the MBR after loading and before executing where the initrd can pick it up again (/proc/mem)
Assuming the bypass key is written to the disk before rebooting, what steps are taken to ensure that the bypass key is securely overwritten when the system comes back up? How does the software deal with disks that perform marginal sector relocation, erase wear leveling (for the newer flash base disks) and similar tricks which may cause the original physical block containing the key to survive even when the software overwrites the logical block?
A bypass means that the feds can also get to the data just as easy as the admins even if they don't talk to each other. The feds get it from the software company i.e. PGP etc.
Anonymous said...
"A bypass means that the feds can also get to the data just as easy as the admins even if they don't talk to each other. The feds get it from the software company i.e. PGP etc."
Only if you're stupid enough to let the feds pick your passphrases for you. ;-)
im glad you're on the lookout for bugs in this software, but this happens to not be one... You basically say that if the passphrase is phished, then it is vulnerable. Well if the password is phished by a trojan it could also be reported back to the owner of the trojan and the encryption doesnt even need to be bypassed! In order for a disk encryption to be vulnerable I want to see the data read from the disk without the user turning it off before hand and without tricking the user. If i give you a disk encrypted with this software, can you read the data or even weaken the encryption to the point where other standard attacks would be a viable method of attack? If the answer is no you have not found a backdoor / vulnerability.
-krzee
The lack of documenting seems to be the most concerning. Why make such a blunder that can only fuel conspiracies and doubt on the intention of the product?
Actually, whole disk encryption was abandoned by a competitor, Credant Technologies, for just this reason. Yet the industry has preferred "whole disk encryption" because it sounds more secure. In the case of good cryptography, access to the OS makes no difference: It can't be decrypted without the password. That's how one defines 'real encryption.'
@Brian
The passphrase is not stored on disk in the pre-boot (unencrypted) portion of disk. That was my first response as well when I heard about this feature.
Instead what happens is that a new user access key is created for a temp/bypass user with a passphrase of value hexadecimal x01. At each boot, the PGP Boot Guard searches for the existence of that bypass user key (which has cryptographic access to the Volume Master Key) to unlock the bypass user access key with that static passphrase (ahem, "flag"), which in turn unlocks the Volume Master Key. What we have to trust, however, is that the PGP Boot Guard will remove that temp/bypass user's access key immediately after unlocking the disk and starting the rest of the boot process. Look here for more details.
@krzee
True enough. If a password/passphrase is phished there are other problems. The real issue I'm trying to highlight is:
- The feature isn't documented and it's dangerous.
- There are opportunities for drives to be stolen in a vulnerable state.
- There is no integrity checking on the PGP Boot Guard (or the integrity checking is documented even less than this feature was).
For more, read here.
This isn't a back door. If you are using this feature, you should understand the risks involved. However the software should ensure any copies of keys written to unencrypted portions of the disk are overwritten at least to DoD standards when it is done using them.
The issue with all of this stuff is not only protection but satisfying the new regulatory environment where a company has to prove the state of a drive when lost.
This feature is fine but there must be a non reputible transaction log made by either the admin locally or the server that a drive was put into that state and then the state was cleared. Otherwise there is resonable doubt that the machine might have been put into this state by a local user with access. Proving this type of stuff without the machine present is what invalidates any solution for meeting the Legal test. In general, if there is a way that a machines data protection can be altered offline with out a server record then there must be record of everyone who could have altered the machine with time stamp and second party signoff. When you lose 800,000 records "trust me no one touched it" is not going to cut it. This is an area where hardware will have a hugh advantage.
steven
> - The feature isn't documented
yes, but I kind of get the point of the reasoning if even you think its dangerous and that is _after_ the explanation.
> and it's dangerous.
no it's not.
If you put a postit with your passphrase on your monitor that's also dangerous, but you can hardly blame the program for the stupedity of the user/admin
> - There are opportunities for drives to be stolen in a vulnerable state.
only if the admin is stuped!
Why would you set the bypass if you don't need access to the PC after a reboot - just shut down and let the user enter the PW at the next start.
If you need access after a reboot there is no problem, since it only works once.
I don't know if you even can just shutdown if the bypass is set, but to disable all other options beside reboot would be a way to make it impossible even for a stuped admin to leave the machine vunerable (this might allready be implemented - could anybody comment if it is or not?)
Steven,
You bring up an excellent point regarding the non-repudiation of using the bypass feature in terms of regulations & compliance. Thanks!
Anonymous said: "If you put a postit with your passphrase on your monitor that's also dangerous, but you can hardly blame the program for the stupedity (sic) of the user/admin"
Yes, but if it's possible to create technical solutions that encourage the human element to behave better, then we should do so. That's what this is all about. I discuss that more here.
Evanh said: "The lack of documenting seems to be the most concerning. Why make such a blunder that can only fuel conspiracies and doubt on the intention of the product?"
Exactly my point.
You might want to do some research on other products in the whole disk encryption market. Most of the larger enterprise vendors support this or a wake on lan mode (Utimaco) to allow for unattended reboots during patching. Yes it boots up to the OS login in this mode, but you are left without the ability to modify files on the system to get into the box. So no modifying the sam, changing binaries to get in or the easy methods to get in when you have physical access. It would be nice if you could demonstrate a way to actually compromise the windows host when it's in this mode (or did you not try that?)
In what version number of PGP Desktop was this "feature" introduced? Does anyone know? Was it there from 9.0 or introduced later? Also is it available on all license types (Professional for example) or only on Enterprise?
"How trivial would it be for a Trojan to pretend to be an authentication dialog box and apply the user-supplied password as the drive unlocking passphrase!"
If the machine is infected with a trojan of that sort, your data is no longer secure anyway - why would the hacker bother taking the extra risk of physically stealing such a machine when they can download the data remotely at their leisure anyway?
I think I may have a better solution, let's offer it up for discussion.
If I understand correctly, when you're remotely logged in to the machine you can set the next boot to not ask for a passphrase. Instead, why not set boot guard to query a remote IP address for its passphrase on the next boot? Preferably by using encrypted communications with a PGP-provided program at the other end. So maybe you have a very bored guy sitting typing passphrases while a remote script executes on a bunch of machines, but what big company doesn't have a couple of disposable trainees lying on a shelf somewhere? :)
That way the machine will only boot if given the passphrase. Period. The danger would then be if someone were dumb enough to automate providing the passphrase somehow. But the attacker would still have the ptoblem of getting the flag set in the first place, so you're no worse off than you are now.
Am I missing anything?
Shane
As John mentioned in his artical (and yes, I have met the man, he is very genuine, and is as close to a saint as anyone in the corporate world can get, and no I do not work for PGP) this is a needed INTENTIONAL backdoor, that due to the expirience that all of the employees, programmers, and management of PGP have, has been installed because many 'whole disk encryption' users work with thousands of seats, and a remote administrator.
I can not fault you for attempting to boost your hits on your blog, HOWEVER, as a future piece of advice - if you can't reasearch it, keep your mouth shut, or call the company that you intend to 'expose' to verify the issue that you are reporting on. This is called journalistic integrity - something that you, as a blogger can be held accountable for, despite your obvious lack of formal education in the field.
Re: "PGP Whole Disk Encryption - Barely Acknowledged Intentional Backdoor" Post
For the facts regarding the PGP(R) Whole Disk Encryption (WDE) Authenticated Bypass feature please visit
http://www.pgp.com/wde_bypass_feature.html
Quick Summary - No "backdoors". Fully documented. Documentation available.
Regards,
John Dasher
Director, Product Management
PGP Corporation
Hi Melissa,
Thanks for sharing your thoughts.
I agree that Jon Callas is very unlikely to be hiding anything in the products or otherwse. If there's a fault here, it's not ignorance or malice, it's likely just neglect and apathy.
I do hope you will read on, so that you can see your first impression of me is incorrect. ;)
Hi, John Dasher.
Thanks for posting. I added another entry with a link back to the page. I appreciate your positive attitude both in your comment here and in your PR link.
Hi nice blog i like it.
Keep it up
Awsome post. I find the info. i am searching for.
Keep it up.
thanks for sharing the information about Encryption. I appariciating for your effort
I´m using discryptor.net to encrypt my data. It is userfriendly and really fast.
Thanks dude !
I got the info in this blog what i am looking for... :-)
Thanks for the encryption details.
Cool blog :-)
I think the post has accomplished its goal - PGP Corp has now publicy posted the information that had previously been unavailable to the public.
Kudos to PGP Corp for stepping up.
Kudos to the blog for helping facilitate that.
Post a Comment