air Exchange Protocols Steve Kremer and Mark Ryan air Exchnage Protocols p.1
Examples of fair exchange protocols Electronic purchase of goods exchange of an electronic item against an electronic payment igital contract signing exchange of digital signatures on a given electronic document Non-repudiation protocols exchange of an electronic item and a non-repudiation of origin evidence against the corresponding non-repudiation of receipt evidence Certified e-mail exchange of an electronic message against a proof of receipt Barter an electronic item of a given value is exchanged against another item of a similar value... air Exchnage Protocols p.2
An example: digital contract signing Use digital signatures to sign a contract over a network What is the problem? Alice Signed contract Bob Signed contract Asymmetry: someone must be the first to sign airness A protocol is fair if at the end of the protocol, either all participants received the expected item, or none of them received the expected item. air Exchnage Protocols p.3
Evolution of fair exchange protocols protocols requiring a trusted third party (TTP... but create a bottleneck at the TTP act: no deterministic contract signing protocol exists without the participation of a TTP. [Even Yacobi 1980] protocols based on gradual release... but need to assume comparable computation power, do not achieve real fairness and require a high number of messages randomised protocols... but need to increase the number of messages to decrease the probability that someone may cheat optimistic protocols suppose that most entities are honest, TTP intervention only in case of problem... introduced only in 1997 independently by Asokan et al. and Micali air Exchnage Protocols p.4
A probabilistic contract signing protocol Alice chooses a random number, and then she chooses random keys. Bob doesn t know or the keys. Next, Alice and Bob exchange messages as follows. Each party will timeout and abandon the protocol if there is a delay of time units by the other party in sending the next message. ecryption time is assumed to be much greater than. ack( Alice ack( Bob ack(. ack( air Exchnage Protocols p.5
A first optimistic contract signing protocol Main protocol Alice Promise to sign contract Signed contract Bob Signed contract else recover with TTP air Exchnage Protocols p.6
A first optimistic contract signing protocol (2 Recovery protocol Bob Recovery request (including A s promise TTP Contract signed by TTP Alice Contract signed by TTP Note: communication channels between the TTP and participants are supposed to be resilient (all messages eventually arrive. air Exchnage Protocols p.7
A first optimistic contract signing protocol (3 This protocol is fair. But it still has a problem... After having sent the first message Alice can get stuck. Timeliness A protocol provides timeliness if and only if at each moment in the protocol each participant can reach, in a finite amount of time, a point where he can stop the protocol while preserving fairness. air Exchnage Protocols p.8
A second optimistic contract signing protocol Main protocol Alice Bob Promise to sign contract Promise to sign contract else stop else abort with TTP Signed contract Signed contract else recover with TTP else recover with TTP air Exchnage Protocols p.9
A second optimistic contract signing protocol (2 Abort Protocol Alice TTP Abort request Abort token signed by TTP Contract signed by TTP if protocol not yet recovered else Note: The abort token is not a proof that the protocol has been aborted. It is only a promise that the TTP will not allow this protocol to be recovered. Note: Each message of the protocol must contain a unique identifier for the protocol session. air Exchnage Protocols p.10
A second optimistic contract signing protocol (3 Recovery Protocol Alice TTP Recovery request (including B s promise Abort token signed by TTP if protocol already aborted Contract signed by TTP else Bob Contract signed by TTP Note: The recovery protocol for Bob is obtained by inversing Alice s and Bob s role. air Exchnage Protocols p.11
TTP invisibility The previous protocol is fair and respects timeliness. However, it is possible to determine whether the TTP did intervene or not. TTP invisibility Bad publicity! A company could be believed to have cheated whereas in fact it was the network which delayed some messages. Having Alice s signature on the contract may be preferable to the TTP s signature. A TTP producing evidences which are indistinguishable from the ones Alice or Bob would have produced in a faultless scenario is said to be invisible or transparent. air Exchnage Protocols p.12
Verifiable Recoverable Encrypted Signatures A VRES is a cryptographic primitive, which implements a promise of a signature; makes it infeasible for anyone to extract the standard signature except for the TTP; is verifiable, i.e. a verifier will be convinced that the VRES can be converted to a standard signature by the TTP; is recoverable by the TTP, i.e. the TTP can convert the VRES to a standard signature. In a fair exchange protocol use a VRES as a promise to sign the contract (first 2 messages; the VRES can be converted to a standard signature by the TTP in case of a recovery. air Exchnage Protocols p.13
!! + ' ;7 9 7 : 6 6 8 / 3 1 6 / 7 6 ;7 : 6 - / RSA in a nutshell (1 Key generation and Choose two large primes = Compute and gcd, such that Choose ", such that Compute Signature generation for message * ( $( ' Signature verification, $( $( How it works: since 34 21 0 5.5 *,.- - / 7 2 5 <- - by ermat s little thm: 5 - / 3 21 5 air Exchnage Protocols p.14
(, ( = ( RSA in a nutshell (2 Cross-decrytpion property and!, and compute, choose and and "! Given two relative prime RSA modula, such that "!! Given min : Encryption: the encryption of ( is: is ecryption: the decryption of *?@ = or *?> = How it works: * >, $( * >, ( air Exchnage Protocols p.15
B A C C, N K ML O A VRES based on RSA signatures Nenadić, Zhang, Barton 2004 Key generation (registration at the TTP generates an RSA modulus E and the correpsonding keys! E generates a second RSA modulus (relatively prime with correpsonding keys which she shares with TTP! and the VRES generation Choose a random prime G G H *J $( G I 3 2RQ P J S *J H G I air Exchnage Protocols p.16
+ S + H A VRES based on RSA signatures (2 VRES verification, *J $( G I, ( H, *TJ H G, I H H VRES recovery S *J G $( ' * J ( I U G Note: there exist more efficient VRES scheme which do not require to share a key with the TTP. air Exchnage Protocols p.17
V An advantage to one party Imagine Alice starts a protocol to sell stock options to Bob. Alice starts the protocol with Bob and then shows Bob s offer to Charlie. Alice can convince Charlie that Bob started the protocol with a given offer; Alice can choose the outcome of the protocol. Influence Charlie to make a better offer. act: any protocol with an optimistic signer, the other signer can at some point choose the outcome of the protocol. [Chadha et al, 2003] The best we can hope is to avoid provable advantage. Abuse-freeness A protocol is said to be abuse-free if it is impossible for any participant to prove to an outsider that he has the power to decide the outcome of the protocol. air Exchnage Protocols p.18
B A W Private contract signatures Garay, Jakobsson, MacKenzie 1999 To achieve abuse-freeness use PCS instead of VRES. A PCS is a cryptographic primitive, which is recoverable by a TTP designated verifier: only a given designated verifier, Bob, is convinced that Alice is the signer. The designated verifier property is implemented by giving Bob the possibility to simulate or fake the PCS. Charlie will not be convinced that Alice really started the protocol, as Bob could show a simulation of Alice s message. air Exchnage Protocols p.19
Conclusion Crucial protocols to enable secure electronic commerce Currently still at an academic stage... Complex structure (in comparison to authentication protocols Some properties need non-standard cryptographic primitives Still a lot of ongoing research... or a survey and pointers: [KMZ02] Steve Kremer, Olivier Markowitch, and Jianying Zhou. An intensive survey of non-repudiation protocols. Computer Communications, 25(17:1606 1621, November 2002. [PVG03] Henning Pagnia, Holger Vogt, and elix C. Gärtner. air exchange. The Computer Journal, 8(2:55 75, January 2003. air Exchnage Protocols p.20