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
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 microcommerce 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 Nonrepudiation
Thank You!