Analyzing an Anonymous Fair Exchange E-commerce Protocol CS 259 Adam Barth (joint work with Andrew Tappert)

Protocol Overview uProtocol proposed in Ray and Ray 2001 Protocol presented in pseudocode uFive roles Customer and customer’s bank Merchant and merchant’s bank Trusted third party uAnonymous fair exchange of money for a digital good Wanted to look at non-trace-based properties Employed MOCHA, an ATL model checker uCustomer 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 Mipub Preamble (on a private channel) TP => C: [m, K1] Mipub 1) 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] CM CBMB

Formalizing Protocol Specification uProtocol has many messages Eight, not including the trusted party uMany terms in each message MOCHA bug limited total number of variables Too complex to keep track of every term directly uModeled messages as Boolean variables Set to true when sent uDishonest parties can forge messages Based on the messages in their possession

Design of Our MOCHA Model u Honest principals interact with network Dishonest principals folded into network u Network records messages seen by dishonest parties u Dishonest can forge messages with enough knowledge Each corrupt principal adds more initial knowledge hc n n hm 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 endatom endmodule Rules for updating state Gets product from message 8 or B (part of TP resolution)

Network Module (1) uAble 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 vars Dishonest client or network can record message 4

Network Module (2) u 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? uMOCHA allowed us to “run” model by hand Useful to debug the model uTested 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 uHonest customer eventually gets product atl "atl1" ( > F (cprod)) uWhen payment is sent, honest customer eventually gets the product atl "atl2" (~i5 | > F (cprod)); uExchange can be successfully completed by honest parties atl "atl3" ( > F (cprod & mpay)) cb needed to make payment token

Fairness uDishonest merchant can't get paid without honest customer having a strategy to get product (DM model) atl "cfair" (~( > F (npay & ~( > F (cprod))))) uDishonest customer can't get product without honest merchant having a strategy to get paid (DC model) atl "mfair" (~( > F (nprod & ~( > F (mpay))))) Dishonest parties folded into network Dishonest customer still needs help from honest bank

Balance uDishonest customer can’t get to a point where (1) Customer can force receiving product (2) Merchant can’t force getting paid atl "cbal" (~( > F uDishonest merchant can’t get to a point where (1) Merchant can force getting paid (2) Customer can’t force receiving product atl "mbal" (~( > F (( > F npay) & ~( > F cprod)))) (( > F nprod) & ~( > F mpay))))

Four Attacks on the Protocol uAnalysis 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 uAll found by hand while constructing model Did not see them before building the model uMOCHA found traced-based attacks 1 and 2 uMOCHA should have found attack 4 Ran for 150 hours with no answer

Conclusions uThink carefully about your models! Process of creating formal model uncovers bugs Large impact on model checker’s efficiency uMOCHA limitations frustrating Usually used for simpler models? uChecking invariants successful uChecking ATL properties time consuming MOCHA didn’t answer in a reasonable time