Contract-Signing Protocols John Mitchell Stanford TECS Week2005.

Slides:



Advertisements
Similar presentations
Multi-Party Contract Signing Sam Hasinoff April 9, 2001.
Advertisements

Impossibility of Distributed Consensus with One Faulty Process
Secure Multiparty Computations on Bitcoin
Lecture 3Dr. Verma1 COSC 6397 – Information Assurance Module M2 – Protocol Specification and Verification University of Houston Rakesh Verma Lecture 3.
CIS 725 Key Exchange Protocols. Alice ( PB Bob (M, PR Alice (hash(M))) PB Alice Confidentiality, Integrity and Authenication PR Bob M, hash(M) M, PR Alice.
Analysis of optimistic multi-party contract signing Rohit Chadha 1,2, Steve Kremer 3,4, Andre Scedrov 1 1 University of Pennsylvania 2 University of Sussex.
CSE331: Introduction to Networks and Security Lecture 22 Fall 2002.
6.852: Distributed Algorithms Spring, 2008 Class 7.
Computer Science Dr. Peng NingCSC 774 Adv. Net. Security1 CSC 774 Advanced Network Security Topic 3.3: Fair Exchange.
Distributed Algorithms – 2g1513 Lecture 10 – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks.
Eran Omri, Bar-Ilan University Joint work with Amos Beimel and Ilan Orlov, BGU Ilan Orlov…!??!!
Lect. 18: Cryptographic Protocols. 2 1.Cryptographic Protocols 2.Special Signatures 3.Secret Sharing and Threshold Cryptography 4.Zero-knowledge Proofs.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Probabilistic Contract Signing CS 259 Vitaly Shmatikov.
CSCI283 Fall 2005 GWU All slides from Bishop’s slide set Public Key Infrastructure (PKI)
CS555Spring 2012/Topic 161 Cryptography CS 555 Topic 16: Key Management and The Need for Public Key Cryptography.
CMSC 414 Computer and Network Security Lecture 6 Jonathan Katz.
Non-blocking Atomic Commitment Aaron Kaminsky Presenting Chapter 6 of Distributed Systems, 2nd edition, 1993, ed. Mullender.
1 Secure Failure Detection in TrustedPals Felix Freiling University of Mannheim San Sebastian Aachen Mannheim Joint Work with: Marjan Ghajar-Azadanlou.
ITIS 6200/8200. time-stamping services Difficult to verify the creation date and accurate contents of a digital file Required properties of time-stamping.
Optimistic Synchronous Multi-Party Contract Signing N. Asokan, Baum-Waidner, M. Schunter, M. Waidner Presented By Uday Nayak Advisor: Chris Lynch.
Advantage and abuse-freeness in contract-signing protocols Rohit Chadha, John Mitchell, Andre Scedrov, Vitaly Shmatikov To appear in CONCUR 2003.
C ontract signing Rohit Chadha, John Mitchell, Andre Scedrov, Vitaly Shmatikov.
Distributed Algorithms: Agreement Protocols. Problems of Agreement l A set of processes need to agree on a value (decision), after one or more processes.
Chapter 9 Cryptographic Protocol Cryptography-Principles and Practice Harbin Institute of Technology School of Computer Science and Technology Zhijun Li.
Analysis of optimistic multi-party contract signing Rohit Chadha 1,2, Steve Kremer 3, Andre Scedrov 1 1 University of Pennsylvania 2 University of Sussex.
Computer Science CSC 774Dr. Peng Ning1 CSC 774 Advanced Network Security Topic 2. Review of Cryptographic Techniques.
Alexander Potapov.  Authentication definition  Protocol architectures  Cryptographic properties  Freshness  Types of attack on protocols  Two-way.
Csci5233 Computer Security1 Bishop: Chapter 10 Key Management: Digital Signature.
Digital Cash By Gaurav Shetty. Agenda Introduction. Introduction. Working. Working. Desired Properties. Desired Properties. Protocols for Digital Cash.
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Andrew Lindell Aladdin Knowledge Systems and Bar-Ilan University 04/09/08 CRYP-202 Legally-Enforceable Fairness in Secure Two-Party Computation.
Contract-Signing Protocols J. Mitchell CS 259. Revised schedule uTuesday 1/24 Contract-signing protocols uThursday 1/26 Secure hardware architecture (XOM)
Chapter 4: Intermediate Protocols
CS 395T Contract Signing Protocols. Real-World Fair Exchange uBoth parties want to sign the deal uNeither wants to commit first Immunity deal.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
Analysis of a Fair Exchange Protocol Vitaly Shmatikov John Mitchell Stanford University.
Information Security Conference (ISC 2015) On the Efficiency of Multi-Party Contract Signing Protocols Gerard Draper-Gil, Josep-Lluis Ferrer Gomila, M.
Rational Exchange Levente Buttyán and Jean-Pierre Hubaux Swiss Federal Institute of Technology – Lausanne Laboratory for Computer Communications and Applications.
Based on Schneier Chapter 5: Advanced Protocols Dulal C. Kar.
Game-Based Verification of Fair Exchange Protocols CS 259 Vitaly Shmatikov.
Security protocols  Authentication protocols (this lecture)  Electronic voting protocols  Fair exchange protocols  Digital cash protocols.
Consensus and Its Impossibility in Asynchronous Systems.
Byzantine fault-tolerance COMP 413 Fall Overview Models –Synchronous vs. asynchronous systems –Byzantine failure model Secure storage with self-certifying.
CS294, Yelick Consensus revisited, p1 CS Consensus Revisited
CS 425/ECE 428/CSE424 Distributed Systems (Fall 2009) Lecture 9 Consensus I Section Klara Nahrstedt.
Sliding window protocol The sender continues the send action without receiving the acknowledgements of at most w messages (w > 0), w is called the window.
Network Security Continued. Digital Signature You want to sign a document. Three conditions. – 1. The receiver can verify the identity of the sender.
Chap 15. Agreement. Problem Processes need to agree on a single bit No link failures A process can fail by crashing (no malicious behavior) Messages take.
Two-Phase Commit Brad Karp UCL Computer Science CS GZ03 / M th October, 2008.
Alternating Temporal Logic and Game-Based Properties CS 259 John Mitchell with slides from Vitaly Shmatikov.
Lecture 5.1: Message Authentication Codes, and Key Distribution
SysRép / 2.5A. SchiperEté The consensus problem.
Private key
Key Management Network Systems Security Mort Anvari.
Alternating Bit Protocol S R ABP is a link layer protocol. Works on FIFO channels only. Guarantees reliable message delivery with a 1-bit sequence number.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
1 Authentication Protocols Rocky K. C. Chang 9 March 2007.
Probabilistic Contract Signing CS 395T. Probabilistic Fair Exchange uTwo parties exchange items of value Signed commitments (contract signing) Signed.
Consensus, impossibility results and Paxos Ken Birman.
Alternating Bit Protocol
Distributed Consensus
Distributed Consensus
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
EEC 688/788 Secure and Dependable Computing
Presentation transcript:

Contract-Signing Protocols John Mitchell Stanford TECS Week2005

Contract Signing uTwo parties want to sign a contract Multi-party signing is more complicated uThe contract is known to both parties The protocols we will look at are not for contract negotiation (e.g., auctions) uThe attacker could be Another party on the network The person you think you want to sign a contract with

Example uBoth parties want to sign the contract uNeither wants to commit first Immunity deal

Another example: stock trading Willing to sell stock at price X Ok, willing to buy at price X stock broker customer uWhy signed contract? Suppose market price changes Buyer or seller may want proof of agreement

Network is Asynchronous uPhysical solution Two parties sit at table Write their signatures simultaneously Exchange copies uProblem How to sign a contract on a network? Fair exchange: general problem of exchanging information so both succeed or both fail

Fundamental limitation uImpossibility of consensus Very weak consensus is not solvable if one or more processes can be faulty uAsynchronous setting Process has initial 0 or 1, and eventually decides 0 or 1 Weak termination: some correct process decides Agreement: no two processes decide on different values Very weak validity: there is a run in which the decision is 0 and a run in which the decision is 1 uReference M. J. Fischer, N. A. Lynch and M. S. Paterson, Impossibility of Distributed Consensus with One Faulty Process. J ACM 32(2): (April 1985).

FLP Partial Intuition uQuote from paper: The asynchronous commit protocols in current use all seem to have a window of vulnerability- an interval of time during the execution of the algorithm in which the delay or inaccessibility of a single process can cause the entire algorithm to wait indefinitely. It follows from our impossibility result that every commit protocol has such a window, confirming a widely believed tenet in the folklore.

Implication for fair exchange uNeed a trusted third party (TTP) It is impossible to solve strong fair exchange without a trusted third party. The proof is by relating strong fair exchange to the problem of consensus and adapting the impossibility result of Fischer, Lynch and Paterson. uReference H. Pagnia and F. C. Gärtner, On the impossibility of fair exchange without a trusted third party. Technical Report TUD-BS , Darmstadt University of Technology, March 1999

Two forms of contract signing uGradual-release protocols Alice and Bob sign contract Exchange signatures a few bits at a time Issues –Signatures are verifiable –Work required to guess remaining signature decreases –Alice, Bob must be able to verify that what they have received so far is part of a valid signature uAdd trusted third party

Easy TTP contract signing AB TTP signature contract uProblem TTP is bottleneck Can we do better?

Optimistic contract signing uUse TTP only if needed Can complete contract signing without TTP TTP will make decisions if asked uGoals Fair: no one can cheat the other Timely: no one has to wait indefinitely (assuming that TTP is available) Other properties …

General protocol outline uTrusted third party can force contract Third party can declare contract binding if presented with first two messages. AB I am going to sign the contract Here is my signature

Commitment (idea from crypto) uCryptographic hash function Easy to compute function f Given f(x), hard to find y with f(y)=f(x) Hard to find pairs x, y with f(y)=f(x) uCommit Send f(x) for randomly chosen x uComplete Reveal x

Refined protocol outline uTrusted third party can force contract Third party can declare contract binding by signing first two messages. AB sign(A, contract, hash(rand_A) ) sign(B, contract, hash(rand_B) ) rand_A rand_B

Optimistic Protocol [Asokan, Shoup, Waidner] M K Input: PK K, T, text Input: PK M, T, text m 1 = sig M (PK M, PK K, T, text, hash(R M )) m 2 = sig K (m 1, hash(R K )) m 3 = R M m 4 = R K m 1, R M, m 2, R K

uContract from normal execution uContract issued by third party uAbort token issued by third party Asokan-Shoup-Waidner Outcomes m 1, R M, m 2, R K sig T (m 1, m 2 ) sig T (abort, a 1 )

Role of Trusted Third Party uT can issue a replacement contract Proof that both parties are committed uT can issue an abort token Proof that T will not issue contract uT acts only when requested decides whether to abort or resolve on the first-come-first-serve basis only gets involved if requested by M or K

Resolve Subprotocol T K Net M r 1 = m 1, m 2 r2r2 aborted? Yes: r 2 = sig T (abort, a 1 ) No: resolved := true r 2 = sig T (m 1, m 2 ) r2r2 m 1 = sig M (… hash(R M )) m 3 = ???m 4 = ??? m 2 = sig K (… hash(R K )) sig T (m 1, m 2 ) sig T (abort, a 1 ) OR

Abort Subprotocol M m 2 = ??? K Network T a 1 = sig M (abort, m 1 ) a2a2 resolved? Yes: a 2 = sig T (m 1, m 2 ) No: aborted := true a 2 = sig T (abort, a 1 ) m 1 = sig M (… hash(R M )) sig T (m 1, m 2 ) sig T (abort, a 1 ) OR

Fairness and Timeliness If A cannot obtain Bs signature, then B should not be able to obtain As signature and vice versa Fairness One player cannot force the other to wait -- a fair and timely termination can always be forced by contacting TTP Timeliness [Asokan, Shoup, Waidner Eurocrypt 98]

B A m1= sign(A, c, hash(r_A) ) sign(B, m1, hash(r_B) ) r_A r_B Agree A B Network T Abort ??? ResolveAttack? B A Net T sig T (m 1, m 2 ) m1m1 ??? m2m2 A T Asokan-Shoup-Waidner protocol If not already resolved a 1 sig T (a 1,abort)

Attack M r 2 = sig T (m 1, m 2 ) m 1 = sig M (... hash(R M )) m 2 = sig K (m 1, hash(R K )) m 3 = R M T r 1 = m 1, m 2 secret Q K, m 2 sig T (m 1, m 2 ) m 1, R M, m 2, Q K contracts are inconsistent!

Later... sig M (PK M, PK K, T, text, hash(R M )) K Replay Attack Intruder causes K to commit to old contract with M sig K (m 1, hash(Q K )) RMRM QKQK M K RMRM sig M (… hash(R M )) RKRK sig K (... hash(R K ))

Fixing the Protocol M K Input: PK K, T, text Input: PK M, T, text m 1 = sig M (PK M, PK K, T, text, hash(R M )) m 2 = sig K (m 1, hash(R K )) m 3 = R M m 4 = R K m 1, R M, m 2, R K sig M (, hash(R K ))

Desirable properties uFair If one can get contract, so can other uAccountability If someone cheats, message trace shows who cheated uAbuse free No party can show that they can determine outcome of the protocol

Abuse-Free Contract Signing A B PCS A (text,B,T) PCS B (text,A,T) sig A (text) sig B (text) [Garay, Jakobsson, MacKenzie] uPrivate Contract Signature Special cryptographic primitive B cannot take msg from A and show to C T converts signatures, does not use own

Role of Trusted Third Party uT can convert PCS to regular signature Resolve the protocol if necessary uT can issue an abort token Promise not to resolve protocol in future uT acts only when requested decides whether to abort or resolve on a first-come-first-served basis only gets involved if requested by A or B

Resolve Subprotocol B A Net T r 1 = PCS A (text,B,T), sig B (text) aborted? Yes: r 2 = sig T (a 1 ) No: resolved := true r 2 = sig A (text) store sig B (text) r2r2 PCS A (text,B,T) ??? PCS B (text,A,T) sig T (a 1 ) sig A ( text ) OR

Abort Subprotocol A ??? B Network T a 1 =sig A (m 1,abort) a2a2 resolved? Yes: a 2 = sig B (text) No: aborted := true a 2 = sig T (a 1 ) m 1 = PCS A (text,B,T) sig B ( text ) sig T (a 1 ) OR

B A PCS A (text,B,T) PCS B (text,A,T) sig A (text) sig B (text ) Agree A B Network T m 1 = PCS A (text,B,T) Abort ??? ResolveAttack B A Net T PCS A (text,B,T) sig B (text) PCS A (text,B,T) ??? PCS B (text,A,T) B T sig T (abort) abort AND sig B (text) abort Leaked by T Garay, Jakobsson, MacKenzie

Attack B PCS A (text,B,T), sig B (text) sig T (abort) PCS A (text,B,T) PCS B (text,A,T) T sig A (abort) sig T (abort) Leaked by T abort AND sig B (text)only abort

Repairing the Protocol B PCS A (text,B,T), PCS B (text,A,T) PCS A (text,B,T) PCS B (text,A,T) T If T converts PCS into a conventional signature, T can be held accountable

Balance No party should be able to unilaterally determine the outcome of the protocol Stock sale example: there is a point in the protocol where the broker can unilaterally choose whether the sale happens or not Balance may be violated even if basic fairness is satisfied! Can a timely, optimistic protocol be fair AND balanced?

Advantage Willing to sell stock at price X Ok, willing to buy at price X stock brokercustomer Must be able to ask TTP to cancel this instance of protocol, or will be stuck indefinitely if customer does not respond Can go ahead and complete the sale, OR can still ask TTP to cancel (TTP doesnt know customer has responded) Optimistically waits for broker to respond … Chooses whether deal will happen: does not have to commit stock for sale, can cancel if sale looks unprofitable Cannot back out of the deal: must commit money for stock

Abuse free: as good as it gets uSpecifically: One signer always has an advantage over the other, no matter what the protocol is Best case: signer with advantage cannot prove it has the advantage to an outside observer

Theorem uIn any fair, optimistic, timely contract-signing protocol, if one player is optimistic*, the other player has an advantage. * optimistic player: waits a little before going to the third party

Abuse-Freeness No party should be able to unilaterally determine the outcome of the protocol Balance No party should be able to prove that it can unilaterally determine the outcome of the protocol Abuse-Freeness [Garay, Jakobsson, MacKenzie Crypto 99] impossible

How to prove something like this? uDefine protocol Program for Alice, Bob, TTP Each move depends on –Local State (whats happened so far) –Message from network –Timeout uConsider possible optimistic runs uShow someone gets advantage

Key idea (omitting many subtleties) uDefine power of a signer (A or B) in a state s if A can get contract by reading a message already in network, doing internal computation if A can get contract by communicating with TTT, assuming B does nothing otherwise Power A (s) = uLook at optimistic transition s s where Power B (s) =1 > Power B (s) = 0.

Advantage (intuition for main argument) uIf Power B (s) = 0 Power B (s) =1 then This is result of some move by A –Power B (s) = 0 means B cannot get contract without Bs help The move by A is not a message to TTP –The proof is for an optimistic protocol, so we are thinking about a run without msg to T B could abort in state s –We assume protocol is timely and fair: B must be able to do something, cannot get contract B can still abort in s, so B has advantage!

Conclusions uOnline contract signing is subtle Fair Abuse-free Accountability uSeveral interdependent subprotocols Many cases and interleavings uFinite-state tools great for case analysis! Find bugs in protocols proved correct uProving properties of all protocols is harder Understand what is possible and what is not