Traveling Light in a Time of Digital Thievery

This sounds exciting, like intrigue for spy fiction:

When Kenneth G. Lieberthal, a China expert at the Brookings Institution, travels to that country, he follows a routine that seems straight from a spy film.

He leaves his cellphone and laptop at home and instead brings “loaner” devices, which he erases before he leaves the United States and wipes clean the minute he returns. In China, he disables Bluetooth and Wi-Fi, never lets his phone out of his sight and, in meetings, not only turns off his phone but also removes the battery, for fear his microphone could be turned on remotely. He connects to the Internet only through an encrypted, password-protected channel, and copies and pastes his password from a USB thumb drive. He never types in a password directly, because, he said, “the Chinese are very good at installing key-logging software on your laptop.”

Never types his password in directly? News for you: if are concerned about only key stroke logging, you forget what other avenues of approach a threat can take if it's kernel resident. On-screen keyboards and even one time password tokens (e.g. RSA SecurID tokens) can and have been defeated as well. If this is your level of threat, these countermeasures aren't good enough. This should not be the extent of the threat to consider:

Both China and Russia prohibit travelers from entering the country with encrypted devices unless they have government permission.

Here's better advice:

Now, United States companies, government agencies and organizations are doing the same by imposing do-not-carry rules. Representative Mike Rogers, the Michigan Republican who is chairman of the House Intelligence Committee, said its members could bring only “clean” devices to China and were forbidden from connecting to the government’s network while abroad. As for himself, he said he traveled “electronically naked.”

and probably the best advice:

McAfee, the security company, said that if any employee’s device was inspected at the Chinese border, it could never be plugged into McAfee’s network again. Ever. “We just wouldn’t take the risk,” said Simon Hunt, a vice president.

The cost of doing business in places like that is the cost of "burn devices". The hardware, data, and software on them, should all be thrown away upon exit. Don't risk powering it back on. Like a disposable camera. Send your data in before you leave in-country, and let go of any and all emotional attachment to the hardware.

If China & Russia can do this, so can any other country or, perhaps even a commercial organization, of any substantial size (yes, even the United States can and will snoop on your devices).

Earth Shattering Attacks on Disk Encryption

Trusted Platform Modules (TPMs) are were the last hope of truly secure distributed computing endpoints. The idea behind TPMs is that they are safe from physical inspection-- resistant to tampering, but we now know that to no longer be true, thanks to some clever research by Christopher Tarnovsky (pictured at left).

Every disk encryption vendor on the planet tries to sell you the impossible: a product that on one hand they claim is impervious to physical access by an adversary, and-- at the same time on the other hand-- a product they conveniently claim is no better than anything else at preventing data loss when physical access is lost to an adversary. What? Does that even make sense?

Of course it doesn't make sense. It makes dollar$.

Yeah, for the great majority of laptop thefts, probably even disk encryption isn't necessary since the thieves are just after hardware, but I never advise anyone risk that. You never know when that casual thief wants to make a quick buck off of hardware sell to a smart, conniving criminal on eBay, for instance, who just might be equipped with the knowledge and intent to steal the data off of the device.

Look at what I wrote back on October 3, 2007 when dealing with PGP Corp's failure to disclose a dangerous encryption bypass feature:

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:

1. 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).
2. Trojan Horse adds bypass by unlocking the master volume key with the user's passphrase.
3. [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.]
4. Laptop is stolen.

I just described the premise behind the Evil Maid attack years before Joanna Rutkowska coined the term.

Then read the cop-out response by Marc Briceno – Director, Product Management of PGP Corp:

No security product on the market today can protect you if the underlying computer has been compromised by malware with root level administrative privileges. That said, there exists well-understood common sense defenses against “Cold Boot,” “Stoned Boot,” “Evil Maid,” and many other attacks yet to be named and publicized.

