I gave up on commenting at Slashdot articles a few years ago, so if I have something to say, it might as well be here. It's not the karma I worry about (I've always been positive) so much as the fact that there is a huge signal to noise ratio, and I read it about a day behind when most of the comments/moderation has already precipated out and anything I might post quite possibly won't be read. Also, this post got to be an extremely long essay of sorts.

This latest Ask Slashdot was full of a lot of well-moderated dreck. I mention it because it falls within one of my weird "areas of fascination™", and although I can't make any claim as to being an expert, I think I have a hell more an idea of the intricacies than the average slashdotter. I've done a lot of work in security, authentication, and privacy studies. The three together compromise one of the biggest, ugliest, and most complex systems we deal with unconciously in our lives. Most people treat this topic like some form of black magic... you "have it" or you "don't", and often only blood sacrifices might change that, in the minds of most.

So, someone on Slashdot asked a bunch of nerds whether or not "code signing" (using a digital signature on program code) was "worth it", citing the opinions of an expert in Cryptography (the applied mathematical facet of the whole Security-Authentication-Privacy megasystem).

First, signatures are the major component of the Authentication world. (The lesser counterpart to signatures being vouchers, which is where OpenID gets its strength as an Authentication system. OpenID is my recommended standard (of the ones I've seen) for basic website authentication, and I'm hoping that more of a push gets made soon enough to build OpenID support for Drupal and other PHP projects.) Signatures are a (as much as anything else) an invention of the Banking system, and they've grown a lot of magic and mystery around them because they are so close to our money (which itself has a lot of weird magic beliefs, but that's another topic).

What is a signature? At its base, a signature is to say "I am the authentic me". In the real world we rely on a particular set of scribbles that most of the time for most of the people stays fairly close to the same on each writing and for most of the people is fairly unique from everyone else. Here's the fun part: why do you trust a signature? Why do you sign reciepts? Why do you sign contracts? Think about it for a bit, and I'll come back to it in just a second.

