How to achieve non-repudiation?

Question

If I have a message that I need to send to another person, how do I achieve non repudiation ?

Is digitally signing the message sufficient ?

Answer 1

No. Digital signatures are not sufficient for non-repudiation -- not by a long shot.

Non-repudiation is a legal concept. It means that, if there is a dispute, in a lawsuit it will be possible to hold one party to their commitments.

For example, mathematical schemes that claim to provide non-repudiation have to withstand the "jury attack". Some expert witness is going to have to be able to explain, in non-technical terms that an ordinary juror (and judge) can understand, why the mathematics proves anything at all. Meanwhile, an expert witness for the other side is going to be arguing the opposite. If the scheme uses fancy mathematics, it is likely to be incomprehensible to the jurors and the judge, and hence not likely to be of much use in a lawsuit. This is a kind of attack that most mathematical schemes in the literature are unlikely to be able to stand up to.

I'm afraid much of the cryptographic research community has screwed this up. Researchers have written many technical papers that claim to address "the non-repudiation problem", trying to solve it with mathematics -- but what they've failed to accept is that there is a tremendous gap between the crypto-mathematics and the pragmatics and legal issues. And unfortunately, the hardest part of the problem to solve is not the mathematics, but rather the pragmatics and legal issues. Unfortunately, this seems to be a long-standing blind spot within the cryptographic research community.

Here are some of the challenges to achieving true non-repudiation that a court or lawyer would be satisfied with:

• Malware. What if Grandpa's computer is infected with malware, which steals his private key? Are we going to hold him responsible for anything signed by that malware -- even if it means he loses his house? That'd be ridiculous. In particular, an easy way to repudiate is simply to claim "my private key must have been leaked/stolen".

  Similar remarks can be made about social engineering. When social engineering attacks have a good chance of being successful at stealing the private key, and when the scheme is designed in such a way that ordinary people cannot use it securely, and when the designers know (or should have known) this, I think it is questionable whether jurors will be willing to hold Grandpa responsible, simply because he got screwed by a poorly-designed security system.

• Humans vs. computers. Legally, non-repudiation is about the actions of a human. A court is going to be looking for evidence that a human (e.g., Grandpa) assented to the terms of the contract/transaction. The cryptographic schemes cannot achieve that. They can only show that some computer performed some action. Cryptographers like to assume that the computer acts as an agent of the human and the computer's actions can stand in for the human's actions, but this is not a reasonable assumption. For example, malware on the person's computer can apply the private key without the human's consent.

  Basically, most of the cryptographic research into non-repudiation schemes has the wrong threat model. It is based on assumptions that we've since discovered are faulty.

If you'd like to learn more, there has been a great deal published on these gaps between what's called "non-repudiation" in the cryptographic literature vs what lawyers would accept as adequate. Here are some example publications where you can read more:

• Carl Ellison, Non-repudiation.

• Ross Anderson, Liability and Computer Security: Nine Principles.

• Brian Gladman, Carl Ellison, and Nicholas Bohm, Digital Signatures, Certificates and Electronic Commerce.

• Adrian McCullagh and William Caelli, Non-Repudiation in the Digital Environment.

• Michael Roe, Cryptography and Evidence.

• Peter Gutmann, Digital Signature Legislation.

• Greg Broiles provides a legal perspective on non-repudiation.

Answer 2

Non-repudiation is about having a proof that the announced author really wrote the message -- and such the proof can be verified even without the consent of the said author: the author must not be able to repudiate his message.

This calls for asymmetric cryptography (since verification can be done without the author consent, it cannot use whatever secret keys the author may own), namely digital signatures, which are the tool meant for that.

However, with a digital signature, you have only done half of the work, and that's the easy half. The digital signature does not tell you: "the author is Bob". It tells: "the author is whoever controls the private key associated with this public key". You still must have a way to reliably (in the sense of: in a way acceptable as a proof) link Bob's public key with Bob's identity. This is where certificates come into action. A certificate is a piece of data which contains an identity ("Bob") and a public key, and is signed by a "Certification Authority": the CA, when it signs the certificate, says: "this is the public key owned by that guy". Since the CA uses itself a digital signature, it also falls under the scope of non-repudiation: the certificate "proves" that the public key is Bob's only insofar as the CA is honest and used reliable procedures (e.g. meeting Bob face-to-face with ID card verification) to establish the link between the key and Bob. If the CA fails, the wrong certificate can be used to sue the CA. On a practical point of view, the main interest of the CA is that the certificate can be verified automatically, and knowing a single CA public key is sufficient to validate the millions of certificates that the CA produced. Web browsers do that, when they connect to a HTTPS site: they validate the server's certificate against the "root CA" which are hardcoded in the browser code (or in the operating system). A few dozens of root CA public keys are sufficient to verify the whole Internet.

Bottom-line is that while digital signatures are the proper cryptographic tool to use, most of the solution is non-cryptographic; it is mostly a matter of procedures and an awful lot of lawyer-compatible papers.

Answer 3

It also helps if there's some assurance that you're the only one who has access to the private key used to sign the message. For example, non-repudiation is harder to assert if a copy of the private key is also held by some kind of key escrow service, because you could always claim "I didn't sign the message, it must have been an evil sysadmin with access to the escrow database".

X.509 certificates have a "non-repudiation" bit in the keyusage attribute, to identify the intended use of the key. rfc5280 talks about this.

Answer 4

None Repudiation refers to having proof of any transaction made from the requester to the authoriser and also from the authoriser to the requester. this is an electronical proof that will have information of the person who made any transaction.

eg: a client will go to a bank and request to change a password for his/her bank account, the teller or the authoriser will assist the client but will have to login to the system by using biometrics, this is to ensure the identification of who was assisting the client in case anything goes wrong with the client's bank account then the investigation team can track down who was in charge of the client's bank account, because this is a biometric application, the authoriser cannot deny any accusation being pointed to him/her should there be any form of fraud on client's bank account.

The client would also use the biometrics application just to ensure that he/she really did come to the bank and make that change request, at times a bank account holder would send someone over to the bank to make changes on sensitive information, the use of the none Repudiation would be used as a proof to ensure identification of who came to the bank and made change request should there be any form of fraud to the client's bank account details.

There will be a vault (report) on any change of sensitive data which will show all the information before it was changed and after a change request was made. This report will also show details of the client who made change request and also details of the authoriser who authorised changes made by the client. this report can be used by investigating team when any fraud has been reported on client's bank account after the change was made.