You can read his full response, but the gist is that he never admits his product has a flawed assumption: that nobody would ever manipulate the PGP BootGuard-- the software that must remain plaintext on the encrypted drive (if wasn't plaintext, the CPU couldn't read the instructions and execute the decryption routine). At least Microsoft's BitLocker, when used with TPMs did not have this vulnerability, although we'll have to see if breaking TPMs is only accomplished by a handful of experts, like Tarnovsky. If it becomes a repeatable task that can be accomplished by inexpensive tools, then BitLocker in TPM mode will be reduced to the lower security status of PGP Whole Disk Encryption.


So which is it, vendors? Are you still letting your marketing people sell encryption products with powerpoint slides that read: "Keeps your data safe when your device is lost or stolen", while having your technical security people say "Well, about that coldboot or evil-maid attack ... well ... all bets are off when you lose physical access to the device."

It's time for vendors to get their stories straight. Stop selling your products to people who are worried about the physical theft of their devices, unless you make it very clear that there are ways around your product that a dedicated and resourceful adversary may be able to defeat-- disk encryption is only good at keeping the casual thieves out.

The Reality of Evil Maids

There have been many attacks on whole disk encryption recently:

1. Cold Boot attacks in which keys hang around in memory a lot longer than many thought, demonstrating how information flow may be more important to watch than many acknowledge.
2. Stoned Boot attacks in which a rootkit is loaded into memory as part of the booting process, tampering with system level things, like, say, whole disk encryption keys.
3. Evil Maid attacks in which Joanna Rutkowska of Invisible Things Lab suggests tinkering with the plaintext boot loader. Why is it plain text if the drive is encrypted? Because the CPU has to be able to execute it, duh. So, it's right there for tampering. Funny thing: I suggested tampering with the boot loader as a way to extract keys way back in October of 2007 when debating Jon Callas of PGP over their undocumented encryption bypass feature, so I guess that means I am the original author of the Evil Maid attack concept, huh?

About all of these attacks, Schneier recently said:

This attack exploits the same basic vulnerability as the "Cold Boot" attack from last year, and the "Stoned Boot" attack from earlier this year, and there's no real defense to this sort of thing. As soon as you give up physical control of your computer, all bets are off.

"As soon as you give up physical control of your computer, all bets are off"??? Isn't that the point of these encryption vendors (Schneier is on the technical advisory board of PGP Corp-- he maybe doesn't add that disclaimer plainly enough). Sure enough, that's the opposite of what PGP Corp claims: "Data remains secure on lost devices." Somebody better correct those sales & marketing people to update their powerpoint slides and website promotions.

