Failure Analysis of an E-commerce Protocol using Model Checking (2005)

1. Failure Analysis of an E-commerce Protocol using Model Checking(2005) Ivan Denisa

2. Protocols for E-Commerce • iKP (IBM-Zürich) – secure payment over insecure network • Millicent (Digital Equipment's Systems Research Center) – secure micropayments • Digicash-anonymous transactions • Netcash- anonymous transactions

3. E-commerce protocols desirable properties • The information exchanged between the parties involved in the e-commerce is protected from unauthorized disclosure and modification • Money atomicity - money is neither created nor destroyed in the course of an e-commerce transaction. • Goods atomicity – a merchant receives payment if and only if the customer receives the product. • Validated receipt - the customer is able to verify the contents of the product about to be received, before making the payment.

4. Model checking Protocol verification using existing software verification techniques

5. Model checking is a completely automated technique and considerably faster than other approaches. • If a property does not hold, a counter example is produced by the model. • Model checking has previously been used successfully to verify security protocols.

6. Model checker: Failure Divergence Refinement (FDR) • Protocol (named SYSTEM): will be expressed as a communicating sequential process (CSP) • Property to be proven (named SPEC): will be expressed as another CSP process => If SYSTEM is a refinement of SPEC (that is, the set of behaviors generated by SYSTEM is a subset of those generated by SPEC), we can infer that the protocol satisfies the property.

7. Messages Exchanged in the E-commerce Protocol

9. FDR model checker • Based on the theory of CSP • Allows one to check properties of finite state systems • CSP processes are described using events(which cause a process to change state) and operators • In CSP, the communication between processes is synchronized. To model asynchronous communication, which means that a sender sends messages over a unique channel (sender’s “out” channel for a particular receiver) while the receiver receives the message over another channel (receiver’s “in” channel corresponding to a particular sender)

10. List of CSP notations • a?x //input x on channel a • a!x //output x on channel a • {|a|} //set of event associated with channel a • a->P //defines the process waiting for event a, after a it behaves like P. • []x:X @ a?x -> P //defines the process that accepts any element x of X on channel a and behaves like P

11. List of CSP notations • P |~| Q // defines the process that non-deterministically can behave like either P or Q • P [] Q // defines the process that can behave like either P or Q, preference is given to the unblocked process. • P [|{}| Q] // defined the process in which processes P and Q run completely independently of each other • P [|X|] Q //defines the process where all events in X must be synchronized and the events outside X can proceed independently.

12. ExampleMerchant – Customer communication • Channels : minc, moutc, cinm,coutm • Processes : COMMmc, COMMcm • COMMmc: • reads from channel coutm • writes to channel minc • COMMcm: • reads from channel moutc • writes to channel cinm COMMcm = []x: {po} @(coutm ?x -> (minc !x -> COMMcm)) po = purchase order

13. Modeling the Customer process • C = cint ?x -> DOWNLOADED_EGOODS(x) • DOWNLOADED_EGOODS(x) = coutm !po -> PO_SENT(x) 3. PO_SENT(x) = cinm ?y -> if (y==encGoods1 or y==encGoods2) then RECEIVED_EGOODS(x,y) else PO_SENT(x) • RECEIVED_EGOODS(x,y) = if (x==y) then RECEIVED_CORRECT_GOODS else ABORT • RECEIVED_CORRECT_GOODS = coutt !paymentToken -> TOKEN_SENT 6. TOKEN_SENT = cint ?y -> if (y==key) then SUCCESS else (if y== transactionAborted) then ABORT else TOKEN_SENT

14. Modeling the Merchant Process • MERCHANT = minc ?x -> if (x==po) then PO_REC else MERCHANT 2. PO_REC = (moutc !encGoods1 -> ENCRYPTED_GOODS_SENT) |˜| (moutc !encGoods2 -> ENCRYPTED_GOODS_SENT) (After the merchant receives a po, it can act in two ways – either he sends the correct encrypted product , denoted by encGoods1, or an incorrect encrypted product , denoted by encGoods2) • ENCRYPTED_GOODS_SENT = moutt !key -> KEY_SENT 4. KEY_SENT = mint ?x -> if (x==paymentToken) then SUCCESS else if (x==transactionAborted) then ABORT else KEY_SENT

15. Modeling the Trusted Third Party(I) • TP = toutc !encGoods1 -> WAIT_TOKEN_KEY 2. WAIT_TOKEN_KEY = (tinc ?a -> if (a==paymentToken) then WAIT_KEY(a) else WAIT_TOKEN_KEY) [] (tinm ?b -> if (b==key) then WAIT_TOKEN(b) else WAIT_TOKEN_KEY) where WAIT_KEY(a) = tinm ?b -> if (b==key) then CHECK_TOKEN(a,b) else WAIT_KEY(a) WAIT_TOKEN(b) = tinc ?a -> if (a==paymentToken) then CHECK_TOKEN(a,b) else WAIT_TOKEN(b) (the third party waiting to receive the payment token from the customer and the key from the merchant. When the third party receives a message it checks if the message is a payment token or key or neither. Note that, it is not known whether the key or payment token will arrive first. If the payment token arrives first, the third party must wait for the key. On the other hand, if the key arrives first, the third party must wait for the payment token.)

16. Modeling the Trusted Third Party(II) 3. CHECK_TOKEN(a,b) = OK_TOKEN(a,b) |˜| NOK_TOKEN OK_TOKEN(a,b) = SEND_TOKEN_KEY(a,b) NOK_TOKEN = SEND_ABORT_MESSAGE • where a=paymentToken and b=key SEND_ABORT_MESSAGE = toutc !transAborted -> toutm !transAborted -> STOP SEND_TOKEN_KEY(a,b) = toutc !b -> SEND_TOKEN(a) |˜| toutm !a -> SEND_KEY(b) SEND_TOKEN(a) = toutm !a -> SUCCESS SEND_KEY(b) = toutc !b -> SUCCESS The processes of sending out the key to the customer and the token to merchant can occur in any order.

17. Modeling the Desirable Properties

18. Money Atomicity Money is neither created nor destroyed in the process of an electronic transaction. Success: • the customer sends the payment token and the merchant receives it • the customer sends the payment token and then receives a transaction abort message. SPEC1 = STOP |˜| (coutt.payTok -> ((cint.transAborted -> STOP) |˜| (mint.payTok -> STOP)))

19. Goods Atomicity Customer receives product iff he has paid. Both the correct encrypted product and the key are required by the customer in order to get the product. Success: • C receives the correct encrypted product and the keys and M receives the token(in any order) • C receives just the encrypted product and neither M gets payTok nor C the keys SPEC2 = STOP |˜| ((cinm.encGoods1 -> STOP) [] (cinm.encGoods2 -> STOP) [] (cinm.encGoods1 -> cint.key -> mint.payTok -> STOP) [] (cinm.encGoods1 -> mint.payTok -> cint.key -> STOP)) //encGoods1= correct encrypted product //encGoods2= incorrect encrypted product

20. Validated Receipt Customer makes the payment only after he is satisfied that the product he is about to receive is the one that he is paying for. Success: • the customer receives some encrypted product and does not make payment (incorrect product or cancel product) • the customer makes the payment after receiving the correct encrypted product SPEC3 = STOP |˜| ((cinm.encGoods2 -> STOP) [] (cinm.encGoods1 -> STOP) [] (cinm.encGoods1 -> coutt.payTok -> STOP))

21. Detecting the Violation of Properties in the Presence of Failures

22. Assumptions • The channels through which the merchant, customer and the third party communicate are reliable. In other words, any data send by one party to another will eventually be received by the second party and is not lost in transmission. • Customer, Merchant and Trusted Third Party are not allowed, in general, to abort communication. • The customer (merchant) will never make a conscious decision to abort after sending out the payment token (after sending out the product decryption key) as this is detrimental to the customer’s (merchant’s) interests.

23. Introducing Unreliability over the Communication Medium • the data is lost or • the receiver receives the data. • we take the example of the communication channel that transfers data from the customer to the merchant , the other two cases are similar • FDR recheck => the unreliable channel has no effect on the property COMMcm = []x: {po} @(coutm ?x -> (minc !x -> COMMcm)) => COMMcm = []x: {po} DATAcm @(coutm ?x -> (COMMcm |˜| (minc !x -> COMMcm)))

24. Failure in the Customer Process • The customer is allowed to abort at any point. • For example, we take the first step: CUSTOMER = cint ?x -> DOWNLOADED_EGOODS(x) => CUSTOMER = ABORT |˜| (cint ?x -> DOWNLOADED_EGOODS(x)) //FDR reports no property violation. Exception is the last step (the customer sending the purchase order), with result : money and goods atomicity violation. Next: money atomicity violation counterexample

25. FDR debugger generates the following sequence of events: • toutc.encryptedGoods1, cint.encryptedGoods1, • coutm.po, minc.po, • moutc.encryptedGoods1, • moutt.key, tinm.key, • cinm.encryptedGoods1, • coutt.paymentToken, tinc.paymentToken, // M does not receive payTok • toutc.transAborted, /* C has aborted transaction, it does not receive this message*/ toutm.transAborted, mint.transAborted => the customer sends out the payment token, but neither the merchant received the payment token nor the customer the transaction abort message. Thus money atomicity is violated.

26. Failure in the Merchant Process Abort in third step (after M has sent the key to TTP) • FDR generates: • toutc.encryptedGoods1, cint.encryptedGoods1, • coutm.po, minc.po, • moutc.encryptedGoods1, cinm.encryptedGoods1, • coutt.paymentToken => The third party has received the payment token from the customer and is awaiting the key from the merchant who has already aborted. Thus, in this case, neither the merchant receives the payment token nor the customer, the abort message. Thus money atomicity is violated.

27. Problem can be fixed by adding a timeout event when TTP waits for responses WAIT_KEY(a) = (tinm ?b -> if (b==key) then CHECK_TOKEN(a,b) else WAIT_KEY(a)) [] (timeOut -> SEND_ABORT_MESSAGE) WAIT_TOKEN(b) = (tinc ?a -> if (a==paymentToken) then CHECK_TOKEN(a,b) else WAIT_TOKEN(b)) [] (timeOut -> SEND_ABORT_MESSAGE) However, allowing the merchant process to abort in the last step, that is, after sending the key but before receiving the payment token, violates both money atomicity and goods atomicity.

28. Failures in the Trusted Third Party Process • The third party process can abort only at its first step. • In the rest of the protocol, the third party must be up and running

29. Ensuring Failure Resilience of the Protocol 1. The customer cannot abort (for any reason) after he has sent the payment token to the trusted third party. 2. The merchant cannot abort (for any reason) after he has sent the product decryption key to the trusted third party. 3. The trusted third party cannot abort unilaterally after its first step. • Protocol extensions: • each party involved in the transaction, keeps a copy of the information sent to another party (in a stable local storage) • C,M and TTP use a system-wide unique identifier • Ti = < PID, C, M> , PID = product identifier, each party stores a log record of the form < Ti , ACTION_NAME>

30. Protocol Failure Analysis

31. 1. M fails after sending product decryption key (step 4) but before writing log record <Ti KEY_SENT> M queries TTP to find out the status. • If status == abort then merchant aborts. • If TTP has not received K^ then M resends the key and write the appropriate record. • If TTP cannot provide a status then • M resends the encrypted product to C, and the key and approved po to TTP and writes the appropriate log records. • It then waits for the payment token from TTP • Finally, as a result of the status query the merchant may receive the payment token. It then finishes by writing the appropriate log record.

32. 2. M fails after writing log record <Ti KEY_SENT> After recovery from failure, M finds that it has not received the payment token. It asks TTP for the payment token. The third party responds either by sending the payment token or an abort message. If it is an abort message, the merchant write <Ti ,ABORT> in its stable storage and aborts the transaction. If payment token is received the merchant writes <Ti FINISH> to log.

33. 3. M fails before writing <Ti FINISH> After recovery, merchant assumes that payment token has not been received. This is then equivalent to the previous scenario. 4. C fails after sending payTok but before writing log record <Ti PAYMENT_SENT> After recovery, C notes from log that Ti has been initiated but no other information is recorded in the log. C gets in touch with M and asks for the product. M either sends the encrypted product or an abort message. If C receives the encrypted product, the customer validates it, sends payTok and writes the appropriate log record.

34. 5. C fails after writing log record <Ti PAYMENT_SENT> After recovery C notes that the decryption key has not been received. So it requests TTP for the product decryption key. TTP responds with either an abort message or the decryption key. If it is an abort message, the customer writes <Ti ABORT> to its log and aborts. If it is the decryption key, the customer writes <Ti FINISH> to the log and finishes. 6. TTP fails before writing log record <Ti INITIATE> At this stage TTP is not aware of the transaction Ti => TTP does nothing. At some point of time either C or the M will get in touch asking for the product decryption key or a status query => TTP writes <Ti INITIATE> and ask C for the payTok and PO, and M for the product decryption key and the approved purchase order. It then starts the timer.

35. 8. TTP fails after writing <Ti INITIATE> After recovery TTP notes that Ti has been initiated. It asks C for payTok and PO, and M for the product decryption key and the approved PO. Once it has received a response from C or M, it starts the timer and waits for the other message. 9. TTP fails before writing either log records <Ti PAYMENT_FWD> or <Ti KEY_FWD> Similar to previous scenario. 10. TTP fails after writing one of the records PAYMENT_FWD> or <Ti KEY_FWD> but before writing the other After recovery TTP sends the message that was not sent out prior to failure and writes the appropriate record.

36. References • I. Ray, I. Ray, and N. Narasimhamurthy. A Fair-Exchange Protocol with Automated Dispute Resolution. Technical report, University of Michigan-Dearborn, 1999. Submitted for publication. • A. W. Roscoe. Proving Security Protocols with Model Checkers by Data Independence Techniques. In Proceedings of the 1998 IEEE Computer Security Foundations Workshop. IEEE Computer Society Press, 1998. • Formal Systems (Europe) Ltd. Failure Divergence Refinement - FDR2 User Manual, version 2.64 edition, August 1999. • B. Cox, J. D. Tygar, and M. Sirbu. NetBill Security and Transaction Protocol. In Proceedings of the First USENIX Workshop in Electronic Commerce, pages 77–88, July 1995.