Digital Cash Protocols:A Formal Presentation

Delwin F. Lee & Mohamed G.GoudaThe University of Texas at Austin

Presented bySavitha Krishnamoorthy

CIS 788

The Ohio State University

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

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

Contribution No formal verification available for

any security protocol

Presents a formal technique of proving correctness

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

Concepts & Proof

Proof uses concepts of • Closure• Convergence• Protection

Proves protocol security against• Forgery• Modification • Replay

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

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

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

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

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

To Prove

Convergence of protocol

Protection of protocol

Specs of Millicent

Parties: Customers, Vendors

Customer specific, vendor specific scrip:• Identity of customer• Identity of vendor• Value of scrip (dollars)

The Millicent Protocol Value of scrip buy request, scrip

request Message flow:

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])

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

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

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)

State Transition Diagrams

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

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

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

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

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

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

Micropayment

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

Adversary Actions

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

Verification Message Modification

• All messages are integrated with public/private key encryption

Message Replay• Presence of time stamp

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

Comments Does not mention key exchange in

millicent; required for signature

Fault Span can include Non-repudiation

Thank You!