To put this plainly: if you still believe that whole disk encryption software is going to keep a skilled or determined adversary out of your data, you are sadly misled. We're no longer talking about 3 letter government agencies with large sums of tax dollars to throw at the problem-- we're talking about script kiddies being able to pull this off. (We may not quite be at the point where script kiddies can do it, but we're getting very close.)

Whole Disk Encryption software will only stop a thief who is interested in the hardware from accessing your data and that thief may not even be smart enough to know how to take a hard drive out of a laptop and plug it into another computer in the first place. You had better hope that thief won't sell it on ebay to somebody who is more interested in data than hardware.

Whole Disk Encryption fails to deliver what it claims. If you want safe data, you need to keep as little of it as possible on any mobile devices that are easily lost or stolen. Don't rely on magic crypto fairy dust and don't trust anyone who spouts the odds or computation time required to compute a decryption key. It's not about the math; it's about the keys on the endpoints.

Trusted Platform Modules (TPMs) (like what Vista can be configured to use) hold out some hope, assuming that somebody cannot find a way to extract the keys out of them by spoofing a trusted bootloader. After all, a TPM is basically just a blackbox: you give it an input (a binary image of a trusted bootloader, for example) and it gives you an output (an encryption key). Since TPMs are accessible over a system bus, which is shared among all components, it seems plausible that a malicious device or even device driver could be used to either make a copy of the key as it travels back across the system bus, OR, that a malicious device could just feed it the proper input (as in not by booting the bootloader but by booting an alternative bootloader and then feeding it the correct binary image) to retrieve the output it wants.

Jon Callas Responds to Ed Felten

It's nice to not be on the top spot of Jon Callas' "CTO Corner" anymore ... although I held that spot for four and a half months. Jon Callas, the CTO of PGP Corporation, has moved on to respond to Ed Felten's memory-freezing, whole-disk-encryption-key-stealing crew at Princeton University.

Some highlights from Jon's response ...

"The basic issue is one that we have known for years."

Well, that's not very concerting, or at least it shouldn't be. If it was so well known, then why is PGP Corp just now looking to integrate with hardware and BIOS vendors to attempt to resolve this? That line, along with Jon's general theme, is that this is no big deal ... we've known about it forever ... it's just a new spin on an old trick ...

"Those of us who consider these things have known that this was at least in theory possible for some time. This team did two impressive things: they made it actually work, and they did some math to recover partially-damaged RSA and AES keys. This latter feat they did by looking at scratch variables that the encryption systems use, and back-deducing what some of the damaged bits of the keys must have been. The process is a bit like a big Sudoku game; when you play Sudoku, you deduce what is missing based on what is present."

Again, "it's no big deal", except, wait, yep, there's that really complicated math part. I do like Jon's comparison to Sudoku; it's a good analogy.

"Despite how dramatic this attack is, there is an easy fix for it."

If there really was an easy fix for it, then the whole notion of "coldboot" would be a solved problem, but that's obviously not the case. Ripping power from a running system (which Jon later goes on to say has never been the primary threat that PGP WDE was designed to overcome) does not protect the keys. Even if BIOS vendors started shipping with features that sanitize memory at boot, a quick power off optionally followed by a cool down of DRAM and finally placing the memory into a prepared system could still read the encryption keys. Yes, that requires a dedicated and trained adversary, but there are organizations with very valuable information. Jon should not be so quick to downplay the likelihood that his customers may have such an adversary, unless of course the really security conscious organizations have been skipping his company's products altogether.

"When a computer is hibernated, the contents of its memory is written to disk, and then the computer is shut down. No residual power is supplied to the RAM, so it will fade in one to two minutes, just as if you had shut it off. It doesn't matter what software you are running; if you hibernate a machine with WDE, it will be safe in a couple of moments. (Note: the Cold Boot researchers say that hibernate mode is vulnerable, and they are wrong on this nit. A truly hibernated machine is turned off, but with a copy of RAM written to disk. These machines are safe, once memory has faded.)"

Anyone else want to hear Felten's and crew's response to the hibernate "nit"?

"If there is a hard power loss, such as pulling the battery from a laptop or yanking the power cord out from a server, there's next to nothing that software alone can do. There's next to nothing that hardware can do. We could design hardware and software to do something in this case, but you probably wouldn't pay for it. I wouldn't."

I can think of several options here, all of which cannot be so expensive that when typical economies of scale (mass production and consumer demand) are applied the price becomes unreasonable. I'm not sure what this says about what's on Jon's computer, that he wouldn't be interested something as simple as a small reserve of electrical power (like in a capacitor) that can detect when main power has diminished and employs its small reserve which is just ample to perform a basic overwrite or sanitizing operation on DRAM. Such a feature could not possibly cost more than a seat of PGP WDE.

"External authentication using smart cards, tokens, TPMs, does not solve the problem. There have been reports of some people claiming that it does. It doesn't. Remember, this is very simple; there is some RAM that has a key, and that RAM needs to be cleared. Authentication doesn't clear memory. TPMs do not clear memory. The people who claim that a USB key helps at all are displaying their ignorance."

I agree that USB keys don't clear memory. What was Dr. Eric Cole of SANS thinking when he said this in the Feb 29th issue of their Newsbites?

"(Cole): The cold boot attack has a cool factor to it, but remember that
full disk encryption will protect a system only if it has a strong
password (two factor recommended) and if the system is completely turned
off. Use of a USB token stops the attack. If you turn your system
completely off (and hold on to it for more than 5 seconds) the attack
is not successful. If you do not follow either of these rules, than
full disk encryption can potentially be broken even without this
attack.]"

