Tangled in the Threads

Jon Udell, July 5, 2000

Identity Crisis

The security hole that email worms exploit isn't fundamentally a problem with scripting. It's really about identity.

The day the ExploreZip worm hit the Net, I received this unfortunate message: 

Hello

You are in my address book and have therefore probably been sent an e-mail
"from me" containing a zipped attachment - which I received from 
[SENDER], [TITLE], [PROMINENT_COMPANY]

DO NOT OPEN THE ZIPPED ATTACHMENT - this is the worm virus on the news.

Simply delete the e-mail.

Sorry

[VICTIM]

Many months later, in the wake of the Love Bug, nothing has changed. The experts interviewed for CNET and NPR are still trotting out the same recommendations:

I don't think that scripting, and executable attachments, are the root of the problem. Identity theft is. These worms, while clever, are more socially than technically adept. A victim is attacked by a message that seems to come from an acquaintance, perhaps even in response to a message just sent to that acquaintance. In reality, of course, the poisoned message comes from a trusted person's machine, but not from that trusted person.

I do most of my business, and you probably do a lot of yours, through email, represented by nothing more than an email address. Everybody knows it's trivial to forge an email address. The latest round of email hacks has shown that it's also far too easy to hijack somebody's email program and wreak havoc with it.

It baffles me that people who fret about the strength of encryption used to guard their credit cards enroute to Amazon.com will, quite happily, transmit reams of unencrypted confidential communication through a whole chain of SMTP email routers. It also baffles me that people don't seem to care much about, or do anything to protect against, identity theft.

Prove your identity with a digital signature

The email clients bundled with both the Microsoft and Netscape browsers have, since 1996, enabled us to digitally sign our messages and thus prove our identities to recipients. I sign all my email messages, but I can count on the fingers of two hands the people who have ever sent me signed email messages. Leave out cryptography experts, and it's the fingers of one hand.

To sign your email, you need a client certificate, aka digital ID. These are like the server certificates that secure Web sites must acquire and install. Server certs do more than just enable SSL on servers. They also authenticate servers to clients -- that is, they prove to your browser that it's really connected to Amazon.com, and not some rogue site masquerading as Amazon.com.

The dirty secret of e-commerce is that the reverse procedure -- authenticating clients to servers -- has never caught on. You know that Amazon.com is Amazon.com, but it doesn't know that you're you, only that you're somebody's valid credit-card number. Why not? It takes effort to acquire and use a client certificate. Nobody wants to slow the e-commerce juggernaut by asking people to make that effort.

How would digital signing have thwarted the Love Bug? On my machine, I've configured my email program to require me to sign all outbound messages. Yes, that means that I actually have to type the digital-ID password once per message. Yes, that's a drag. But it would be much worse to wreck my colleagues' disks and reputations.

Of course, typing a password once per message is a ridiculous inconvenience that most people won't put up with. As, unfortunately, is the current procedure for acquiring client certicates. I'd rather receive a digital ID as a consequence of some routine administrative activity, like registering my car or paying taxes. And I'd rather the Send button in my email program could read my fingerprint, or do some other kind of biometric authentication.

It's a chicken-and-egg problem. We made a good start in 1996, and widely-deployed messaging software does far more -- with respect to both signing and encryption -- than the vast majority of users realize, or exploit. But because these available technologies are little used, there's little pressure on the industry to perfect them. Many people regard digital signatures as a geeky affectation. We need to regard them, instead, as a mark of professionalism. If we're doing business by way of email, we should expect proof of each other's identities, and we should want to offer such proof for our own protection.

Client-side scripting isn't inherently evil

Many people cite Microsoft's script-enabling of its software as a hazardous mistake. I agree that it's hazardous, but not that it's a mistake. As I mentioned last week, CGI security holes have caused plenty of trouble too, but few would have shunned the first-generation web until "that CGI security hole" got plugged. CGI was the Web's equivalent of DOS INT21; network effects made it at once more powerful and more dangerous.

Of course it's easier to control a centralized, server-based technology like CGI than to control distributed, client-based technologies. But the immense rush of enthusiasm surrounding Napster, Gnutella, and Freenet tells us that the client-server web is, finally, becoming a peer-to-peer web. The final chapter of my book foresaw this trend:

Like any powerful technology, this one's a double-edged sword. Wielded responsibly, it can enable all sorts of useful things. In the wrong hands, it can spell disaster. As with genetic engineering, there are two ways to respond to this dilemma:

  • Reject the technology. You might reasonably conclude that potential risks outweight potential benefits. Peer-to-peer replication of code and data is inherently uncontrollable, therefore dangerous, therefore to be shunned.

  • Embrace the technology. You might also reasonably conclude that if peer-to-peer replication of code and data seems too simple and too powerful, then the correct response is to tap into the source of that simplicity and power, analyze the associated risks, and learn how to manage them.

Part of that analysis, I believe, involves distinguishing between what software can do, and who can do it. I very much want to be able to automate my email software much more powerfully than even its current script-enabling allows. At the same time, I want to be sure that software acts in my name only when I specifically authorize it to do so. This is not an easy problem to solve. But solve it we must -- and, ultimately, at the level of OS/network infrastructure rather than applications.

The digital signature law

On June 30, President Clinton signed the "digital signatures" bill into law. Earlier, in the newsgroups, I had expressed some skepticism about the failure of this bill to define, in any meaningful sense, what a digital signature is. Mark Wilcox agreed:

It's dangerous. Most places consider clicking a button to be as good as a signature -- when you opt out of a service, or agree to a software license.

What if we're suddenly held liable for a contract by simply opening an email message?

There's no standard for digital signatures.

But James Power pointed out that, in a sense, nothing changes:

All it is saying is that if you agree to something electronically, it can be as legally binding as by signing your name on paper. Of course, if you say you didn't sign it, that it was forged, then that would complicate matters, just as it would if you say your signature on a check was forged.

Todd Boyle was also pleased with the outcome:

I think the wording of the bill is just right. If they encoded [specific implementations] into the law, it would be obsolete in months...and whoever owned the patents and gateways would be set for life, collecting rents, while other acceptable/superior digital signature technologies were NOT enforceable.

I think digital signatures are the greatest thing since sliced bread. They are another step towards the free and geodesic model of commerce, between individuals and small business, outside of the control of central hubs and corporations and banks, which I hunger for.

On reflection I agree that the government wouldn't understand, and shouldn't try to legislate, how digital signatures are implemented. What we can hope for is that, by legitimizing the concept, and raising general awareness of it, they'll create a competitive market for standards and technologies that have languished for several years now.

Meanwhile, various consumer advocate groups have criticized the digital signature law for exposing people to the risk of identity theft. One such group, the Consumer Project on Technology, issued a statement expressing this concern. In that statment the CPT's director, Jamie Love, said:

In general, electronic transactions may leave consumers more vulnerable to unauthorized use, compared to conventional transactions. Technology residing on a consumer's personal computer can hardly be expected to be shielded from malicious intrusions. Unlike a handwritten signature, if an electronic authorization is stolen or forged, the legitimate owner will be hard-pressed to prove that it was used fraudulently. The E-sign Act contains no provision to limit the liability of consumers victimized by fraudulent spending.

Fair enough; these are legitimate concerns. It's ironic, though, that the CPT's e-commerce page presents that statement by referring to an unsigned email message in a mailing list archive. It would be trivial for me, or anyone, to assume Mr. Love's identity in a posting to that list. We have the tools to provide at least minimal assurance that an email address binds to an identity, and is suspect when not bound to that identity. It's time to start using those tools.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

Creative Commons License
This work is licensed under a Creative Commons License.