There has recently been some attention to a bypass feature in PGP Corporation’s Whole Disk Encryption product line. The gist of it seems to be that it is possible for an encrypted volume to be set so that the passphrase requirement is waived (bypassing the authentication) for a single reboot.
While this comes across as concerning at first, after reading the PGP Knowledgebase Article #750, it appears that the risk is minimal. I feel that if I were a government organization, such as the CIA,NSA,FBI, DHS, etc, then I’d be worried about the types of advisories the anonymous author of securology mentions. However, most laptop thefts are by common criminals looking to make some money in a pawn shop or otherwise. I doubt there will be many if any cases of a malicious trojan that not only replaces PGPs Bootguard with a malicious one to extend the number of unauthenticated bypasses ad infinitum, but also infects machines that the attacker can get physical access to. This would require being able to reverse engineer the PGP BootGuard code that so far even the fine folks over at Guidance Software haven’t been able to do.
As part of risk management, there is a certain level of risk that has to be accepted. We can not live in a world without risks and should only worry about the ones that have a reasonable chance of occurring.
The posting lists 4 points that he/she would like addressed.
- 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.
The first point I absolutely agree with. However, it’s worth mentioning that PGP documented this feature back on July 27th of 2007. I would like to see the security warning though, as I personally had no knowledge of this feature until I went looking for it. Could PGP have backdated the document? Of course, but I’m hoping the company making my encryption solution isn’t that shady.
The second point seems academic in nature to me. There are plenty of programs used in every company of every nation that have features which would be insecure. For instance, Microsoft Active Directory can allow user accounts to have blank passwords. Shouldn’t we be satisfied that in our environment the feature is disabled? Demanding that Microsoft remove the feature from the code base simply because it would be unfavorable if enabled is ridiculous. I feel like that’s what’s being demanding of PGP here. It might be a risk a 3 Letter Agency should worry about, but certainly not your typical business.
For the third point I’m interested to see what his proposed solution is that doesn’t allow cryptographic access to the Volume Master Key. I may be misinformed but I’d think that without access to the VMK the laptop wouldn’t be able to decrypt anything and thus it would be impossible to boot.
I completely agree with this fourth point. I’ve always been against developers hard coding passwords into binaries, and especially into plain text script files. PGP should allow an alternate form of authentication that doesn’t require displaying the password. I have some thoughts on this but will likely post them later.
Overall though I’m very impressed with the writing style and depth of thought that the author behind Securology has shown. I plan to keep reading and keep learning.