The other day I received an email message from jon_udell@infoworld.com, accompanied by a valid S/MIME digital signature. But the message wasn't from me, it was from David Wall (see earlier post), and here's what it said:



As mentioned here is a spoofed email that appears to come from you and is digitally signed. Note that I signed up using another person's email address, another person's SSN, another person's phone number, chose your name as the password for the key, etc. In other words, these "precautions" Thawte demands don't provide any real security any more than checking IDs will stop terrorism. Only the honest will comply.



And what's worse, the person who really has the SSN that I provided won't be able to get her own certificate now because I've locked it up, yet Thawte doesn't know who I am to resolve matters.


Ouch! This withering critique of S/MIME deserves a closer look. I was at first perplexed because I've tested S/MIME forgery myself, and have verified that when the From: header doesn't match the certified address, S/MIME-aware mailers tell you that the signature is invalid. So let's look at how David's trick works.



I began by retracing David's steps, because it's been a very long time since I originally signed up with Thawte -- a process which, as reader Matt Dirks notes, begins here. (Another reader, Dennis Wurster, pointed me to this overview of the signup process.)



Like David, I was able to use a random 10-digit number to satisfy Thawte's requirement for a "national ID." He's right: that's lame. The freemail cert does one thing, and one thing only: it binds a public key to an email address with minimal assurance. Thawte, like other certification authorities, will sell you certificates that offer more robust assurance. Only then, arguably, should official credentials -- SSN, driver's license, passport -- play a role in the process. I'd love to hear from Thawte (or another CA offering free S/MIME certs) on this point.



Here's the information I gave Thawte when I created my new account:



        Surname: Gates

      Forenames: Bill

    Nationality: American

USA National ID: xxx-xxx-xxxxx

      Thawte ID: JUDELL@MYREALBOX.COM

  Date of Birth: 1955/05/12

And here is a spoofed message from Bill Gates with a valid digital signature backed by a certificate containing these data:

spoofed S/MIME, Outlook



Cool, huh? It probably wouldn't occur to Aunt Tillie to click on the signature icon. If she did, here's what she would see:


spoofed S/MIME, Outlook: revealed

The signature is valid because the email address in the From: header does match the certified email address. But Aunt Tilie can't see the mismatch between the address and the friendly name. The forger, relying on the fact that Outlook's "friendly" display hides the actual email address, misdirects Aunt Tillie. She is tricked into believing that the signature binds to billg@microsoft.com rather than to judell@myrealbox.com.



In another context, that bit of misdirection doesn't work so well. Here's the same message in OS X Mail:


spoofed S/MIME, OS X

In this case, even poor old Aunt Tillie might wrinkle her brow and suspect foul play. Unfortunately for her, OS X Mail's ability to inspect the certificate is far weaker than Outlook's. Clicking on the signature icon does nothing. And there is zero chance she'll find her way to the Keychain Access app, figure out which of a bunch of similarly-named Thawte certs corresponds to this message, and inspect it.



David Wall and I draw different conclusions from all this. Mine follows from last week's posting, standards versus conventions: we can't neglect the subtle user-interface details. For example, RFC2312 says:


Receiving agents MUST check that the address in the From header of a mail message matches an Internet mail address in the signer's certificate.

Clearly that's necessary, but not sufficient. I can imagine some additional rules:

  • A receiving agent that displays a signed message MUST display the address in the From header along with the friendly name.


  • A receiving agent that displays a signed message MUST one of the standard signature icons: {URL}


  • The signature icon MUST link to a certificate viewer.





Historically, of course, we don't spell these things out. When I suggested that perhaps we should, Marcus Ramberg suggested that I've been "taking a deep hit of the crack pipe":


For one, standards like this would conflict with UI standards on the respective operating systems the apps run on, and anyways, the point of making a standard is so entities can interact with each other. How applications should interact with users is a topic for UI Design 101. [Marcus Ramberg]

I disagree. Security is a game of social engineering as well as cryptography. And social engineering is inseparably linked to UI conventions. I'm not saying that RFC2312 is the place to spell out the details, but I'm pretty sure we need to do it somewhere.

[Jon's Radio]