Rosewater

legal vs crypto definition of non repudiation

Looking at my logs the other day, I noticed that my post on the problems with non-repudiation briefly snuck into googles top 20 results for non-repudiation -- very surprising. Perusing the other results I ran across this article on non-Repudiation in FirstMonday. They compare the common law definition of repudiation to the crypto definition: So, seems clear that crypto non-repudiation only really deals with the first case above (signature is a forgery), and that only poorly. [via Carl Ellisons Rant on Non-Repudiation]

carol coye benson on federation and liability transfer

Carol Coye Benson of Glenbrook Partners has a article, Liability and Federated Identity: Much Ado About Nothing on why Federated identity probably may not live up to expectations: they will likely never provide a basis for transferring liability for between the parties to an on-line transaction. But, as she points out, this probably won't matter. This is the thing I think most security wonks miss -- it's tilting windmills to try to make risks disappear or to transfer them all away. But this doesn't mean you can't do business. It just places a burden on you as the business manager to understand the risks and how they affect the prospects of turning a profit. Its perfectly reasonable to take an informed risk, and often significantly cheaper than trying to eliminate the risk altogether.

theory and practice of ssl

This article on the practical problems with SSL is right on the money. Not only is SSL solving the wrong problem, it's doing it poorly. The problems here aren't completely unique to SSL. All PKI based systems (including those incorporated in WS Security and SAML) suffer from them to greater and lesser degrees. I'm always surprised that security folks still start with X.509 certs as their primary use case. Too hard and too expensive for too little real reduction of risk.

repudiating non-repudiation

One of the most frequently sited benefits of public-key based digital signatures is that they are theoretically non-repudiable. Unlike conventional cryptography, where the same key is used to encrypt and decrypt, public key crypto uses a pair of keys: one that encrypts and one that decrypts. The advantage of this is that the originator can create a key pair, keep one key private and make the other public. When the holder of a private key encrypts a document with the private key, people can verify the that the encrypted document came from the holder by simply decrypting it with the public key from the key pair. In practice, digital signatures are a bit more complicated, but that's the core of it. With conventional crypto, the encrypter would be able to deny having encrypted the message: the sender has to know the encryption key in order to decrypt it, so they might also have been the one to encrypt the document. With public key crypto, the holder can't deny having creating the encrypted document -- only they have the private key, after all. Very cool, right? Unfortunately, that's just the theory. The practice is significantly less elegant. To turn the theory into practice, your ability to rely on non-repudiation hangs on your ability to do three things right: implement the technology, put in place proper business practices and agreements, and make your case in court. So, there are three questions you should ask: Relative to other means, how much does using digital signatures lower my risk over other technologies? how much will it cost me to setup up and operate a the business end? how will my chances in court be affected? If you're not put off by your answers to the first two questions, then you should definitely take a long, hard look at the third question. While the signer may not be able to deny that their private key was used to sign the document, they may be able to repudiate the signature on a host of other grounds: They didn't keep their key secure and someone stole it; they didn't understand their obligation under their user agreement to keep the key secure; they didn't understand what authority they had granted signatures generated with their private key, etc. I suspect you'd have better luck enforcing an agreement built around usernames and passwords than you would one built around private keys and digital signatures. So, what technology would give you the biggest return (reduction of risk) on your investment? The theory of non-repudiation is great, in practice, it tries to do something that is unnatural: it tries to transfer all the risk of a transaction to one party -- the signer. My bet is that you get better returns by accepting a more natural distribution of risk.

The history of your threat model

Ian Grigg posted a screed about how the threats SSL is intended to counter (network eaves dropper) are not the most common threats that web users actually face (trojans, worms, and other host-based security problems). He talks about the need for page based security, rather than connection based security. Historical note: at one point there was a page-based alternative (SHTTP) but it was more expensive and not backed by the winning team. Due Diligence provides a history of the SSL threat model, blaming it on bad business strategy. Unfortunately, the account is factually wrong on several points. STT wasn't Microsoft's answer to SSL. Microsoft already had, actually, already implemented SSL. In fact, Microsoft and Netscape had even managed to do some interop testing by the time STT was under way. STT was a joint project between Visa and Microsoft. It was Microsoft's attempt to get a piece of each credit card transaction on the Internet; it was Visa's effort to beat MasterCard to the punch and gain market share. Rumor had it that Visa had given Microsoft some favorable terms in exchange for an exclusive arrangement. Not to be left out, MasterCard teamed up with IBM, Netscape, GTE, and Cybercash to create their own protocol, SEPP. As it happens, MasterCard and Visa are both directed by the banks they serve, and those banks (many of whom offered both Visa and MasterCard), weren't keen on implementing two similar technologies (especially given all the infrastructure they required). It quickly became clear that this was not an area where Visa and MasterCard were welcome to compete. And, thus, SET was born -- even American Express and Discover were invited to the table. It was initially was a simple merging of the two protocols, but quickly expanded to cover all the specific requirements of each of the credit card associations. And this was it's downfall, because, at the end of the day, the card associations weren't the customer for this: the merchants and the member banks were. While SET did a great job of covering the risks the card associations were worried about (e.g. merchant fraud, stolen cards), it did nothing for the banks or the merchants, who were expected to pay the majority of the cost to implement SET. It didn't help SETs case that it was slow out the gate: by the time it was ready, consumers had ample opportunity to become comfortable with the risks of the internet (which, in point of fact, were small -- merchant's eat fraudulent transactions on internet and phone orders). Merchants had also gotten a sense for what fraud would cost them and found that there were cheaper ways to mitigate the risk (e.g. checking for real email and street addresses) than SET. So, SET was DOA. I know this because I had a small to role to play in these events -- a great experience to have early in my career. Great lessons learned, the most significant of which was cool technology is nice, but if you don't know who your customers are and understand their needs, you're wasting your time. WRT to Ian Griggs post: From my point of view, SSL was never really intended to address the risks we know of today. The funny thing was that the risks that people were afraid of on the internet were largely not an issue -- already well handled by the credit card processing model (which distributes risk to those who benefit the most and are in the best position to make informed decisions). SSL was just the placebo for the thing that people found most unnerving -- dangling their private bits out on the new and unknown internet.