"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."I am curious, Jon, if you could be forthcoming with details as to why this feature was not documented. I would hate to pull out the overused "security by obscurity" banner. Was it intentional (and if so, why?) or was it simply oversight?
"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."Of course you are correct on that detail. I was aware of the one time use parameter, but did unintentionally neglect its inclusion.
But we are both working under the assumption that we are using the PGP issued boot guard binary to unlock and boot the drive. If (and please correct me if I am wrong, Jon), however, a third party were to reverse engineer the process the PGP boot guard works to build their own (say to boot from media such as a CD or DVD), this bypass, which is simply another key (protected by a passphrase of hexadecimal value x01) to decrypt the Volume Master Key could remain on disk. The users (and administrators) have to trust that the PGP binary will leave the function calls (the ones that remove the bypass from disk) intact.
Essentially, this is an example of a trusted client, which (without going too off subject here) is not that much different from why client-based NAC implementations fail [Because if you cannot trust a machine trying to connect to your network, how can you trust the output of some software running on that machine as an attempt to interrogate its trustworthiness?]. There is no trusted path to validate that the binary image that is called to both add the bypass and to boot the device, removing the bypass, is unchanged from its distribution from its maker, PGP Corp. Administrators who use this feature are putting their trust (or perhaps their faith) in the hope that: 1) the binary as identified by file path has not (and will not be) changed, and 2) there is no interest in the "insecurity research" community to create a method to maliciously alter those binaries.
Basically, (and I apologize, Jon, if this is a simplistic diagram) the image below is a disk that is protected by PGP Whole Disk. The User Access Keys, Boot Guard (software that unlocks the disk), and Volume Master Key may be out of order (probably are-- after I quickly made the diagram I realize the Boot Guard is likely to be first), but the ideas are the same regardless. User Access Keys unlock the Volume Master Key, and users unlock their corresponding access key by their passphrase (or various physical token). If a bypass exists, it is added to the User Access Keys. The Boot Guard has a function call for using the bypass (by attempting to decrypt the bypass user01 access key with a passphrase of value x01) and a function call to remove the bypass from the user access keys on disk.
What if the PGP Boot Guard's function for removing the keys was removed (e.g. by a Trojan/malicious boot guard or boot media)? What controls would then obligate that the bypass key would be removed? If the PGPwde.exe --add-bypass command checks the integrity of the Boot Guard to ensure the RemoveBypass() (or equivalent) function call is intact, it certainly isn't documented that it does so. Regardless of whether it checks at the instant it creates the bypass, there still is no guarantee from that point in time that the Boot Guard won't be manipulated or that alternative boot media won't leave the bypass intact.
Jon went on to say:
"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.Exactly. This is the theme of which I would like to take hold, more so than the hype of a problem in a widely-adopted product. The question at hand may be: "Is whole disk encryption an example of bolt-on security that doesn't truly solve the problem of confidentiality and integrity of data at distributed locations?"
"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."
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?
"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.True. It's not a "backdoor" in the sense of 3 letter agencies' wiretapping via a mathematical-cryptographic hole in the algorithm used for either session key generation or actual data encryption, but how can a PGP WDE customer truly disable this "bypass" feature? As long as the function call to attempt the bypass exists in the boot guard's code, then the feature is "enabled", from my point of view. It may go unused, but it may also be maliciously used in the context of a sophisticated attack to steal a device with higher valued data contained within it:
"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."
- Trojan Horse prompts user for passphrase (remember, PGP WDE synchronizes with Windows passwords for users, so there are plenty of opportunities to make a semi-realistic user authentication dialog).
- Trojan Horse adds bypass by unlocking the master volume key with the user's passphrase.
- [Optional] Trojan Horse maliciously alters boot guard to disable the RemBypass() feature. [NOTE: If this were to happen, it would be a permanent bypass, not a one-time-use bypass. Will PGP WDE customers have to rely on their users to notice that their installation of Windows boots without the Boot Guard prompting them? Previous experience should tell us that users will either: A) not notice, or B) not complain.]
- Laptop is stolen.
- Enterprise IT shop sends notification to users regarding upcoming maintenance (OS/Application patch) which will include a mandatory/automated reboot.
- Malicious insider powers off computer when BIOS screen appears, keeping disk in "bypass" state.
- Malicious insider images the drive or steals the device entirely.
"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."Jon, I would be more content with this feature in your product, if:
- The feature was documented clearly, including a security warning covering the risks of its use/presence in such a way that administrators must see it.
- The feature could be permanently disabled-- not just ignored or left seemingly unused.
- The intended use of the feature did not require the creation of a passphrase with cryptographic access to the Volume Master Key.
- The intended use of the feature did not require the distribution of plain text scripts with an embedded passphrase to N clients each and every time that feature is needed.