Analyzing an Anonymous Fair Exchange E-commerce Protocol - PowerPoint PPT Presentation

About This Presentation
Title:

Analyzing an Anonymous Fair Exchange E-commerce Protocol

Description:

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

Number of Views:34
Avg rating:3.0/5.0
Slides: 17
Provided by: Vital72
Category:

less

Transcript and Presenter's Notes

Title: Analyzing an Anonymous Fair Exchange E-commerce Protocol


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

2
Protocol Overview
  • Protocol proposed in Ray and Ray 2001
  • Protocol presented in pseudocode
  • Five roles
  • Customer and customers bank
  • Merchant and merchants 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

3
Protocol Overview (no TP)
1
2
5
C
M
6
3
8
4
7
CB
MB
  • Preamble (on a private channel) M gt TP m K1
    Mipub
  • Preamble (on a private channel) TP gt C m, K1
    Mipub
  • C gt M PO CC(PO), Ciprv Cipub, Mipub
  • M gt C CC(PO), Miprv m.r, K1xK2 CC(m.r,
    K1xK2), Miprv r, K1
    CC(r, K1), Miprv Macct, MBpub CC(Macct,
    MBpub), Miprv
  • C gt CB MTI, Cprv, CBpub 4)
    CB gt C P, Bcprv, Cpub
  • C gt M P, Bcprv, Mipub
  • M gt MB P, Bcprv, MBpub 7)
    MB gt M ack, MBprv
  • M gt C K2inv, Cipub CC(K2inv), Miprv rinv,
    Cipub CC(rinv), Miprv

4
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

5
Design of Our MOCHA Model
hc
n
hm
hmb
hcb
  • 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

6
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
  • -gt i1' false
  • i3' false
  • i5' false
  • i5a' false
  • iA' false
  • cprod' false

Vars for messages
Customer dishonesty flag
Initially has no messages
7
Honest Customer Module (2)
Rules for updating state
  • update
  • i1
  • -gt i1' true
  • i1 o2 o2a i3
  • -gt i3' true
  • i1 o2 o2a i3 o4 o4a i5
    i5a
  • -gt i5' true
  • i1 o2 o2a i3 o4 o4a i5
    i5a
  • -gt i5a' true
  • i1 o2 o2a i3 o4 o4a i5
    i5a o8 iA
  • -gt
  • i1 o2 o2a i3 o4 o4a i5
    i5a o8 iA
  • -gt iA' true
  • (o8 oB) cprod
  • -gt cprod' true
  • endatom
  • endmodule

Gets product from message 8 or B (part of TP
resolution)
8
Network Module (1)
  • Able to record messages for dishonest roles
  • i1 (dm dnet) m1 -gt m1'
    true
  • i2 (dc dnet) m2 -gt m2'
    true
  • i2a (dc dnet) m2a -gt m2a'
    true
  • i3 (dcb dnet) m3 -gt m3'
    true
  • i4 (dc dnet) m4 -gt m4'
    true
  • i4a (dc dnet) m4a -gt m4a'
    true
  • i5 (dm dnet) m5 -gt m5'
    true
  • i5a (dm dnet) m5a -gt m5a'
    true
  • i6 (dmb dnet) m6 -gt m6'
    true
  • i7 (dm dnet) m7 -gt m7'
    true
  • i8 (dc dnet) m8 -gt m8' true

Dishonest client or network can record message 4
Knowledge vars
9
Network Module (2)
  • Forge messages
  • (dc ii mm) m1 -gt
    m1' true
  • m1 dm m2 -gt
    m2' true
  • dm m2a -gt
    m2a' true
  • dc m3 -gt
    m3' true
  • (dcb (dc dmb)) m4 -gt
    m4' true
  • (dcb dc) m4a -gt
    m4a' true
  • ((m4 dc) dcb dmb) m5 -gt
    m5' true
  • (dc ii mm) m5a -gt
    m5a' true
  • ((m5 dm) dmb (dm dcb)) m6 -gt
    m6' true
  • dmb m7 -gt
    m7' true
  • m1 dm m8 -gt
    m8' true
  • m1 m2 m5 oA -gt oA' true iitp'
    true

Dishonest client can forge message 3 at will
10
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)

11
More Complex ATL Properties
  • Honest customer eventually gets product
  • atl "atl1" (ltlt hc gtgt F (cprod))
  • When payment is sent, honest customer eventually
    gets the product
  • atl "atl2" (i5 ltlt hc gtgt F (cprod))
  • Exchange can be successfully completed by honest
    parties
  • atl "atl3" (ltlt hc, hm, hcb gtgt F (cprod mpay))

cb needed to make payment token
12
Fairness
  • Dishonest merchant can't get paid without honest
    customer having a strategy to get product (DM
    model)
  • atl "cfair" ((ltlt n gtgt F (npay (ltlt hc gtgt F
    (cprod)))))
  • Dishonest customer can't get product without
    honest merchant having a strategy to get paid (DC
    model)
  • atl "mfair" ((ltlt n, hcb gtgt F (nprod

  • (ltlt hm gtgt F (mpay)))))

Dishonest parties folded into network
Dishonest customer still needs help from honest
bank
13
Balance
  • Dishonest customer cant get to a point where
  • (1) Customer can force receiving product
  • (2) Merchant cant force getting paid
  • atl "cbal" ((ltlt n, hcb gtgt F
  • Dishonest merchant cant get to a point where
  • (1) Merchant can force getting paid
  • (2) Customer cant force receiving product
  • atl "mbal" ((ltlt n gtgt F ((ltlt n gtgt F npay)
  • (ltlt hc,
    hcb gtgt F cprod))))

((ltlt n gtgt F nprod)
(ltlt hm gtgt F mpay))))
14
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

15
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

16
Conclusions
  • Think carefully about your models!
  • Process of creating formal model uncovers bugs
  • Large impact on model checkers efficiency
  • MOCHA limitations frustrating
  • Usually used for simpler models?
  • Checking invariants successful
  • Checking ATL properties time consuming
  • MOCHA didnt answer in a reasonable time
Write a Comment
User Comments (0)
About PowerShow.com