Formal Verification of Digital Cash Protocols for Secure Online Transactions

1. Digital Cash Protocols:A Formal PresentationDelwin F. Lee & Mohamed G.GoudaThe University of Texas at AustinPresented bySavitha KrishnamoorthyCIS 788The 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<message> 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!