SOA Security – The Myth of Non-Repudiation

In this article I explain why (in my non-qualified opinion as a non-lawyer) I think most people are wasting their time when they worry about non-repudiation of SOA messages.

The purpose of non-repudiation in business is to try and make sure someone can't welch on a contract. The idea being that when you send a SOA message you are, in effect, entering into a contract and so you want some kind of non-repudiation measure to make sure that the sender of the message can't come back later and say "I never sent that message and I'm not paying for the 10,000 widgets it ordered either!".

When you talk about non-repudiation most geeks will immediately start discussing digital signatures and encryption technology. But near as I can tell (and I'm no lawyer) there is no need to use encryption technology to get non-repudiation and anyway the biggest problem one will have in court is probably not proving who sent the message but proving what it is both parties agreed to when the message was sent.

So unless you intend to have an army of lawyers drive your software development process you are all but sure to be better off not worrying about non-repudiation.

What is a Digital Signature, legally speaking?

In Geek land digital signatures are all about encryption, public and private keys, cryptographically secure hashes, etc. Making all of this work is, of course, non-trivial. It requires a lot of infrastructure to generate and disseminate keys as well as to maintain the keys, ensure proper access, deal with revocations, etc. Therefore using digital signatures is far from free in practice.

But, you see, here is the funny part. geeks, being geeks, just worry about the technology. But notice the point of this exercise – to enforce a 'contract' in court. The use of digital signatures in SOA is therefore not about technology but about the law and the law has some interesting things to say on the matter.

First of all, it is far from clear that one needs a digital signature in order to make a message non-repudiable for legal purposes. Have you had experience lately signing up for an on-line service where you were asked to just type in your name as your 'digital signature'? Or filling out a form that included a notice by the post button saying that by pressing this button you are electronically signing the form and agreeing to its contents? These, of course, aren't digital signatures in the encryption sense but near as I can tell they are digital signatures in the legal sense.

Watch this part carefully because it will make all the Geek's heads hurt. While digital signature are legally enforceable in the U.S. and I believe Europe the legal term 'digital signature' seems to just mean 'some identifying mark sent electronically'. In other words when geeks say 'digital signature' they mean cryptography but that isn't what the law necessarily means when it says 'digital signature'. We have two groups using the same phrase to mean two different things.

I can already hear the geeks screaming "but you can fake that other stuff!". Well, yes, you can, but you can fake physical signatures too. It turns out the legal system has dealt with such problems for a very long time. While this may offend our Geek sensibilities it is how the world appears to work.

BTW, just to confuse things even more some states in the U.S. have different definitions of digital signatures than others. California actually takes a pretty reasonable approach and defines the qualities a digital signature must have rather than the specifics of how it is to be implemented. But keep in mind that these laws are apparently not exclusive. That is, if you can reasonably show to the satisfaction of the court that a message came from a specific source than that message can be considered binding. There have apparently already been several cases involving e-mail in various jurisdictions around the world where courts took e-mails to be legally binding. Besides, near as I can tell, most of the more restrictive digital signature laws have yet to be tested in court so their meaning in practice is still unknown.

Contracts, it depends on what the meaning of the word "is" is

But wait, it gets better. Let's say the message is signed following the strictest legal standards available, the sender welched and now you are ready to nail the jerk in court! But here's the thing, have you ever been involved in a contract negotiation? If you haven't you should try it at least once. Yes, the experience is right up their with root canal but the pain goes away quickly and you will learn some important lessons (such as: don't get involved in contract negotiations). The first thing you will notice about a contract negotiation is that most of the people in the room are lawyers. The next thing you will notice is that the lawyers don't speak English and they like to use red pens. But the point is that the actual process of negotiating a contract is a long and painful one.

The reason for the pain is that badly written contracts create ambiguities that courts are happy to resolve in a process that one lawyer once described to me as being akin to roulette. The result often seems to be more about chance (what judge you get, what jury, if there is one, etc.) than about the quality of your case.

This is why contracts tend to be written down and tend to involve a lot of lawyers ahead of time. It turns out that paying lawyers upfront is significantly cheaper than paying them in court.

All of which brings us back to SOA. For, you see, when you take your digitally signed message to court what you are doing is trying to enforce a contract. Except, um, how many lawyers did you have examine that message before you defined it in your software? How many legal reviews did it actually go through? Did you ever discuss it with the message sender's lawyer's ahead of time? I'm guessing the answer to these questions is generally – 'no'. Which means that no one, in a legal sense, really knows who agreed to what. Trying to enforce your 'contract' in court is quite likely to do little else than provide a lot of money to a lot of lawyers.

Conclusion

The legal burden of proof for a digital signature (in the legal sense) doesn't seem to be, in most cases, anywhere near the burden of proof expected by digital signatures (in the geek sense). And besides, even if the legal burden proof was the same as the geek burden of proof the real pain is likely not proving who sent the message but proving what they meant when they sent it. Unless armies of lawyers are involved in your software development process then non-repudiation is probably not worth much thought.

7 thoughts on “SOA Security – The Myth of Non-Repudiation”

  1. There are others aspects to this as well. Take B2B in the electronics manufacturing sector as an example. The pattern is usually large buyers connecting to small suppliers. The small suppliers are usually dependent on the business of one or two of these large suppliers. If one of these suppliers ever tried to repudiate one of its B2B messages (“I never promised you 5000 parts in Q3!”) the buyer isn’t going to go through the hassle of taking the supplier to court, they’re just going to stop doing business with them. This is more than enough incentive to keep the suppliers honest. For their part the buyers have already pushed the suppliers into the lowest possible profit margins so they have little incentive to play games with them.

    Non-repudiation seems like a cool idea but, in this case (and I suspect many others), there are already business structures in place that make the use of non-repudiation services unnecessary. This is not to say that non-repudiation is *never* necessary, but I suspect that the cases where it is needed are relatively few.

  2. I think you are quite right. However, digital signatures have a major function in a SOA context and that is to provide authentication of the sender. Although this can be done in other ways, only digital signatures can pass multiple servers and still authenticate. Data integrity is not too bad either.

  3. The interesting question is – who needs to authenticate the sender? If company X sends a message to company Y and uses say mutual auth via SSL then when company Y receives the message they can notate that it was received via an authenticated channel and call it a day, even if the message gets bounced around a bunch of places within company Y. From a legal perspective this appears to be more than sufficient (although I freely admit that the case law is thin).

    The point isn’t that digital signatures are always unnecessary, it’s just that most of the time most of the use cases for non-repudiation aren’t real.

    My personal expectation is that over time as the courts better understand the role of digital signatures it will become expected that they will be used in order to provide ‘reasonable’ security. But there is an educational process that has to happen first and it doesn’t appear to be happening very quickly.

  4. Thank you for the interesting a helpful discussion. Another interesting case is Health Information Exchange. You may not need to worry about nonrepudiation at the sender/receiver level when using secured channels, however you still need to worry about nonrepudiation of content of the message.

    1. The question is – what’s the legal bar for demonstrating responsibility for the content of the message? In many cases nothing more than a simple log file is necessary. So before using technology we first need to figure out if the use case requires that technology.

Leave a Reply

Your email address will not be published. Required fields are marked *