But a future generation of TPMs, or more specifically secure co-processors, could potentially perform all cryptographic operations in hardware, not just integrity checking of boot procedures. Whereas today's TPMs can store keys only later to hand them off to a process that will unfortunately store them in DRAM, the next generation of secure co-processors could be passed the ciphertext blocks of data for decryption, passing the plaintext version back to a WDE-like service. There will be I/O performance concerns to overcome initially, but it is feasible that a commodity-priced chip will one day solve that problem.

"There is more reason to use WDE in conjunction with either Virtual Disk or NetShare. We have always said that the primary threat model for WDE is a machine that is shut down or hibernated. We have always pointed to the added benefits of the other forms of encryption. In his recent article on mobile data protection, Bruce Schneier touts PGP Virtual Disk. The PGP Encryption Platform gives you defense in depth. Defense in depth is good because the layers of protection give more security."

Translation: buy more of their products.



Of course, there's always the solution I have offered despite common objections: one method for securing information is to not place it on disk at all. Encryption is not always the answer.

Excellent Cold Boot Step-By-Step

News.com has an excellent step-by-step complete with pictures detailing what it takes to steal the encryption keys for Apple's File Vault using the Princeton University's Cold Boot attack on whole disk encryption. Jacob Appelbaum, one of the independent security researchers involved with Ed Felten's Princeton crew, is your guide.

Felten Destroys Whole Disk Encryption

Ed Felten and company publicized some research findings today on a form of side-channel attack against whole disk encryption keys stored in DRAM.

We show that disk encryption, the standard approach to protecting sensitive data on laptops, can be defeated by relatively simple methods. We demonstrate our methods by using them to defeat three popular disk encryption products: BitLocker, which comes with Windows Vista; FileVault, which comes with MacOS X; and dm-crypt, which is used with Linux....

Our research shows that data in DRAM actually fades out gradually over a period of seconds to minutes, enabling an attacker to read the full contents of memory by cutting power and then rebooting into a malicious operating system....
Interestingly, if you cool the DRAM chips, for example by spraying inverted cans of “canned air” dusting spray on them, the chips will retain their contents for much longer. At these temperatures (around -50 °C) you can remove the chips from the computer and let them sit on the table for ten minutes or more, without appreciable loss of data. Cool the chips in liquid nitrogen (-196 °C) and they hold their state for hours at least, without any power. Just put the chips back into a machine and you can read out their contents.
This is deadly for disk encryption products because they rely on keeping master decryption keys in DRAM. This was thought to be safe because the operating system would keep any malicious programs from accessing the keys in memory, and there was no way to get rid of the operating system without cutting power to the machine, which “everybody knew” would cause the keys to be erased.
Our results show that an attacker can cut power to the computer, then power it back up and boot a malicious operating system (from, say, a thumb drive) that copies the contents of memory. Having done that, the attacker can search through the captured memory contents, find any crypto keys that might be there, and use them to start decrypting hard disk contents. We show very effective methods for finding and extracting keys from memory, even if the contents of memory have faded somewhat (i.e., even if some bits of memory were flipped during the power-off interval). If the attacker is worried that memory will fade too quickly, he can chill the DRAM chips before cutting power.

This is a good example of academic security research. We need to see that the trust placed upon the hardware by the whole disk encryption software is a faulty decision.

There's even a video:

Possible Criminal Charges for Lost Laptops in the UK

Of course, the media are spinning this as "don't encrypt your laptop and you could go to jail" when the goal of the legislation is really: "for those who knowingly and recklessly flout data protection principles".

How many times does it need to be said? Encryption does not equal auto-magical security.

Encryption simply transitions the problem of data confidentiality into a key confidentiality problem. It trades one vast and complicated problem for one slightly less complicated problem. Key management is so crucial, yet it is rarely discussed in these forums. I would rather government officials' laptops not be encrypted than to have them encrypted with poor key management. It's better to know the problem exists than to pretend it doesn't. And it's worse to legislate everyone into pretending the key management problem doesn't exist.

