Fair Exchange Protocols Steve Kremer and Mark Ryan Fair Exchnage - - PowerPoint PPT Presentation

Fair Exchange Protocols

Steve Kremer and Mark Ryan

Fair Exchnage Protocols – p.1

Examples of fair exchange protocols

Electronic purchase of goods

exchange of an electronic item against an electronic payment

Digital 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

. . .

Fair Exchnage Protocols – p.2

An example: digital contract signing

Use digital signatures to sign a contract over a network What is the problem ? Alice Bob Signed contract Signed contract Asymmetry: someone must be the first to sign Fairness 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.

Fair Exchnage Protocols – p.3

Evolution of fair exchange protocols

protocols requiring a trusted third party (TTP)

. . . but create a bottleneck at the TTP

Fact: 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

• ptimistic protocols suppose that most entities are honest, TTP intervention
• nly in case of problem

. . . introduced only in 1997 independently by Asokan et al. and Micali

Fair Exchnage Protocols – p.4

A probabilistic contract signing protocol

Alice chooses a random number

• , and then she chooses
• random keys

. Bob doesn’t know

• r 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. Decryption time is assumed to be much greater than

. Alice Bob

ack(

)

ack(

)

ack(

) . . .

ack(

)

Fair Exchnage Protocols – p.5

A first optimistic contract signing protocol

Main protocol Alice Bob Promise to sign contract Signed contract Signed contract

else recover with TTP

Fair Exchnage Protocols – p.6

A first optimistic contract signing protocol (2)

Recovery protocol Bob TTP Recovery request (including A’s promise) Contract signed by TTP Contract signed by TTP Alice Note: communication channels between the TTP and participants are supposed to be resilient (all messages eventually arrive).

Fair 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.

Fair Exchnage Protocols – p.8

A second optimistic contract signing protocol

Main protocol Alice Bob Promise to sign contract

else stop

Promise to sign contract

else abort with TTP

Signed contract

else recover with TTP

Signed contract

else recover with TTP

Fair Exchnage Protocols – p.9

A second optimistic contract signing protocol (2)

Abort Protocol Alice TTP Abort request

if protocol not yet recovered

Abort token signed by TTP

else

Contract signed by TTP 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.

Fair Exchnage Protocols – p.10

A second optimistic contract signing protocol (3)

Recovery Protocol Alice TTP Recovery request (including B’s promise)

if protocol already aborted

Abort token signed by TTP

else

Contract signed by TTP Bob Contract signed by TTP Note: The recovery protocol for Bob is obtained by inversing Alice’s and Bob’s role.

Fair 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. 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. TTP invisibility 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.

Fair 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.

Fair Exchnage Protocols – p.13

RSA in a nutshell (1)

Key generation

Choose two large primes

and

Compute

=

Choose

, such that

and gcd

Compute

, such that

Signature generation for message

Signature verification

How it works:

• ✒

since

• ✒

• ✒

• ✒

by Fermat’s little thm:

• ✒

Fair Exchnage Protocols – p.14

RSA in a nutshell (2)

Cross-decrytpion property

Given two relative prime RSA modula

and

, choose

, and compute

and

, such that

and

Given

min

: Encryption: the encryption of

is:

Decryption: the decryption of

is

• r

How it works:

Fair Exchnage Protocols – p.15

A VRES based on RSA signatures

Nenadi´ c, Zhang, Barton 2004

Key generation (registration at the TTP)

generates an RSA modulus

and the correpsonding keys

generates a second RSA modulus

(relatively prime with

) and the correpsonding keys

which she shares with TTP

VRES generation

Choose a random prime

• ❉

• ❉

• ❉

• ❉

Fair Exchnage Protocols – p.16

A VRES based on RSA signatures (2)

VRES verification

• ❉

• ❉

VRES recovery

• ❉
• ❉

Note: there exist more efficient VRES scheme which do not require to share a key with the TTP .

Fair Exchnage Protocols – p.17

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.

Fact: 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

• f the protocol.

Fair Exchnage Protocols – p.18

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.

Fair 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 ... For 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 Felix C. Gärtner. Fair exchange. The Computer Journal, 8(2):55–75, January 2003.

Fair Exchnage Protocols – p.20