Analyzing an Anonymous Fair Exchange E-commerce Protocol

CS 259

Adam Barth

(joint work with Andrew Tappert)

Protocol Overview Protocol proposed in Ray and Ray 2001

• Protocol presented in pseudocode Five roles

• Customer and customer’s bank• Merchant and merchant’s bank• Trusted third party

Anonymous fair exchange of money for a digital good• Wanted to look at non-trace-based properties• Employed MOCHA, an ATL model checker

Customer assured of obtaining correct product by cross validation (not modeled)• Had enough to look at without this

Protocol Overview (no TP)

Preamble (on a private channel) M => TP: m K1 MipubPreamble (on a private channel) TP => C: [m, K1] Mipub1) C => M: PO [CC(PO), Ciprv] [Cipub, Mipub]2) M => C: [CC(PO), Miprv] [m.r, K1xK2] [CC([m.r, K1xK2]), Miprv] [r, K1]

[CC([r, K1]), Miprv] [Macct, MBpub] [CC([Macct, MBpub]), Miprv]3) C => CB: [[MTI, Cprv], CBpub] 4) CB => C: [[P, Bcprv], Cpub]5) C => M: [[P, Bcprv], Mipub]6) M => MB: [[P, Bcprv], MBpub] 7) MB => M: [ack, MBprv]8) M => C: [K2inv, Cipub] [CC(K2inv), Miprv] [rinv, Cipub] [CC(rinv), Miprv]

C M

CB MB

1

2

3

4

56

7

8

Formalizing Protocol Specification Protocol has many messages

• Eight, not including the trusted party Many terms in each message

• MOCHA bug limited total number of variables• Too complex to keep track of every term directly

Modeled messages as Boolean variables• Set to true when sent

Dishonest parties can forge messages• Based on the messages in their possession

Design of Our MOCHA Model

Honest principals interact with network• Dishonest principals folded into network

Network records messages seen by dishonest parties Dishonest can forge messages with enough knowledge

• Each corrupt principal adds more initial knowledge

hc

nhm

hcb hmb

Honest Customer Module (1)module hc -- honest customer external o2, o2a, o4, o4a, o8, oB: bool interface i1, i3, i5, i5a, iA, cprod /* customer has received product */, dc: bool atom controls i1, i3, i5, i5a, iA, cprod, dc reads o2, o2a, o4, o4a, o8, oB, i1, i3, i5, i5a, iA, cprod, dc

init [] true -> i1' := false; i3' := false; i5' := false; i5a' := false; iA' := false; cprod' := false; dc' := false

Vars for messages

Customer dishonesty flag

Initially has no messages

Honest Customer Module (2) update [] ~i1 -> i1' := true [] i1 & o2 & ~o2a & ~i3 -> i3' := true [] i1 & o2 & ~o2a & i3 & o4 & ~o4a & ~i5 & ~i5a -> i5' := true [] i1 & o2 & ~o2a & i3 & ~o4 & o4a & ~i5 & ~i5a -> i5a' := true [] i1 & o2 & ~o2a & i3 & o4 & ~o4a & i5 & ~i5a & ~o8 & ~iA -> [] i1 & o2 & ~o2a & i3 & o4 & ~o4a & i5 & ~i5a & ~o8 & ~iA -> iA' := true [] (o8 | oB) & ~cprod -> cprod' := true endatomendmodule

Rules for updating state

Gets product from message 8 or B (part of TP resolution)

Network Module (1) Able to record messages for dishonest

roles [] i1 & (dm | dnet) & ~m1 -> m1' := true [] i2 & (dc | dnet) & ~m2 -> m2' := true [] i2a & (dc | dnet) & ~m2a -> m2a' := true [] i3 & (dcb | dnet) & ~m3 -> m3' := true [] i4 & (dc | dnet) & ~m4 -> m4' := true [] i4a & (dc | dnet) & ~m4a -> m4a' := true [] i5 & (dm | dnet) & ~m5 -> m5' := true [] i5a & (dm | dnet) & ~m5a -> m5a' := true [] i6 & (dmb | dnet) & ~m6 -> m6' := true [] i7 & (dm | dnet) & ~m7 -> m7' := true [] i8 & (dc | dnet) & ~m8 -> m8' := true

Knowledge varsDishonest client or network can record message 4

Network Module (2) Forge messages [] (dc | ii | mm) & ~m1 -> m1' := true [] m1 & dm & ~m2 -> m2' := true [] dm & ~m2a -> m2a' := true [] dc & ~m3 -> m3' := true [] (dcb | (dc & dmb)) & ~m4 -> m4' := true [] (dcb | dc) & ~m4a -> m4a' := true [] ((m4 & dc) | dcb | dmb) & ~m5 -> m5' := true [] (dc | ii | mm) & ~m5a -> m5a' := true [] ((m5 & dm) | dmb | (dm & dcb)) & ~m6 -> m6' := true [] dmb & ~m7 -> m7' := true [] m1 & dm & ~m8 -> m8' := true [] m1 & m2 & m5 & ~oA -> oA' := true; iitp' := true

Dishonest client can forge message 3 at will

What Did We Do With the Model? MOCHA allowed us to “run” model by hand

• Useful to debug the model

Tested some invariants (trace-based properties)• Intruder can't get product unless he's acting as

merchant or customer– inv "inv1" (~nprod | dm | dc)

• Customer only gets prod when merchant is paid– inv "inv2" (~cprod | mpay)– inv "inv3" (cprod | ~mpay)

More Complex ATL Properties Honest customer eventually gets product

• atl "atl1" (<< hc >> F (cprod))

When payment is sent, honest customer eventually gets the product• atl "atl2" (~i5 | << hc >> F (cprod));

Exchange can be successfully completed by honest parties• atl "atl3" (<< hc, hm, hcb >> F (cprod & mpay))

cb needed to make payment token

Fairness Dishonest merchant can't get paid without honest

customer having a strategy to get product (DM model)• atl "cfair" (~(<< n >> F (npay & ~(<< hc >> F (cprod)))))

Dishonest customer can't get product without honest merchant having a strategy to get paid (DC model)• atl "mfair" (~(<< n, hcb >> F (nprod & ~(<< hm >> F (mpay)))))

Dishonest parties folded into network

Dishonest customer still needs help from honest bank

Balance Dishonest customer can’t get to a point where

• (1) Customer can force receiving product• (2) Merchant can’t force getting paid• atl "cbal" (~(<< n, hcb >> F

Dishonest merchant can’t get to a point where• (1) Merchant can force getting paid• (2) Customer can’t force receiving product• atl "mbal" (~(<< n >> F ((<< n >> F npay) & ~(<< hc, hcb >> F cprod))))

((<< n >> F nprod) &~(<< hm >> F mpay))))

Four Attacks on the Protocol Analysis reveals four attacks:

• Malicious banks can steal product– Banks share a signing key (should use group sigs)

• Man-in-the-middle can steal product– Ephemeral keys can be replaced (need another sig)

• Dishonest merchant can get paid without giving prod

– Customer and TP stuck in a loop (need TP state)• Unbalanced in favor of customer

– Customer can force outcome with payment token

How the Attacks Were Found All found by hand while constructing

model• Did not see them before building the model

MOCHA found traced-based attacks 1 and 2

MOCHA should have found attack 4• Ran for 150 hours with no answer

Conclusions Think carefully about your models!

• Process of creating formal model uncovers bugs

• Large impact on model checker’s efficiency MOCHA limitations frustrating

• Usually used for simpler models? Checking invariants successful Checking ATL properties time consuming

• MOCHA didn’t answer in a reasonable time