Sorry for the delay, Jon

I just came across this on Jon Callas' CTO Corner just now (11 PM GMT, when I started this draft). I had a busy day Friday (obviously so did Jon), but on a totally different subject. By the time I got around to checking for comments to moderate (24 hours ago), I noticed there were several (contrary to some, I really am not sitting here trying to build a following ... read if you want, or don't--your choice, obviously). A bunch of them were either 'you don't know what you're talking about' (which is fine if they want to think that-- I posted their comments anyway) or they were 'what about X' comments which I already answered in later posts.

I saw John Dasher's (PGP Product Management) comment right away, published it, and elevated it to a main post/entry. There was a lot of negative hype around the company, apparently, and I did not want to have anything to do with a negative impact to the company [If you don't believe me on that point, all I ask is that you please read the other topics]. My main point was that this feature was not published well enough (Jon and I seem to agree on that).

I want to make this clear though: the time it took to get Jon's comment in the list (as it is now and mirrored here) was unrelated to the content in his comment, or my opinion of him in general. Read it for yourself; I'm not against differing opinions or even insults. Just note that I responded to him as well.

Jon wrote:

"As I started asking about what we did and did not do to document the feature, I heard several times, 'I thought we documented that?'

"So our product manager went off to find where it is documented. We found that it was documented in five places, including the release notes for each product (client and server) and the 'What's New?' section of each. Okay, we could do better, but a feature listed in 'What's New?' could hardly be termed 'barely documented.'"

I have pointed out several times that there is a difference between documented and publicly documented. Now it's publicly accessible, but when this whole ordeal started out, that same link required a customer ID and password. You can read how I did work with the vendor, PGP Corp, (how their support people were not well aware of the feature) and read how they were satisfied with the way things were documeted BEFORE they made the documentation available to non-customers.


Jon also wrote:

"In the world I live in, the world of cryptographers-are-security-geeks, the word 'backdoor' is a fighting word. It is especially a fighting word when modified with 'intentional.' It means we sold out. It means we've lied to you.

The word 'backdoor' is thus a slur. It is a nasty word. There a plenty of nasty words that insult someone's race, national origin, religion, and so on. I will give no examples of them. 'The B-Word,' as I will call it, is one of those slurs. It is not to be used lightly."

I agree that "backdoor" has a negative connotation (I'd be stupid to ignore that now), but I disagree that that the connotation should exist (and arguably so do others). And most importantly, I did not use the words "intentional" + "backdoor" to mean anything aggressive or fighting. In fact, I replaced "backdoor" with "bypass" on the first post (and nearly any other post where I don't give an explanation like this one). Clearly from the beginning, I did not imply an "alternative means of access" like the conspiracy theories claim. Shoot, there are even other beneficial "backdoors" in PGP products, like the ADK (additional decryption key, such as used with Blakely-Shamir key splitting techniques). Those are backdoors in the academic sense, just not in the paranoid, socio-political sense. The question at hand is: "for whom does the door open?" And PGP Corp's official stance is: "never for an adversary or warring faction". All I have tried to point out is that it could possibly (no matter how unlikely you think it might occur) open for a well-timed cat-burglar.

I was surprised when Jon wrote:

"I wrote a tart reply and posted it to his second note. As I am writing this, 15 hours have passed and although he has approved other people's replies, he hasn't approved mine.

Murphy's law being what it is, it's possible that by the time I dot the 'i’s', cross the 't’s', and get this article posted on my CTO Corner, he may have printed my reply -- but it isn't there now, I just checked. Nonetheless, it angers me immensely that someone would tell lies and insult my personal integrity and the integrity of my company.

I know why he won't post it -- I point out facts, show that he has intentionally misstated facts, knowingly defamed PGP Corporation, and show that he has not lived up to the very ethical standards for which he criticizes other people. He accuses us of technical and ethical violations that he knows are false.

