Response to Jon Callas - continued #2

This is the continuation of my response to Jon Callas regarding the PGP Whole Disk Encryption bypass.

I can appreciate the problems inherent in managing distributed computers while still protecting the confidentiality and integrity of the data contained within them. I understand there is often the need to do maintenance on machines in-mass.

However, what I do not understand is the classification of machines that would have both physical access control needs (hence the PGP Whole Disk Encryption) and the immediate availability without a human nearby. Here's the rough categories/scenarios I can come up with:

1. Mobile Computers (i.e. laptops)
2. Less-Mobile Desktops/Workstations
3. Servers

It is very obvious why an enterprise IT shop would turn to a product like PGP WDE for laptops. We have all seen the stolen laptop cases in the news. What I do not understand is where the applicability of a maintenance bypass of the PGP WDE encryption would come into play here. Laptops, being the very nature of something that can grow legs and walk away, should ALWAYS have maintenance reboots send the machines into the pre-boot authentication state. PERIOD. Because if you don't, the device is very likely to end up in the wrong hands. And like I predicted before, we will likely see a case in the news of a stolen laptop that had encryption software deployed on it-- yet it still resulted in a data leakage. Having a feature like this bypass turned on for this category of systems is a sure-fire way to make headlines.

I will temporarily skip over #2 (workstations) for #3 servers.

I understand the reasoning behind protecting servers' drives from data leakage via whole disk encryption software. I also understand that large enterprises have farms of servers and rarely manage individual servers, preferring to manage multiple servers at once through a single admin interface. However, a smart enterprise is going to use layers of security, starting at physical security controls (the data center: locked doors, raised floors, controlled environmentals, etc.), moving through network layers (firewalls, IDS), up to the system and application layers. Besides going through the performance trade-offs, and enterprise has to decide if the complexity of WDE is worth the trade-off of the confidentiality/integrity it might provide.

In this situation, I personally prefer the way TPMs (Trusted Platform Modules) have been used in WDE-like implementations (NOTE: PGP Corp does not currently support the use of TPMs with its WDE product). TPMs, in theory (but perhaps not in all implementations), have the ability to create a Trusted Path for the boot process, roughly in these steps:

1. TPM takes a cryptographic hash of the software used in the boot process (BIOS, bootstrap, kernel, etc.).
2. TPM compares hash output of components to known good hash output of the same components [remember that the TPM is tamper resistant-- any attempts to modify the hash outputs will render the device unusable].
1. If the hash outputs match, boot process continues.
2. If the hash outputs do not match, the boot process halts.
3. The boot strap (i.e. boot guard) can then rely upon the TPM to store the Master Volume Key, releasing it to the known-good (and therefore trustworthy) volume encryption/decryption driver either automatically or after additional authentication processes are completed successfully.

The caveat is that a stolen device can still boot the OS, but at that point the confidentiality/integrity of the system is no longer the responsibility of a full disk encryption product, but rather on the OS/Applications/Listening Services. However, on the plus side, there are no passphrases going around in the clear-- in plaintext scripts pushed down by administrative tools to implement a one-time reboot with a pre-boot authentication bypass. If the system's Trusted Path along the initial hardware and software phases can be established, it will reboot without interaction.

A major plus with TPMs over PGP's implemented bypass is that its use truly is a customer opt-in choice. Whereas the PGP Boot Guard (today) always checks for the existence of the bypass user access key and supplies it a generic/static x01 passphrase whether a customer knows or wants this feature to work on their systems or not, the TPM is clearly designed and documented to perform that function. There's no hidden trick; it's a deliberate act on behalf of the customer. Another huge plus is that there is no API or command line tool with which to interact in order to establish the automated boot, so there are less opportunities to accidentally disclose a critical boot volume passphrase (i.e. no plaintext scripts).

Now, to return to the issue of workstations ...

I have seen enterprise IT organizations treat workstations as servers, by installing production-dependent servers upon desktop-class hardware and expecting SLAs a server in a well-protected data center (or at least a locked closet) could provide. Those people are making mistakes--not just security mistakes-- but IT management mistakes. If something is that critical, it should be well-supported and funded, being provided the layers of control it should have. And if those are PGP's customers, I would still contend they should pursue the TPM route as described above for servers.

For workstations that are sitting (semi-) permanently on employees' desks, what are the real objections to having users come into work some morning only to see the PGP Boot Guard authentication dialog box waiting for them? If the objection is that the users are not trusted to have a User Access Key of their own (think: kiosks), then again, the TPM route is probably best, so there is less of a key management issue. If the objection is that it simply isn't convenient ... well ... anyone who understands security truly understands how dangerous playing into that line of thinking can be. Most organizations that would use the PGPwde.exe --add-bypass command in-mass will be using a shared administrative account (some call these "service accounts"), which means yet-another-default-password that has to be managed, reset when staff leave, etc. For most organizations, that is a nightmare. To top that off, remote-management tools like Microsoft's SMS often place scripts and installers in temp space, which is rife with problems cleaning up after-the-fact. Sure, if a file is deleted by the OS (using the "tombstoning" technique, not over-writing) on a fully-encrypted volume there is no access to the file when the OS is not running, but online recovery of deleted files within a file system can occur, even if the subsystem is reading/writing blocks of encrypted data from the disk. It's still semi-visible to the OS, which means a passphrase in a script could leak.

So to recap: use PGP WDE with pre-boot authentication under the expectation that users will always have a pre-boot authentication experience, even after maintenance reboots. Where that is not feasible, select a WDE solution that uses TPMs for integrity checking and secure storage of keys.

...

I would bet that some *magic* with TPMs would be possible to create some hybrid best-of-both-worlds scenario. Since TPMs can securely store hashes for matching online hash output with a known good historical state, it may be feasible to create a scenario where the default action is to salt+hash the user's passphrase and compare to hashes known only be the TPM, but follow-up with a one-time-bypass scenario where the TPM is told to check another source for the hash output comparison (i.e. the environmentals of the system, the BIOS, the serial number, the boot loader, etc., all hashed together, similar to some current TPM-WDE implementations today do always). That might make it possible to have pre-boot authentication as the default with a truly trustworthy one-time-bypass in the case of remote/automated maintenance.

And, because I could not leave this important point out, like I said previously:

"Please keep in mind that encrypted data is just data protected under time-lock; either the time required to crack the encryption key starting today on current hardware, or the time it takes to wait until current computing hardware can trivially crack the encryption key. And of course, keep in mind that most end-users of a disk encryption software will be setting a password that they can remember and type readily with little slow-down at boot. Even the strongest passwords could be shoulder-surfed and if the motivation is the data, encryption software likely won't be victorious in the end ... but it does make for a good security blanket (sensation of comfort). Instead try to remember that a wonderful and viable alternative is to not carry sensitive data on a mobile device at all! There are layers of security that exist to protect data that is centrally stored on servers in a data center. Those layers tend to not travel well with mobile devices."