1. Digital Cash Protocols: A Formal Presentation Delwin F. Lee & Mohamed G.Gouda The University of Texas at Austin Presented by Savitha Krishnamoorthy CIS 788 The Ohio State University

2. Outline Motivation Contribution Digital Cash Protocols Specs of Millicent Proof of Correctness Specs of Micropayments Proof of Correctness Comments

3. Motivation Increasing need for protocols facilitating online transactions No existing formal verification of security of Digital Cash Protocols Choice of protocols Both prominent, largely supported Techniques used can be applied to other protocols

4. Contribution No formal verification available for any security protocol Presents a formal technique of proving correctness

5. Digital Cash Protocols Tailored to small purchases in micro- commerce applications Need to prove security before approval Protocols verified Compaq’s Millicent IBM’s Micropayments

6. Concepts & Proof Proof uses concepts of Closure Convergence Protection Proves protocol security against Forgery Modification Replay

7. Abstract Protocol Notation Each process defined by consts, variables, parameters, and actions Guard of action of Process P Boolean expression over constants and vars of p A receive guard: rcv from process q Timeout guard (Boolean exp over consts and vars of every process,contents of all channels in the protocol

8. Definitions State: Function of protocol- assigns each variable a value from its domain, to each channel a sequence of messages Transition: A pair(p,q) of states, Guard is true at p, execution of action when state=p -> state=q Computation: Infinite sequence of states (p.0,p.1,p.2,…) s.t. (p.i,p.i+1) is a transition

9. Definitions Contd… Safe state: occurs in any computation starting from an initial state of protocol Error State: State reached when adversary executes its action Unsafe state: an error state or occurs in a computation starting from an error state

10. Secure Protocol Satisfies: Closure: In every computation if first state is safe, every state is safe Convergence:Protocol computation whose first state is unsafe, has a safe state Protection: In each transition whose first state is unsafe, critical variables of protocol do not change their value

11. Technique of Proof Presentation of protocol in abstract notation Identification of Parties involved Identification of actions executed at each party State transformations with every action Adversary Actions Convergence from fault span, Protection

12. To Prove Convergence of protocol Protection of protocol

13. Specs of Millicent Parties: Customers, Vendors Customer specific, vendor specific scrip: Identity of customer Identity of vendor Value of scrip (dollars)

14. The Millicent Protocol Value of scrip  buy request,  scrip request Message flow:

15. Fields of Scrip Sequence number: detects scrip replay Vendor Stamp: detects scrip forgery Signature: Scrip modification MD(i|j|val[j]|seq[j]|stamp[j]|newval|sc[j])

16. Customer Actions C.0:Send Request, with new scrip value; Compute signature to be included in the message C.1: Receive and verify new scrip C.2:Time out and retransmit If message was sent and channels are empty

17. Vendor Actions  Receive request from customer  Compare seq no. to expected seq no.  s or s-1 is s is the last scrip  s => new request; check validity of stamp and signature  Reply with scrip message

18. Proof of Correctness Safe States: S.0: c[i] sends request message S.1: v[j] receives request and sends back a scrip, executing its only action S.2: c[i] receives the scrip and protocol returns to state S.0 Fault Span: Message Forgery (F) Message Modification (M) Message replay (R)

19. State Transition Diagrams

20. Adversary Actions Forgery: S.0->U.0: Adversary in collusion with customer forges a false scrip: cannot reproduce vendor stamp Vendor Returns to S.0 (This means a customer can send his scrip only) If valid c.0 is executed at U.0, vendor returns to S.1

21. Adversary Actions Contd… Modification C[i]’s request modified, S.1->U.2 V[j]’s scrip modified, S.2->U.4 Both fail due to signature (MD Hash) can be verified by either receiver Message discarded, U2 or U4->U6 C[i] times out, U6->S0

22. Adversary Actions Contd… Replay Current request message replaced with earlier request message, S.1->U.3 Current scrip message replaced with earlier scrip, S.2->U.5 Presence of sequence numbers causes message to be discarded, U.3 or U.5 -> U.6 C[i] times out U.6->S.0

23. Proof of Security Convergence: Any computation with first state = {U.0,U.1,U.2,U.3,U.4,U.5,U.6} has a safe state S.0 or S.1

24. Proof of Security Contd… Protection: No critical variable is updated when the protocol starts in an unsafe state Critical variables: Customer: Seq, val, stamp Action updating critical variable: C.1 Scrip is verified before updating

25. Protection Contd… Critical Variables for vendor: seq, val, stamp Updated by action v If protocol starts in unsafe state with rqst message channel modified/replayed V[j] invalidates message; leaves critical variables unchanged

26. Micropayment

27. State Diagrams Interaction b/w customer and broker: S.0: Initial State S.0->S.1: c[i] sends cert req to broker S.1->S.2: Broker action S.2->S.0: c[i] receives cert

28. Adversary Actions

29. Verification Forgery S.0->U.0: Adversary creates its own certificate Message discarded since broker’s private key cannot be accessed U.0->U.1: c[i] requests at U.0

30. Verification Message Modification All messages are integrated with public/private key encryption Message Replay Presence of time stamp

31. Comments Recognizes need for only single scrip for each vendor Protocol never deals with combining scrip Compares two widely used protocols; Micropayment more resource intensive and less efficient

32. Comments Does not mention key exchange in millicent; required for signature Fault Span can include Non- repudiation

33. Thank You!