Therefore, I am posting my reply to him below the break. These are the facts Securology doesn't have the courage to post."

What can I say, Jon? I guess to be fair (and if nothing else following the excellent precedent you have set), I apologize for not moderating comments sooner. Perhaps I should have emailed you so I could have been more open to your time lines. I do hope that you believe me, but I accept that you may not. I ask that you consider how I have published and linked back to everything you have offered (and then some). And I ask that you consider how the ethics truly apply here (and for what it's worth, I did mull over whether to post or not to post on this subject for months after I last discussed the issue with your employees-- I even asked other people whose ethics I trust for their input prior).

I do understand exactly why you would want to jump the gun to believe I was editing you out. It's an "everybody has an opinion" world, one where people can choose what content to keep or throw away. So, I cannot fault you for your response. [If I was in your position, I'd probably do exactly the same thing you did for my employer in an official "PR" type letter: acknowledge, compliment, and trivialize in 200 words or less. It was well executed.]

Finally, Jon also wrote:

"The mark of a good company is how you deal with issues, not the issues themselves."

I think Jon did an exceptional job in his response. He was down-to-earth, humble, yet showed great pride in his company and work. He acknowledged "opportunities" (as the American corporate culture calls them) for improvement, as well as strengths. I think we agree on 90% of the details, and things are improving. Sure, some of the details may be over-hyped; that's not my fault and I still hold to my position.

I would like to believe, Jon, that if we met up in the real world, we would be on the same page.

The door is open for more of your opinions.

About "Backdoors" ...

Again, inspired by the PGP WDE Bypass Issue ...

I am not the only one in the world that uses the term "backdoor" in a generic, non-cryptographic, opposite of your-favorite-national-security-or-mafia-organization-is-going-to-get-you sort of way.

Here are several sources that are considered (at least somewhat) reputable:

Princeton's Wordnet:

"an undocumented way to get access to a computer system or the data it contains"

Wikipedia (supposedly the opinion of the general public, mind you)

"A backdoor in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication, securing remote access to a computer, obtaining covert access to plaintext, and so on, while attempting to remain undetected. The backdoor may take the form of an installed program (e.g., Back Orifice), or could be a modification to an existing program and/or hardware device."

Search Security/Tech Target:

"A back door is a means of access to a computer program that bypasses security mechanisms."

F-Secure (in the context of malware):

"Backdoors are remote administration utilities that open infected machines to external control via the Internet or a local network."

Albany University's Information Security glossary:

"Normally installed by a virus or worm, a backdoor is a alternate method of accessing a system."

The Net Guy (whoever that is-- Google had his definition):

"A means of access to a computer system that bypasses security mechanisms, installed sometimes by an authorized person, sometimes by an attacker. Often installed by programs called Trojans horse programs."

And one of my favorite ones, in light of everything recently:

"Also called a trapdoor. An undocumented way of gaining access to a program, online service or an entire computer system. The backdoor is written by the programmer who creates the code for the program. It is often only known by the programmer. A backdoor is a potential security risk."

Search for yourself. While the use of the term may have prompted a media over-hype, I was not out of line in my word usage. [I removed the term from the parent post anyway, because I do not wish any harm to PGP as a company.] Rarely, if ever, is "backdoor" synonymous with paranoia surrounding an agency having access to your private keys, except ... perhaps ... maybe in a slashdot thread.


UPDATED: Adobe's PDF vulnerability is a current event that illustrates how other people in the "security community" use the word "backdoor" beyond just mathematical-cryptographic access control bypasses.

PGP's Publicized Documentation of WDE Bypass

John Dasher, Director of Product Management at PGP, commented with a link to PGP's documentation on the WDE Bypass Feature. I thought it pertinent to raise John's comment, especially with this at the end of that page:

"We appreciate and are thankful for open dialog between us, our customers, and even our critics. This discourse always helps us improve our process, our products, and the standards on which they’re based."

I cannot agree more with that comment from John.

More on the PGP issue

