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 ?
migrated from stackoverflow.com Jan 21 '11 at 8:40
This question came from our site for professional and enthusiast programmers.
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:
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:
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.
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.
None Repudiation referes 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 incase anything goes wrong with the client's bank account then the investigation team can track down who was incharge of the client's bank account, because this is a biometric application, the authoriser cannot denie any accusations 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 dat 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 sensetive 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 shuold there be any form of fraud to the client's bank account details.
There will be a vault (report) on any change of sensetive 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.