Thursday, October 4, 2007

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."

6 comments:

Anonymous said...

> 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.

Installing a whole bunch of appz/drivers remotely that are non "standard" in the company when some require a reboot (depending on the situation it might not be too smart/convinient/cheap to just install the stuff and wait for the user to come back and enter the PW and then check if everything actually works and if it doensn't the user just has to sit and wait ..)


> the data center: locked doors, raised floors, controlled environmentals, etc.

that doesn't keep your data save if you sell your old HDs on ebay (or the guy you hired to shred the discs does, since this is a nice way to increace his income ..)
And loosing data that was stored on an unencrypted disk is AFAIK heavily finded at least in the US

> TPMs, in theory (but perhaps not in all implementations)

yes in Theorie - with PGP you actually have the ability to check the implementation and you even could be present when they compile your individual app out of the sources you checked (if you really want to be shure ..)

> 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

the other side of this coin is: any security measure that isn't uses because it is not convenient enough is worth even less than a potential dangerous one which is used

Tim MalcomVetter said...

Anonymous said: "Installing a whole bunch of appz/drivers remotely that are non "standard" in the company when some require a reboot (depending on the situation it might not be too smart/convinient/cheap to just install the stuff and wait for the user to come back and enter the PW and then check if everything actually works and if it doensn't the user just has to sit and wait ..)" (sic)

I would suggest that any IT shop that has that problems has general IT management problems, or is an extremely small or understaffed shop. Proper change & configuration management should result in a predictable & repeatable installation process-- which would yield high assurance of success-- and allow the admins to simply wait on the users to reboot the system (pre-boot authentication and all), log in, and use the application.

"that doesn't keep your data save if you sell your old HDs on ebay (or the guy you hired to shred the discs does, since this is a nice way to increace his income ..) And loosing data that was stored on an unencrypted disk is AFAIK heavily finded at least in the US" (sic)

For the same reason I commented at the bottom of this post, the use of encryption as an access control system is simply a time-sensitive lock; it is not (and nobody who knows what they are talking about will ever tell you otherwise) a perfect/permanent access control solution on its own, for a number of reasons (human rememberable passphrases are less complicated than ones computers can guess, Moore's Law as an effect on cryptography, etc.).

And if the guy you hired to do a job isn't doing the job your hired him to do ... well, that sounds like you have poor management in general, yet again. Where are the auditable controls? Any enterprise with any decent governance and controls in general will be able to overcome the ability to get employee who is supposed to do X to actually do X with a high level of reliability. It also sounds like you have some conflict-of-interest problems if you allow that employee to keep track (or sell) inventory.

"yes in Theorie - with PGP you actually have the ability to check the implementation and you even could be present when they compile your individual app out of the sources you checked (if you really want to be shure ..)"

Two things: 1) it doesn't sound like your knowledge of TPMs is very high. I suggest reading the Trusted Computing Group's spec. 2) PGP has an open source review process and yet they still had this feature undocumented. It's not whether your source code is open or not-- it's who is reviewing the code (who is it, what are their credentials, what are their motivations to do a quality review, etc.). Many open source projects don't get reviewed (or at least not well). Open source an unrelated variable.

"the other side of this coin is: any security measure that isn't uses because it is not convenient enough is worth even less than a potential dangerous one which is used"

Absolutely true, but striking an excellent balance is all about good engineering-- designing solutions to problems, not designing solutions in search of a problem.

steven sprague said...

So let's examine an enterprise solution that has FDE done with hardware and TPM integration.
The seagate FDE drive provides for a number of interesting capabilities especially when centrally managed.

First the pre boot code is delivered from a read only memory on the drive that can be updated by an admin but never locally in an enterprise

Secondly the Encryption key is created in silicon on the drive and never leaves the chip.

Encryption is always on.
Access control is accomplished by the silicon as well. The passphrase is compared by the silicon of the seagate technology.

All managment functions can be centrally managed by ERAS servers from Wave systems Corp. In this case all drive administration is done by the server and can not be altered by anyone on the client. all drive commands are encrypted and have a session key based protocol to assure they are not replayed or sniffed.

Because the encrytpion is independent of the OS entirely the local machine can be managed without messing up the state of the FDE. A machine can be reimaged by an offline admine and it will not turn off the protection.

The TPM can be used to provide binding of the Drive to the platform so that it will only boot on a known motherboard.

Really what we need is the rest of the parts

Machine ID with TPM over IPSEC (known PC IT can request a Private key created in TPM never Leaves TPM)
NAC based measurement of alt boot record to know FDE drive is present and operational (using either TNC or NAP)
Strong user Identity to assure the user has access rights using TPM or smartcards (Keypair held in TPM used for authentication and Pin number provided by user)
Finally a server that keeps a log of what sensitive info was delivered to that know platform in a known state.

TO meet the regulations
The most important fact is that with a server only managed drive one gets a cradle to Grave log on all transactions with a drive and knowledge that no admin functions were ever done without a record. This does a good job of proving that a lost machine is secure.

Steven

Tim MalcomVetter said...

Hi Steven,

That's interesting. Thanks for sharing.

Anonymous said...

> Proper change & configuration management should result in a predictable & repeatable installation process

In theory yes, in practice those strict rules are often bent or broken (e.g. if the boss wants to test s.th. new on his machine).
So what do you do (as PGP) if you can't convice your customer to implement those strict rules because he want's those options regardles of the potential danger?

