outline
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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!