Re: Sender and receiver non-repudiation
all true it was part of the original point ... which was that much of the writing about security in conjunction with digital signatures all have to do with the responsibilities of certification authorities. However, it is possible to have a totally insecure infrastructure with the best certification authority along with their best policies and practices ... and still have a situation like the "Emperor's new clothes". It is further possible to have a terrible secure infrastructure with secure chip-card, secure public/private keys, secure display, secure processes, along with trusted digital signatures ... and have absolutely no certificates. In lots of cases, you can treat certification authorities and certificates as totally orthogonal to the issues involved in trusting digital signatures. some random refs: http://www.garlic.com/~lynn/subtopic.html#fraud http://www.garlic.com/~lynn/subtopic.html#privacy http://www.garlic.com/~lynn/subtopic.html#sslcerts http://www.garlic.com/~lynn/subtopic.html#radius - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
At 08:55 AM 7/3/01 -0700, [EMAIL PROTECTED] wrote: >signing. With digital signatures it becomes murkier ... how does somebody >know that what they are looking at is the same thing that the computer is >calculating a digital signature for. Good point. There's no way without a trusted host somewhere. Imagine that you scanned the paper doc, inspected it visually, and digitally signed the image file. Even this is succeptible to a trojan that alters the display, alters what's printed, etc. If you do have a little trusted island, e.g., a java button on a ring you wear in the shower, or a PDA display you trust, you can often leverage this to make a trusted system. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
On Tue, 3 Jul 2001 [EMAIL PROTECTED] wrote: > there is even simpler "misappropriation" ... that of virus on the machine > ... how do you really know what your computer is doing. The more control you have over your machine, and the environment, the more security you have. By hiding sensitive tasks into armored compartments you can push this way further, making it sufficiently secure for all practical purposes. > with paper signatures it is somewhat more clear-cut that the person > signing a document ... is actually looking at the document they are > signing. With digital signatures it becomes murkier ... how does somebody But you are looking at a representation of a document, as rendered in the frame buffer. If you're worried about your machine being compromised, either use armored crypto hardware protected by clean protocols/interfaces, or an air gap protected machine containing only the barest OS essentials and crypto binaries, only transferring _passive_ (thanks to MS, it's essentially just plain ASCII) documents via sneakernet. For practical purposes you would use a smart card with a crypto processor on it. I personally think it would be interesting to see what can be done with polymer/OLED frame buffers printed directly on the top of a deep embedded, which does both video and crypto directly in the framebuffer compartment, and only talks via a fast packet switched network to the rest of the (wearable) computer. The less code and state is in there, the less potential for exploits. > know that what they are looking at is the same thing that the computer is > calculating a digital signature for. -- Eugen* Leitl http://www.lrz.de/~ui22204/";>leitl __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
there is even simpler "misappropriation" ... that of virus on the machine ... how do you really know what your computer is doing. with paper signatures it is somewhat more clear-cut that the person signing a document ... is actually looking at the document they are signing. With digital signatures it becomes murkier ... how does somebody know that what they are looking at is the same thing that the computer is calculating a digital signature for. in retail situations, the burdon of proof is typically with the institutions to disproove any claims of forged signature. some of the draft digital signature laws (associated with certificates and certification authorities) started out trying to move that burden of proof to the consumer (i.e. most of the laws don't so much talk about "non-repudiation" per se ... they talk about disputes and who has the burden of proof and the standards for burden of proof). Some of these somewhat implied that a certificate was sufficient proof ... somewhat ignoring there could be thousands of foibles that might result in a digital signature not being what the key owner expected. business issues typically are associated with amount of risk ... aka how hard is it to defeat or compromise some system, how hard is it to show intent, etc. random refs: http://www.garlic.com/~lynn/2001g.html#25 Root Certificates http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000) http://www.garlic.com/~lynn/ansiepay.htm#anxclean Misc 8583 mapping cleanup http://www.garlic.com/~lynn/2000f.html#64 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
On Tue, 3 Jul 2001, Panayiotis Kotzanikolaou wrote: > The problem in this scheme is that Bob signs and sends the proof after > he has received M. Bob can receive M and never send a receipt. > > By using a trusted delivery service, it is easy to produce > non-repudiation evidence both for the sender and the receiver. > Is there any cryptographic protocol that "forces" Bob to produce > non-repudiation evidence during execution? Answering only to this concrete question: the kind of things you want are accomplished by contract signing protocols. A few recent papers: Optimistic Protocols for Fair Exchange(N. Asokan, Matthis Schunter, Michael Waidner, 1996) Optimal Efficiency of Optimistic Contract Signing(Birgit Pfitzmann, Matthias Schunter, Michael Waidner, PODC 98) Optimistic synchronous multi-party contract signing(N. Asokan, Birgit Baum-Waidner, Matthias Schunter, and Michael Waidner, dec 1998) Asynchronous protocols for optimistic fair exchange(N. Asokan, Victor Shoup, Michael Waidner, may 1998) Optimistic asynchronous multi-party contract signing(Birgit Baum-Waidner and Michael Waidner, nov 1998) Optimistic fair exchange of digital signatures(N. Askon, Victor Shoup, Michael Waidner, oct 1999) Abuse-free Optimistic Contract Signing(Juan Garay, Markus Jakobsson, Phil MacKenzie, CRYPTO '99) Abuse-free Multi-party Contract Signing( Juan Garay, Phil MacKenzie, DISC '99) Provable Secure Certified Mail(Birgit Pfitzmann, Matthias Schunter, Michael Waidner, 2000) Analysis of Abuse-Free Contract Signing( Vitaly Shmatikov, John C. Mitchell, 2000) 06/23/01 Optimistic Asynchronous Multi-Party Contract Signing with Reduced Number of Rounds(Birgit Baum-Waidner, eprint 2001/044) (you can find links to them at http://www.tml.hut.fi/~helger/crypto/link/protocols/contract.html) Answering more generally: it does not help you to get non-repudiation. Nothing does, unless Bob is able to prove that you signed this document consiously, being sober, and generally, that you MEANT to sign it. Helger - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
The problem you are referring to is known as 'selective receipt' (where a party acknowledges only messages it wishes) and generally there are two ways to overcome it: a. make use of an incremental disclosure protocol over many rounds where in each round some knowledge about the message and the receipt acknowledgement are transmitted. If any party aborts the execution of the transaction prior to completion then both parties have comparable information (one party has an incomplete message and the other an incomplete receipt acknowledgement). This method however suffers from the fact that requires many rounds and also assumes the two parties have equal computational power. b. make use of a TTP that is somehow involved in the message exchange and guarantees the production of evidence about the actions that have taken place. Such TTPs can be: - inline, where all communications between the two parties go through the TTP - online, where production of evidence requires the TTP to be online for the duration of the transaction, but communication between parties does not take place via the TTP - offline, where the TTP does not need to be present during the execution of the transaction but is otherwise somehow involved, e.g. a Certification Authority You might want to take a look at the following (by no means an exhaustive list): 1. ISO/IEC 10181-4. Information technology - open systems interconnection - security frameworks for open systems, Part 4: Non-repudiation framework, 1997. 2. ISO/IEC 13888-1. Information technology - Security techniques - Non-repudiation - Part 1: General, 1997. 3. ISO/IEC 13888-2. Information technology - Security techniques - Non-repudiation - Part 2: Mechanisms using symmetric techniques, 1998. 4. ISO/IEC 13888-3. Information technology - Security techniques - Non-repudiation - Part 3: Mechanisms using asymmetric techniques, 1997. 5. J. Zhou and D. Gollmann. Evidence and non-repudiation. Journal of Network and Computer Applications, 1997. 6. J. Zhou and D. Gollmann. A fair non-repudiation protocol. Proceedings of 1996 IEEE Symposium on Research in Security & Privacy, 1996 7. J. Zhou and D. Gollmann. Observations on non-repudiation. Advances in Cryptology - Asiacrypt 96, 1996. 8. J. Zhou and D. Gollmann. An Efficient Non-repudiation Protocol. 10th Computer Security Foundations Workshop, IEEE Computer Society Press, 1997. 9. T. Coffey and P. Saidha. Non-Repudiation with Mandatory Proof of Receipt. ACM Computer Communication Review, 26(1), 1996. Regards, Dimitrios Petropoulos > It is well known that digital signatures can be used to ensure > non-repudiation of the sender in message exchange. > > Say that Alice (A) sends to Bob (B) a mesage M. If Alice sends to Bob a > signed receipt of the message sent, then Alice cannot refuse of having > send the message. > A-->B: M, SIGN_A(A sends M to M) > > Now if Bob receives the message and replies with a signed receipt > B-->A: SIGN_B(B received M from A) > then Bob cannot later refuse of having received the message M. > > The problem in this scheme is that Bob signs and sends the proof after > he has received M. Bob can receive M and never send a receipt. > > By using a trusted delivery service, it is easy to produce > non-repudiation evidence both for the sender and the receiver. > Is there any cryptographic protocol that "forces" Bob to produce > non-repudiation evidence during execution? > > > > [Your exposition is filled with statements lots of people might take > issue with, like the concept that Alice "cannot" deny sending the > message. What if Alice claims it wasn't her key, or her key was stolen > or misappropriated, or what have you? One lesson I've learned -- you > cannot perfect law with technology, or eliminate business risk with > law. --Perry] > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to > [EMAIL PROTECTED] - Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Sender and receiver non-repudiation
A 1997 paper might be of great help for you: Asokan, Victor Shoup, and Michael Waidner. Asynchronous protocols for optimistic fair exchange. Research Report RZ 2976 (#93022), IBM Research www.zurich.ibm.com/csc/infosec/publications/bibliography/ In this paper, there is a trusted third party (TTP), which is used optimistically. This means that TTP is only invoqued if something goes wrong. Although used in the context of contract signing, this approach can be used in the "certified delivery" context. = Emmanouil Magkos Department of Informatics University of Piraeus 185 34 Piraeus, Greece tel (1): +30 1 2113090 tel (2): +30 1 4142134 fax: +30 1 4142264 mobile: +30 945 075815 e-mail: [EMAIL PROTECTED] = > It is well known that digital signatures can be used to ensure > non-repudiation of the sender in message exchange. > > Say that Alice (A) sends to Bob (B) a mesage M. If Alice sends to Bob a > signed receipt of the message sent, then Alice cannot refuse of having > send the message. > A-->B: M, SIGN_A(A sends M to M) > > Now if Bob receives the message and replies with a signed receipt > B-->A: SIGN_B(B received M from A) > then Bob cannot later refuse of having received the message M. > > The problem in this scheme is that Bob signs and sends the proof after > he has received M. Bob can receive M and never send a receipt. > > By using a trusted delivery service, it is easy to produce > non-repudiation evidence both for the sender and the receiver. > Is there any cryptographic protocol that "forces" Bob to produce > non-repudiation evidence during execution? > > > > [Your exposition is filled with statements lots of people might take > issue with, like the concept that Alice "cannot" deny sending the > message. What if Alice claims it wasn't her key, or her key was stolen > or misappropriated, or what have you? One lesson I've learned -- you > cannot perfect law with technology, or eliminate business risk with > law. --Perry] > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