There have been several comments regarding the PGP whole disk encryption bypass issue and in the process a few people have brought up the question that my discussion of them is exactly what I have preached against with "insecurity researchers"; however, I want to clear a few things up.

Yes, I wrote:

"So, let's see if we can figure out the economic process ...
1. Find some vulnerability in some widely used product.
2. Create a proof-of-concept and publish it to the world (preferably before sharing it with the vendor).
3. Use FUD (Fear, Uncertainty, and Doubt) to sell the services of a security consultancy startup.
4. Profit!"

But this PGP issue is not insecurity research:

1. It is not a vulnerability; it's a problem in the design. It's not a coding bug; it's a "dangerous" approach to solving a problem. And if that doesn't convince you that this is not a vulnerability, even PGP thinks there's no problem.
2. There's no proof-of-concept. There's a threat model, sure, but that's not a POC. There's no exploit code, there's only paradigms of attack/defense. I think that will even pass the Ranum test.
3. If you think this is FUD, I apologize. I obviously do not. However, please note, there are no services being sold, no ads on the pages hosting this content, nor in the feeds, etc. There's zero royalty going to me. I'm not even using a real name to take credit. I just want to discuss paradigms of attack/defense and intricately examine and evaluate what some might call an academic-only exercise. Extended readership is nice, but not the intention here.
4. See #3 -- no profit here.

For the record ... I did discuss this (in the real world) with the vendor. They said the documentation level was fine, and even wanted to close my support ticket before actually adding the KB article that was available for current customers only, which is now accessible here. I asked for them to send a notice to current customers, but they decided there was no warrant for that. I even asked to escalate my support ticket more than once.

I still have respect for the vendor and I encourage others to evaluate all solutions thoroughly regardless of this or anything else. The bottom line is that customers (current and potential) have the right to know their risks ahead of time-- they should not have to buy consultants/professional services time to become aware of a feature like this. It should just be well known. Jon Callas has a thorough track record of proven expertise and his opinion is very valid, just like my (somewhat opposing) view is valid.

I do also wish everyone to understand that "backdoor" has controversy-- I never intended this to mean a backdoor that law enforcement, etc., could use. It's not a cryptographic backdoor; it's a backdoor in the historical sense-- as in there's a way to get unauthorized access.

Yes, the Trojan possibilities seem absurd because malware could do more. What isn't discussed, though, is that malware doing this in addition to the other things it does leaving workstations in a wholesale bypass state so that any less sophisticated smash/grab thief can have access is still a possibility. It would be more than a nuisance to an enterprise IT shop, whether you think somebody would take the time to do it or not.

And, of course, there's the timing attack: grabbing the machine when it shuts down, but before it comes back up. That's the risk that is barely documented--not discoverable by 99+% of current and potential customers. That's the point. If you read into anything else beyond, then you're missing the idea.

PGP Bypass on Slashdot

Thanks, Slashdot. Some of your comments are on target, some ... well, I anticipated the knee-jerk response you gave. Many people (even technical people) make the mistake of thinking the use of crypto automatically equals secure. Yes, I realize it requires cryptographic (as in authorized already) access to the drive, but that's the point. The bypass feature creates an opportunity for authorized users to accidentally allow access to unauthorized users.

The positive aspects of the bypass ...

1. Yes, it does require an authorized person to enable it (not necessarily an administrator, but at least a user).
2. Yes, it does make remote, automated management possible. Although, at an expense.
3. OK. It's not a true cryptographic backdoor, but it is a dangerous access control bypass. Either way, it's unfriendly to discover after installation.

There are really a couple issues at hand here ...

