Tangled in the Threads

Jon Udell, July 12, 2000

More on Digital Identity and Client-Side Security

Last week's column on digital signatures provoked quite a lot of thoughtful feedback. Noted one newsgroup participant:

I sense a flaw in the plan. It's true that most people will not bother to type in a key or passphrase with every message they send. So what then? It gets stored in the mail sending system somehow; then it gets automatically added by some sort of programming action or mouse click or something; then (and this is the flaw) someone finds a way to hijack _that_ process into a bit of malicious code, and we're all back to square one. Or did I miss something here? Of course biometrics are different but no ordinary user is ever going to use them.

Dominic Amman responded that this problem stems from a failure to cleanly separate authenticating applications from authentication services.

It's a problem that IE (and other browsers) will execute components in non-protected memory and file space. The next version of of Netscape will use a Security Manager application, which runs as a module in its own space. So, even if my SCM gets my password when I send my first e-mail, and remembers it, the SCM is not vulnerable to attacks by silly unsigned widgets I download and allow to run hog-wild in my e-mail or browser client.

Actually, after checking, it appears my current Netscape already runs the Security Manager as a separate app -- as a side effect of the old US export restrictions! Netscape talks to the SCM through a defined secure API, which is not accessible to downloaded scripts or components.

With respect to biometric authentication, it's quite true that if it's too hard to sign messages, we'll delegate that chore -- with predictably disastrous results. Clearly there is no biometric solution in common use today. But biometric authentication is necessary, and I predict that it will in due course become something we take completely for granted.

Andrew Ducker:

Agreed. Already some large companies are running trials with them, and have found that the amount of tech support time saved with them pays for the cost of installing them. Eventually they will be cheap enough that they come built into your keyboard, and we can just use our thumbs to log in.

Biometric authentication is, admittedly, spooky stuff. As one reader, Chris Calabrese, pointed out in email: "If your biometric identity is stolen, you need surgery to get it back." Another acquaintance, who does "penetration" for a network security company, told me that a retinal scanner he was testing only worked when pressed to a cheek because "if it can't feel a pulse, it figures your eyeball has been stolen."

It's important to keep all this in perspective, though. Nothing is infallible, but it's hard to imagine a more fallible system than what we have today. Web services are popping up like weeds, and not a week goes by that I don't join several new ones. Despite the fact that I've got a perfectly valid client certificate sitting on my machine, every one of these services uses HTTP basic authentication -- maybe over SSL, usually not -- and transmits my login credentials in unencrypted email. Being human, I guiltily reuse the same sets of credentials over and over.

Let's not forget that message-signing isn't the only reason to use a digital ID. They were also invented to bring single signon to the Web. Authenticate to your PC -- or, better, to your crypto-card -- and let it negotiate access to the ever-increasing array of services on which we depend. We're at the breaking point when it comes to managing passwords. President Clinton unwittingly illustrated the problem when he digitally signed the digital signatures bill. As many people pointed out, he broke all the rules by choosing a password ("buddy") that is short, in the dictionary, the name of a family member, and known to everyone. If we could reduce all authentication, for both messaging and Web services, to a single digital-ID password, it would be a bit easier to get people to user proper passwords and to change them from time to time. But realistically, biometric techniques are the only hope.

Trusting active content

As I said last week, I don't think that active content is inherently evil. It's surely powerful, and therefore dangerous, and therefore something we need to learn how to control. For Brian Robertson, the Java flavor of active content is safer than the ActiveX flavor. He's particularly concerned about the attack avenues opened up by SOAP:

The major security concern is the Microsoft XML parser built into IE. The versatility of Microsoft's application of SOAP will give hackers access to every component of Microsoft Office/Explorer/Internet Explorer/Outlook.

It was almost certainly better using the initial Java XML parser that was supplied for IE4.01. It ran securely within the JVM (JRE). I know there were a few security mistakes made while Java was being developed, but they were all quickly corrected, and I don't believe that there has ever been a Java virus/trojan that has worked in the wild.

If not, I'd suggest that's because there's as yet little real use of client-side Java. The reason, I think, is that Java's safety on the client, and its utility there, are inversely proportional.

A few weeks ago when I was testing AnywareOffice -- the Applix suite with a remote Java face -- I used the sandboxed version. That meant: no local saving of files, no use of the clipboard. It was immediately clear that for any real work, I'd need and want a signed version of the applet that could do useful things.

So we're back to the same issues:

I see little difference ultimately between ActiveX and Java in this regard. Both, to be useful, require a sophisticated scheme of trust and permissions. We don't have that yet. But with each passing month, it becomes clearer that we need it.

Here's Chris Calabrese again, from private email (quoted with permission):

Chris Calabrese:

It's true that MS is not the only culprit here, but they are perhaps 99% of the problem. Only MS keeps moving in the direction of adding more and more and more scripting capabilities into things that are supposed to be "documents." Only MS keeps making the same implementation mistakes regarding how/when to execute different active content. Only MS keeps sending out ActiveX controls that are unsafe yet marked safe over and over.

The rest of the world mostly learned this lesson back around 1994 when CERT first put out advisories against PostScript and troff documents with active content (and PostScript and troff viewers were subsequently changed to ignore the nasty active-content directives). MS keeps repeating and repeating and repeating and repeating the same damn mistakes over and over and over and over.

Jon Udell:

So is your conclusion that active content with a useful degree of power can in principle never be controlled? Or in practice cannot be?

Chris Calabrese:

It can be controlled. It requires something like the Java sandbox, but if you want it to work for general programs, rather than just Java bytecode, you need the controls in the operating system. At this point you're talking an OS with mandatory access control, domain/type enforcement, and a default deny posture running on a trusted computing base. In other words, you need an OS that's rated B1 or higher by Orange/Red book standards, which limits us to a few special "trusted" Unix variants aimed at the military and firewall markets. These aren't very good candidates for a popular desktop platform. WinNT 4.x (already much much stronger than Win95/98), by contrast, was recently awarded C2 (which doesn't have anything like the capabilities we're talking about here) after literally years of trying, and that's only when there's no network connectivity! More hopeful is the work being done by the Linux guys, which may bring B-level capabilities to Linux in the next year or two. The Apple folks could also move in that direction with their new Unix-based OS X.

But even with a B-level OS, we still would need a standard mechanism to distribute the trust relationships. This exists in the military world on a limited basis, but there's nothing even close in the commercial world. No, signed Java and ActiveX don't count because they don't include a mechanism to distribute information about what operations the OS should trust the signed code to perform, a problem made blatantly clear by all those ActiveX components MS has marked "safe for scripting" that keep doing nasty things they're not supposed to intend.

Conclusion: Active content with a useful degree of power can not practically be controlled without major changes to the supporting technologies.

Well said! Thanks Chris. I say, bring on those changes ASAP. We're fast heading into a peer-to-peer world. There's no longer such a clear distinction between services out there on a server in the cloud, and services right here on my machine. The RIAA may shut down Napster, but the cat's out of the bag. The network is the computer -- or rather, all the computers. Security concerns will apply equally everywhere. So by all means let's please have a "default deny posture on a trusted computing base." In other words, let's have Windows think and act more like Unix, denying what is not explicitly permitted instead of the reverse. And let's have trustworthy end-user OSes. Those OSes will, in turn, need to be able to determine who, and what, to trust. The PKI (public key infrastructure) that supports many forms of encryption (SSL, SSH, S/MIME), as well as digital signatures, isn't yet fully standardized and deployed. And these technologies certainly aren't the final answer. But they're the best ways yet devised for people (and computers) to know who (and what) they're dealing with. We've got to bite the bullet and master this stuff.

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.