In the digital world for signatures we use one from a "statistically unique" pair of huge numbers to encode a tail to the document (readable by the other, but that's not important for this discussion at the moment). Having a signature says that statiscally the digitally signed document only came from one source: the source with a particular really huge number with his/her name on it. Given that definition, does that sound like a good authentication?

What if I pointed out that that in most cases (to the accuracy of current handwriting analysis technology), the statistical likelihood of a correspondence in real world signatures is much higher than digital signatures? The key arbiter of a signature disbute in the real world often ends up being a Psychologist and based upon "what a person thinks when they are signing"... Have you ever actually listened to a handwriting "expert"? It sounds just like listening to an astrologer. At least digital signatures can fall back upon mathematics and give you the exact probability statistics of such an occurence. So, again, I ask: why do you trust a signature? The easy answer is that "we've been trained to". Bankers and Lawyers have a lot at stake if we all decided to take our leave of the things. Let me prefix this, before I go on that I am not a lawyer... none of this is legal advice and could be overturned by the Supreme Court any day they choose, and is probably invalidated by more state laws than I can count... I'm just stating all of this from a pure Systems Design perspective.

Signatures are just Authentication. They label something as being being from "some one person", relying on the statistical uniqueness to provide a one to one relationship between signatures and people. There is no Security inherent in a signature. Can you Trust someone just because they have a signature? No. Can you Trust a stranger that the signature they give you is their signature? No. Any and all trust inherent in a signature must come from somewhere else!

Let me spin you some real world examples: When you sign a contract, the other party can't trust your signature that you are going to abide by the contract and that you are who you say you are... what the other party is in fact trusting is that your lawyer (and witnesses, in such cases) knows it is your signature and that your signature authenticates your intent to enter a trusted relationship, because it should (in all statistical likelihood) show that it was you who signed it and that your existing relationship can vouch for that. That is why most contracts require various degrees of witnesses, including Notary Publics (who have spent time and money registering as an unbiased person in a trusted relationship with the governing body; consequences can be severe if they break that trust).

Then there is my favorite example provided by Credit Cards. When you sign the back of the card, you authenticate it as your card, and usually that you authenticate your agreement to card terms of service. The trust relationship between you and your card is not created by the signature... it is created by your banking institution: that's why you must apply for a card, and that's why credit reports exist. Yes, you are forced to sign a card to show your authentication of the terms of service, but other than re-enforcing the prior established trust relationship. (This is because terms of service themselves declare the relationship to be flawed in the event of an unsigned card, and that the CC company doesn't trust someone who won't sign their cards. The fun part is how that self-referential act has such magical power in the Banking world.)

Furthermore, the reason you sign a Credit Card reciept is even simpler: you are signing it to note to your credit card company (under their terms of service agreement) who authorized a purchase, you are not signing it to gain trust that you will pay or even actually agreeing to pay the company name on the reciept! Instead, the trust relationship that "you" will pay that money was established not between you and the cashier at the time of signature, but between the cashier's company and your credit card company in their contract. Let me put that this way: when you sign a credit card receipt, the company that didn't get the money can't go to you and get the money directly should you not pay it. They must go to your credit card company, because that is who they have the payment contract and trust relationship with.

So the fun thing here is that unless your service agreement with your CC company says otherwise you are free to authorize it with any signature you wish, it doesn't have to be curly squiggles representing your "name"... or even delegate authorization to someone else. If you want someone else to make a purchase for you, you are free to give someone your card and (again, within the bounds of your service agreement) authorize the purchase with their own signature. You are going to need to know and trust your friend's signature, though. That's also a reciept that you will definitely want to keep for some time, obviously. This is a cool right to have, and one worth continuing to fight for (with continued fraud fighting it is one of those that could disappear through the cracks). Why don't more people use weird signatures or delegate authorization? Mostly fear of magic. The sky will not fall should you do so. What you will have to deal with is in correctly verifying (or getting others to vouch for) a signature in Court. You will also have to deal with worried merchants that might not want to take a weird signature or a delegated signature. They are free, to help protect their own ass from fraud, to refuse to accept either. (Again, its a vanishing right... unintelligently comparing a signature on the back of the card to the one on the reciept is just much easier than actually getting to know and trust people. I'll leave that for another rant.) However, you are just as free to be big a big jackass about it, ask to speak to manager, ask the manager to call your friends up to help validate your authentication of the reciept, and threaten to take your business elsewhere. (Same thing with ID validation and checks, unless mandated by a state law.)

Again, to underline the signature is not trust issue: other than through my identification to my banking institution, Visa has no idea of my actual signature and whether to trust it or not other than via the back of my card and any copies of documents filed with them. They are trusting my bank to provide accurate information about me. My bank is trusting the State government that put together the ID information associated with my account. In the purely theoretical world, to prove my signature is my authentication a court would have to establish a trust relationship with people (make them witnesses to the court) in close trust relationships with me that know my signature, and would similarly have to take my word for it whether or not I made that my authorization. In the real world most states have ID laws that connect your legal ID to a particular signature and the trust relationship of "being a resident of this State" binds that signature, so that in the indirect relationship mentioned above the CC company can trust the State to provide accurate signature information to check a signature against. Thus a court could say (under the state law) that a signature matches your ID signature and thus is valid and binding. If they don't match, there is no binding and you have nothing to worry about... other than state fraud laws if the court can prove anything of the sort. The concept of "match" is sticky, too... The moral of the story: don't trust signatures. Merchants are free to ask that a signature match the one on someones ID (as long as they trust the state from which the ID came), but that really won't help them in a dispute... what would help them more is to ask the customer whether or not they really intend to make the purchase. If you have my signature you are going to have (or at least, should have) a hell of a harder time convincing a jury that the signature was in fact mine; whereas I will have a much easier time proving that I did indeed authenticate a document personally, no matter what the signature. This is exactly how things should be and what signatures were originally meant for (the whole innocent unless proven guilty thing), and so much current fraud protection is focused the wrong way round.

So, now that I've provided some basic idea of what a signature does and does not represent, I'll return to the subject at hand in the Slashdot article... that of code signing. The tough thing about code signing is that too many people misunderstand what a signature on a piece of code represents. A code signature is little different than a real world signature. It doesn't provide any security, it only authenticates an existing trust relationship. (There is a reason that the trademarked name for code signing in the Microsoft frameworks is Authenticode.) I'll use the points of the article-referenced book (from Bruce Schneier), partly because I fear quoting a random slashdotter and partly because Schneier is an "expert".

#1) Users have no idea how to decide if a particular signer is trusted or not.

Trust is not a job of a signature. Signatures have no inherent trust. They are for authentication.

#2) Just because a component is signed doesn't mean that it is safe.

Same problem, different wording. Code safety is a matter of trust, thus a problem for some other system. (Such as managed code analysis and sandboxes.)

#3) Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.

Repeat after me: same problem, different wording; code safety is a matter of trust, thus a problem for some other system. Secondly, this particular problem of bad interactions is an inherent flaw in modern computers... 80% of good software design is in learning how to avoid it (and most people never learn). As long as we are using finite register-based computers we are going to have the possibility for occaisional harmful interaction. Ask any assembler programmer about "side effects" they've spent hours tracking down, and most of those are interactions within sections of a single "program".

#4) "safe" is not all-or-nothing thing; there are degrees of safety.

Repeat after me: same problem, different wording; code safety is a matter of trust, thus a problem for some other system.

#5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.

This is almost but not quite an actual issue. It is still a matter of trusting the code, which a signature will not provide trust (it only authenticates for an existing trust relationship). On the other hand, you might claim that a destroyed authentication token is an authentication problem. However, signatures have never been guaranteed to continue to exist. The scenario as written is basically: someone could write an arson letter, sign it himself, use it to walk into a fire department so that he can talk about the person that wants to start the fire just so that he could set the fire house on fire and with it the letter. It's somewhat ridiculous. Even if the letter isn't burnt, you are still going to have to prove to a court (and a jury, beyond a shadow of a doubt) that the guy did indeed sign that letter himself, after, of course, you've gotten enough evidence to figure out who that guy is in the first place, even assuming you could count on the signature to find the guy (which I guess you can somewhat rely on a state's ID database). Anyway, I think you get the point: this was a violated trust relationship and the fault of some other system other than the authentication.

So, there you have my basic treatise on Authentication and the Calculus of Trust Relationships. I hope someone found it interesting and informative into why code signatures are good signatures for code, as long as you understand what signatures are made to represent (authentication). A signature says, "Yes, if you know my signature: I did indeed do this"... nothing more. Trust always comes from somewhere else.