1. There is no central audit trail. Any user could set this feature up without the knowledge of the "remote" admins. In fact, a smart user could create a script (or use someone else's) to disable the boot passphrase after each boot, which leads into the next point ...
2. There is no way to disable this feature. Jon Callas' (of PGP Corp) response that the bypass is "disabled" by default is more accurately stated as the bypass feature is "unused" by default. Anyone can use it at any time. In fact, the PGP Boot Guard (as best as one can tell without public documentation) checks for the existence of the bypass at each boot.
3. There are no integrity checking controls on the Boot Guard. Admins must trust that the boot guard is not accidentally or intentionally modified to stop the bypass reset/removal function.
4. The biggest threat is a timing attack. Capturing a system that hasn't reset the bypass grants full access to the data. If an adversary (or semi-trusted insider) can know when the automated reboots are scheduled, the device can be captured and misused.
5. The feature wasn't PUBLICLY documented. There simply is no excuse for this feature not be disclosed to current and potential customers. That is the #1 motivation for my discussion of this problem.

The bottom line is that if the bypass was properly documented for potential customers to review before bestowing trust in the product, OR, if the bypass could be truly disabled (guaranteed by integrity checks), then this would not be an issue at all.

Some comments bring up the issue of open source vs. closed source for security. Personally, I view that as an irrelevant side-detail; the question I am concerned with is who has access to review the source code. But yes, despite PGP having some sort of an open source code review
process, this feature was still not publicly documented.

UPDATED: Since there are objections to my claim that "The feature wasn't documented" (besides my details about how the feature came to become documented as it is now), I have changed the wording to "The feature wasn't PUBLICLY documented". Because if the documentation isn't in the hands of someone who would find it useful ... then what's the point?

Response to Jon Callas - PGP Encryption Bypass

As I can only assume the real Jon Callas placed this comment (and, Jon, I am grateful for your time and thoughts if it is you), here are my responses....

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

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

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

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.

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

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:

1. 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).
2. Trojan Horse adds bypass by unlocking the master volume key with the user's passphrase.
3. [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.]
4. Laptop is stolen.

OR just this:

1. Enterprise IT shop sends notification to users regarding upcoming maintenance (OS/Application patch) which will include a mandatory/automated reboot.
2. Malicious insider powers off computer when BIOS screen appears, keeping disk in "bypass" state.
3. Malicious insider images the drive or steals the device entirely.

Jon continued:

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

1. 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.
2. The feature could be permanently disabled-- not just ignored or left seemingly unused.
3. The intended use of the feature did not require the creation of a passphrase with cryptographic access to the Volume Master Key.
4. 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.

As for "there must be a better solution", I will follow this post up with potential "better solutions". Some of them may be attainable with your product line, but I'll warn you, Jon, that some of them are not possible today and would require extensive implementation efforts-- potentially rethinking distributed computing entirely. I will likely present a possible solution that will be beyond what your company is positioned to implement.

PGP Whole Disk Encryption - Barely Acknowledged Intentional Bypass

Popular whole disk encryption vendor, PGP Corporation, has a remote support “feature” which allows unattended reboots, fully-bypassing the decryption boot process. The feature, which until recently was not documented (customer accessible only) in most support manuals, allows a user who knows a boot passphrase to add a static password (hexadecimal x01) that the boot software knows. If this flag is set, the boot process does not interrogate a user. It simply starts the operating system. The feature can be accessed via the command line (ignore line wrap):

"%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!

This illustrates that, while encryption of hard drives can reduce the exposure of a lost or stolen hard drive to a time-complexity problem, there can also be a false sense of security here, too. My personal anticipation is that the lost laptop parade in the media will eventually include a breach of an encrypted laptop. This feature of PGP notwithstanding, there is the age-old problem of shoulder surfing for the boot passphrase. PGP’s feature now allows a lost machine with the by-pass flag to be easily compromised. Granted, without that feature, a Trojan could capture the boot passphrase anyway. The real solution is to not have critical data on mobile devices. Our banks do not issue us mobile bank vaults—we keep our valuables in nice, safe, centralized bank vaults where layers of security protect them.

Imagine this scenario:

1. Enterprise IT ships out a maintenance patch requiring a reboot.
2. Scripted installation also uses PGP WDE bypass to setup unattended reboot.
3. Script preps the system for shutdown, but the laptop is stolen.

All it would take at that point is for somebody to use a simple disk imaging tool to get repeated attempts at access to the drive.

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.