> and allow the admins to simply wait on the users to reboot the system

try convincing a highly payed manager to wait 10minutes (or longer if there are some problems) in front of his PC without being able to work properly ..

> And if the guy you hired to do a job isn't doing the job your hired him to do ... well, that sounds like you have poor management in general, yet again.

so you would do an extensive backround check on each and every employee of the company you hired to do the shredding - get real!
Yes the problem is in a poor security management, but in the real world money _is_ an issue .. (to supervise the guy who does the shredding and at best by 2 trustworthy guys costs money - and even in this situation those 3 could decide to sell the HDs on ebay and splitt the profit ..)

> any enterprise with any decent governance and controls in general will be able to overcome the ability to get employee who is supposed to do X to actually do X with a high level of reliability

everybody _could_ do that, but that process costs money and time - so often it isn't done

> and yet they still had this feature undocumented

it's undocumentet for homeusers (who don't need it) - but they give the info to the guys who actually need it.
I'm not so shure if that policy is good or bad.

> it's who is reviewing the code

so? If you are paranoid pay some guys you trust to do a review. With CS you can't do that.

> not designing solutions in search of a problem

so you think the customers of PGP (and all the other FDE-Produkts) didn't ask for such a feature as they all claim? And after implementing such a feature they _all_ decidet to not advertise their great new feature?

> The TPM can be used to provide binding of the Drive to the platform so that it will only boot on a known motherboard.

great idea if your mb gets fried

> The most important fact is that with a server only managed drive one gets

a _huge_ problem if this server goes down (disgruntled emploee) and no viable solution for notebook users or machines that are not allways online (e.g. PCs that controll measuring equipment (some ISA-Measuring boards are still around) that have to be somewhat mobile).

Plus this seems to be a nice way to increase the workload for your supportdepartment since if the bootsector changes (Virus?) your machine most likely won't start (rescue cd's for the local IT-guys to fix the OS won't work either)

Yes, you can do nice things with TPM but there are certan trade-offs in "non-standard" situations (one being that until now the chips arn't on many PC-mobos and even the notebooks without chips will still be in use for quite some time)z

Tim MalcomVetter said...

Hi anonymous,

You said: "In theory yes, in practice those strict rules are often bent or broken (e.g. if the boss wants to test s.th. new on his machine).
So what do you do (as PGP) if you can't convice your customer to implement those strict rules because he want's those options regardles of the potential danger?"

Again, if you have a manager like that, then you have a management problem. No amount of technology can correct that.

You said: "try convincing a highly payed manager to wait 10minutes (or longer if there are some problems) in front of his PC without being able to work properly .."

I have highly paid managers (as in owners of a multi-billion dollar company) who are understanding of security issues. I suspect it has a lot to do with "ownership" and lot less to do with "highly paid". If you have ownership, you'll have understanding that certain risks aren't worth it. In fact, these same owners are among the best users I have ever experienced. That doesn't mean they always "get" security, though, just that they are willing to trade off the 5 minute boot time (if you have a 10 minute boot, you have an altogether different problem).

You said: "so you would do an extensive backround check on each and every employee of the company you hired to do the shredding - get real!"

Yes. You should. It's not that expensive to do a background check, compared to responding to incidents. Also keep in mind I'm advocating auditable processes-- not just "prevention" but "detection" and "correction" as well.


You said: "everybody _could_ do that, but that process costs money and time - so often it isn't done"

I'd suggest they spend money on that before they spend money on drive encryption (or any other technology for that matter). The business processes, policies, and controls must exist PRIOR to implementing any technical controls. If you can't manage your people before technology, you won't manage your people after, either.

You said: "it's undocumentet for homeusers (who don't need it) - but they give the info to the guys who actually need it.
I'm not so shure if that policy is good or bad."

I hear you about the uncertainty. I, however, was one of the ones "who needed it" and it was not available to me (not right away-- it took kicking and screaming, I'm afraid). That's the whole point of this ...

You said: "> it's who is reviewing the code
so? If you are paranoid pay some guys you trust to do a review. With CS you can't do that."

I'll talk about this in more detail later on in a separate post.

You said: "> The TPM can be used to provide binding of the Drive to the platform so that it will only boot on a known motherboard.

great idea if your mb gets fried"

OK? Does that happen to you often? If so, you may wish to switch hardware vendors. I'm sure it would be easy to dig up some stats here, but I'm quite certain that hard drives (with all of those moving parts) are much, much more likely to die than their solid state compadres.

You said: "Plus this seems to be a nice way to increase the workload for your supportdepartment since if the bootsector changes (Virus?) your machine most likely won't start (rescue cd's for the local IT-guys to fix the OS won't work either)

"Yes, you can do nice things with TPM but there are certan trade-offs in "non-standard" situations (one being that until now the chips arn't on many PC-mobos and even the notebooks without chips will still be in use for quite some time)z"

I don't think you have an understanding of the full vision for TPMs. Yes, they can be used for storing keys for a FDE solution, but they can do much more than that. If used properly, TPMs will link components together, forming a "chain of trust" so to speak, starting at the boot sector (boot strap), through the kernel through to the OSes built-in controls. If implemented to the fullness of their vision, TPMs will prevent malware (your boot sector changing example) from getting CPU time, based on hashes (signatures) and trust action hand-offs.