PGP CTO Blog

Smile When You Say That
5 October 2007

Part of my job as CSO is that I run security response at PGP Corporation. It's a fact of life that if you drive a car long enough, you're going to crump a fender. If you run a security company long enough, you're going to have something annoying happen. The mark of a good company is how you deal with issues, not the issues themselves.

No doubt by now you have seen a blog post on "Securology" called, PGP Whole Disk Encryption -- Barely Acknowledged Intentional Backdoor. Needless to say, this concerns us because there are no backdoors in PGP technology. There never have been, and there never will be. (Come on, if there were backdoors, beat cops with computers everywhere in the world would be coming to us every time they arrested someone with a laptop. We don't have time to have backdoors.)

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.

There are plenty of people who don't know the difference between a backdoor and a backup, however. They don't know that The B-Word is a fighting word. This is also true with other words that are cute or ugly, depending on the context.

If there’s a point Securology has that is valid, it is that the feature we have wasn’t documented as well as it could have been. So I put on my incident inspector's hat and proceeded. I wrote a response to Securology conceding that point: If someone can't find something in the documentation, it wasn't documented as well as it could be.

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

Securology replied to my response as I was investigating the issue. In his response, he admitted that his facts were wrong, admitted that it wasn't a backdoor, and also made it clear that he can tell The B- Word from a backup.

He's a smart guy. I read a lot of his blog, and he's good. If you look at one note of his in particular that he linked to, and I refer to later, he's good! Man, I wish I wrote that!

The suggestions that he gives us for improving the product are good. They're so good that we're putting three out of four into beta test this week, and we might be able to get the fourth one in soon as well.

The fact that he’s good makes the insult all the worse. He knows what he's doing -- which is precisely the sort of shoddiness for which he deftly criticizes other "Security Researchers." He's creating hysteria and buzz with falsehoods for his own gain.

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.


----------------------

Thanks for posting my comment, Securology.

Let me respond to your comments.

Unfortunately, my first paragraph got mangled. What I meant to say was that we didn't document it as well as we could have. I noticed the error right after I posted the reply, but the blogging software you use doesn't allow people to edit.

There's an old rule in human-computer interactions that boils down to "the user is always right." If a user can't figure out how to use a feature, it's the developer's fault, not the user's. In this case, if you couldn't find our documentation, then it wasn't documented well enough.

So let me talk first about where we've documented it. The product manager tracked down where it's documented. Here is the list:

We have a paragraph in the documentation that says:

    Domain administrator restart bypass. Windows System and Administrator account(s) may now engage a mode to bypass WDE authentication on the next restart by utilizing the privileges of the administration account to act as the authenticated user. This feature enables administrators to perform remote software installations requiring a restart of the target computer. Use of this feature is logged to the PGP Universal™ server.

This paragraph is in the "What's New" section of Page 3 of the PGP® Desktop guide and Page 21 of the PGP Universal™ Server Admin Guide.

This paragraph also appears in the release notes of both products.

We also have a tech document http://support.pgp.com/?faq=750 that is titled, "HOW-TO: 
Use the PGP® Whole Disk Encryption Authenticated Bypass Feature". Yes, you have you have an account on the support web site.

We've noted ourselves that we don't yet have a "PGP® WDE Command Line User's Guide," and ideally it should be there. Also it is not in the usage text that the pgpwde program prints. We'll work on these.

However, while I grant that we didn't document it as well as we could have, I really have to take issue with you that it's not documented. 
It is documented. It's not something that we are hiding -- heck, it's there because of customer demand. I know you're incredulous, but people want this feature.

But it is documented, and more than just barely. The core issue that you've brought up -- that we did not document it -- is in fact wrong.

Permit me a small rant before I continue. You are wrong on a number of facts, and I accept that we all make mistakes. (Heck, I garbaged the opening paragraph of my reply.) But you're using inflammatory language ("backdoor," "barely documented") and bringing up canards. I count as a canard your comments about how my reply to you has no non- repudiation. Hey, Securology, it's your blog we're using. Your question about whether this is intentional or oversight is essentially a "when did you stop beating your wife" question.

You admitted in your comments:

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

In other words -- by your own admission, you calumniated my company because it makes for a good headline. You made false and defamatory statements about our integrity because you disagree with a feature.

Also, you never contacted PGP, you haven't called or written to as for clarification or explanation. You're behaving like the "Security Researchers" that you decry, who make a fuss in public before they get their facts right. Let me throw this back at you -- is your inaccuracy merely a mistake, or is it a way to increase your blogging cred by libel? I don't think you're doing anything more than being sloppy. I love reading your blog and I cheer you on, but Gosh, Securology, live up to the standards that you profess! Don't be a "Security Researcher" as you describe it in your own blog!

You're doing exactly what you decry, namely:

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!

Except that this isn't actually a vulnerability, it's a feature you don't like, and the proof-of-concept presupposes that the adversary have kernel access to the system and can write the disk.

Enough ranting.

Let's go to the next issue.

You're right. There's no trusted path to the boot process. So? 
Trusted Computing is still a goal more than a reality and this is somehow PGP's fault? I would love to have a trusted path to the boot credentials and in a year or two, I think we'll get there. Yeah, the marketing sheets on TPMs say it's there now, but we do not yet have boot-level, bug-free TPM drivers for all the major TPMs. We're working on it, and as I said, I hope we'll be there. Call me wary, but I'm the one who gets flames when someone can't booth their laptop. TPMs are really close to being ready for prime-time, and when they are, we'll use them.

You said, "If ... 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)...." I should remind you that we publish our source code. Go download it. Reverse-engineering isn't hard when you have the source.

Permit me to describe what the process is. We take one constant byte and a bunch of random ones, and create a cryptographic credential. We write that on the disk. This is something that is unique (because of the salt) and used once. You must have access to the volume key (knowing the passphrase is an example of access) to produce the credential. After a reboot, Bootguard removes the credential from the disk.

Your pictures and descriptions are accurate enough. Let me summarize your comments and proof-of-concept scenarios thus:

You can shoot yourself in the foot with this.

Brilliant deduction, Holmes! How do you do it?

However:

1. Only you can shoot yourself in the foot.
2. No one else can shoot you in the foot.
3. You can't shoot anyone else in the foot.

Why is this a problem? There is no matter of disabling the feature, if you can't enable it without credentials. Bluntly, if you know a passphrase to the disk you can bypass (once) typing in the passphrase to the disk.

Your scenarios about how someone could do something are certainly possible, but come on! You have assumed an attacker who can run kernel-level code on the system, and then conclude that someone can do mischief.

You've also decided that the mischief they want to do is to reboot the system without Bootguard. If someone can steal your passphrase from you and run kernel-level code, there are far more interesting things that they can do than reboot your system. There really are evil hackers, and you're suggesting that if they use a trojan horse to get my passphrase, they will then reboot my system.

Let's conclude by going to your suggestions.

(1) Despite the fact that we did document it in numerous places, you didn't find it. That means that it wasn't documented well enough. 
We're working on that right now.

(2) You're not the first person to request a permanent disablement of the feature. As you have noted yourself, this is harder than you'd think. Nonetheless, this might arrive in PGP 9.7. We do recommend to people that they can use Windows file ACLs to disable this for non- administrative users today. It isn't cryptographic, but it works.

(3) A feature to allow a member of an "admin group" (as defined by Active Directory) is now in our "managed beta" of 9.7, and should be in public beta in early November. This also addresses the request you have in (4), as well. Additionally, central audits of all uses of the feature are in beta test, and the reboot bypass can't be enabled unless you have communications back to the PGP Universal Server.

To conclude then, of the four improvements you asked for, there are 3
1/2 in beta test today, and a workaround for that 1/2. If you had contacted us, we could have told you that. Of course, you wouldn't have been Slashdotted. Your headline would have to have said, "PGP Has Enterprise Management Feature Documented in Their 'What's New,' 
Admin Guide, and Release Notes" and headlines like that are hell on your hit count as they look like press releases.

If you have further questions, let me know. If you doubt whether this comes from the real Jon Callas, send an email to security@pgp.com. 
I'll reply personally.