Control Your Identity or Microsoft and Intel Will

July 9, 2002

Jon Udell

I've been mulling over the list of features touted for the Microsoft/Intel/AMD security scheme called Palladium.

If you're unfamiliar with Palladium, Ross Anderson has put together a good FAQ on the topic. In his Newsweek story The Big Secret, Steven Levy said that a security chip such as what Intel's Trusted Computing Platform Alliance (TCPA) proposes, combined with a new OS layer (such as Microsoft's Palladium), will:

• Tell you who you’re dealing with

• Protect information

• Stop viruses and worms

• Can spam

• Safeguard privacy

• Control your information after you send it

We have had most of these capabilities in software for years, but haven't bothered to exercise them. The exception is the last item, Palladium's DRM (digital rights management) "feature", which can only work in a world of proprietary devices--and probably not even then. As Ed Felten, the Princeton University security guru, said in a Salon article:

"Society must either give up on copy protection or the general-purpose PC and the Net." And no matter how hard Hollywood tries, Felten argues, society will eventually choose the latter because "the sheer value of the Net and computers is so much greater than any value that copy protection can provide."

DRM aside, the items on Levy's shopping list are useful, mostly implemented in existing software, and more widely available than we realize. For years I've been pointing out that control of our own digital identities is built into the email software that most of us spent most of our days using. Essentially nobody knows about this capability, so nobody exploits it for message signing, encryption, and integrity assurance. As a result, second-order effects like protection against worms and spam have never had a chance to evolve.

Spam, I'm afraid, will be Palladium's toe in the door. This week's New York Times article painted a typically bleak picture: spam has tripled over the past nine months, users are abandoning email addresses, the FTC receives 40,000 complaints every day, and "no-one can do much about it," The Times laments, because:

"All a spammer needs for business is a computer, an Internet connection, and an inexpensive CD containing spamming software and tens of millions of email addresses."

That's true, but suppose the spammer needed one more thing: a revocable digital certificate, bound at least to a verifiable email address and ideally to something more tangible.

The world I envision is divided into two groups: those who assert their identities in cyberspace, and those who do not. Call them, for the sake of argument, professionals and amateurs. By signing my email, I choose to be a professional, and I'll take other professionals much more seriously than amateurs. For example, I'll route all unsigned email to a low-priority folder. Because signing will be a mark of professionalism (and not the geeky affectation it is today), you'll likewise choose to sign your emails so they'll land in the high-priority folders of people like me. If you're a spammer, you'll need to do the same. But now, there's a new kind of accountability. When you broadcast spam, your ID can be revoked. If you send me messages signed with a bogus ID, I'll treat them just like unsigned messages, and route them to the low-priority folder or just /dev/null.

We can choose accountability, or we can let the unholy alliance of Hollywood, Microsoft, Intel, and the government choose for us. The alliance, cleverly, pretends to solve problems that really annoy us, like spam and email worms. But these violations of trust won't yield simply to trusted motherboards and operating systems. People have to assert (and prove) their claims of trustworthiness, and other people have to make judgments about those assertions. The PKI technologies haven't yet perfected the art of binding real identities to virtual ones, but that's just what will be needed on top of TCPA/Palladium in order to deliver the benefits that people actually want.

For years I've argued that activating the security features dormant in popular email software--including Outlook, Outlook Express, and Netscape/Mozilla--is a good idea. Voluntary message signing can establish trust in a way that's useful, and doesn't require reinventing the PC around a digital-rights-management chip.

It's easy to acquire the client certificate that enables S/MIME signatures. It's been years since I did so, so to review the procedure I recently enrolled my 14-year-old daughter in Thawte's Freemail program. Here were the steps:

1. Terms and conditions.
   This page includes a strong privacy statement, and informs you that enrollment will require one of the following pieces of ID: passport number, social security number, driver's license number. "We need this information even if you only intend subscribing to the Freemail program," Thawte says.

   The Freemail option binds your identity to none of these tokens. Instead, it binds to the email address you enroll with. This is the lowest level of assurance--far better than nothing, but still weak. There are two ways to strengthen it. One, available to Freemail users, is Thawte's Web of Trust, a PGP-like system of notarization. The other is to pay Thawte to assert, in your certificate, that an official fact (like your passport number) binds to your identity.

2. Core ID information.
   Here I supplied my daughter's passport number, and an email address. I didn't use her address, but rather one of mine, since I'll be the administrator of this account on her behalf. Once she's enrolled, I can generate an ID that binds to her email address.

3. Language and charset preferences.
   I just took the default: "Use browser settings."

4. Password.
   The account password is a very serious matter, as this page explains in great detail. In particular, it notes that Thawte will not email you a forgotten password, and that an identity token (for example a passport number) linked to an account whose password is forgotten will be permanently compromised. I'd guess that most of the attrition in the enrollment process happens here.

5. Set Password Questions and Contact Telephone Number.
   Despite the dire warnings in step 4, there is a password recovery procedure. Thawte would have to be able to call you at the number you give here, and then you would have to answer five questions, which you select (or invent) on this page.

6. Please Confirm Enrollment Information.

7. Email Message Sent.

8. Enter Probe and Ping
   The email message at step 7 contains a URL and two values marked "probe" and "ping." To complete your enrollment you follow the URL to a form, paste in the values, and submit the form.

Once enrolled, you can create one or more digital IDs. That process goes like this:

1. Choose X.509 format.
   The options include Netscape (works with Mozilla too), MSIE, Outlook or Outlook Express, Lotus Notes R5, Opera, and the C2Net SafePassage Web Proxy.

2. Common Name.
   If you're notarized through the Thawte Web of Trust, your certificate can include your name. Otherwise (as in my case) the common name will be "Thawte Freemail Member."

3. Email addresses.
   Listed here are the addresses you've entered into the system. To add one, use the add, then ping, functions. Although you can embed several addresses in a certificate, Thawte advises that you use just one. This address, embedded in the certificate, will match (and validate) the address on your From: header.

4. Strong Extranet.
   If your identity is certified as part of Thawte's commercial certification program, associated identities would be available here and could be included in the certificate. Such an identity could, for example, enable single sign-on to a suite of corporate applications.

5. Certificate extensions.
   Regarding these, Thawte says: "Please note that the extension options below are not for the faint of heart. You probably won't trigger a Vogon invasion of Earth if you press the wrong button, but you might cause weird behavior in some otherwise-normal software. Don't fiddle with this unless you've been told to, or unless you're a born fiddler."

6. Cryptographic service provider.
   The default here, on Windows, is Microsoft Enhanced Cryptographic Service Provider 1.0.

7. Generate private key.
   If you're on Windows, and you are creating a certificate for use in Outlook or Outlook Express, this is your chance to ratchet up the password security on the certificate. You'll see this dialog box:

   

   Click on the Set Security Level button to bring up this dialog box:

   

   Choosing High means you'll be asked for your digital ID password each time you sign a message. Most people won't want to do this, but I like to. It makes the act of signing an email message feel like signing a physical document. The equivalent setting, in Netscape, is available anytime (not just during key generation) at Edit -> Preferences -> Privacy and Security -> Master Password -> Master Password Timeout -> Every time it is needed.

When you've generated your key, Thawte issues the URL at which you can retrieve your certificate. It takes a few minutes to process your request. Then, on that page, you can click on a link to install the certificate into your email program.

What has all this rigmarole finally accomplished? There's the rub. You can assert the validity and integrity of your messages, but no one expects you to. You can automatically acquire public keys from others who sign their message, but no one does so. Having acquired those keys you can encrypt messages to those people, but again, they don't expect you to do so.

The problem with the S/MIME suite of email security features is that they tackle problems people pay lip service to, but don't really care much about. A problem that people do care about, though, is spam. Do we care enough to assert our identities, and thus enable software to separate us from abusers who will not? It's debatable, but in any case let's consider how a culture of voluntary-identity assertion might combat abuse.

Imagine for a moment that email signing is routine. I've said we could then separate email correspondents into two groups: professionals and amateurs. In practice, that would mean an email filter that classifies messages based on the presence of a valid signature. This wouldn't be a difficult thing to do, but since there's never been demand for the feature, the filtering mechanisms in popular email software don't currently support it.

The harder problem is certificate revocation. To explore this issue, I revoked one of my Thawte Freemail certificates. The goal of the exercise was to get my email software to notice that a message was signed with a bogus certificate. The technology exists, but it's even more obscure than the basics I've reviewed here so far. On this Thawte Web page there is a link to Thawte's Freemail CRL (certificate revocation list). Merely acquiring a certificate doesn't connect you to the CRL. If you want your software to reject bogus certificates, you'll have to track down its URL and load it. When you do so in MSIE, you'll invoke this CRL viewer, shown here displaying the certificate (serial number 07 c1 0a) that I revoked:

Note, by the way, that it took about six hours for my revocation to appear on the list--plenty of time for a spammer to complete a broadcast.

An MSIE user would, in any case, have to repeatedly fetch the CRL--which is, of course, unlikely. Mozilla does much better. Once you fetch the CRL, you can arrange to have it updated daily, like so:

Of course, updating the CRL doesn't help you unless your software actually consults it. So far as I can tell, Outlook doesn't. Messages signed by my revoked certificate look completely normal in Outlook. Mozilla, on the other hand, comes up smelling like a rose. Here's what I expected to see, and did see, in Mozilla:

Note how the broken pencil signals an invalid signature. Mozilla also claims (though I did not test) support for Online Certificate Status Protocol (OCSP), which aims to augment or replace CRL technology with a more direct protocol.

There are, admittedly, plenty of holes in the argument I've made here. Certificate revocation would have to work in near real-time, as OCSP hopes to enable. Certificates would need to bind more durable identity tokens than fungible email addresses. A culture of identity would be at odds with the culture of anonymity that is, for many people, a core value of the Internet. It comes down to this. We can choose to control our own identities, by embracing and refining some existing technologies that are widely available. Or we can cede that control to a cartel that wants to reinvent the PC and the Internet in ways antithetical to freedom and innovation. If spam is the fulcrum issue that will motivate the masses to accept a change, let's offer a solution based on a voluntary framework of trust. We'll like the alternative mandatory scheme a lot less.