Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 11

Colored Petri Net based model checking and failure analysis for e-commerce

protocols

Panagiotis Katsaros – Vasilis Odontidis – Maria Gousidoukatsaros@csd.auth.gr - http://delab.csd.auth.gr/~katsaros/

vasilis_aftermath@yahoo.gr

Department of Informatics

Aristotle University of Thessaloniki

G R E E C E

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 22

Motivation work towards a Colored Petri Net based

atomicity modeling and analysis approach that will combine: formal verification interactive simulation

we model site and communication failures, as well as potential unilateral transaction aborts and model check their effects with respect to the three levels of payment atomicity

in e-commerce, lack of reliability or security may cause loss of money and consumers’ confidence

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 33

The applied approach I employ a Colored Petri net model for the

considered e-cash system

use the CPN Tools toolkit to generate the model’s state space (occurrence graph)

use the supported Computation Tree like Temporal Logic (ASK-CTL) to model check the three levels of payment atomicity, namely:

money atomicity

goods atomicity

certified delivery

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 44

The applied approach II protocol failure analysis by interactive simulation of

potential property violation scenarios pinpoints areas where design changes or revisions should be considered

the system under consideration: the NetBill protocolIt has already been found to possess all three levels of payment atomicity.

already published model checking approaches:are based on a Communicating Sequential Processes (CSP) representation of the system and the use of the FDR model checker (preorder model checking)

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 55

The applied approach III

other interesting problems in e-commerce: model check security properties like authentication,

confidentiality, anonymity, message integrity (need of an intruder CP-net)

model check other functional properties like for example action traceability (also called accountability)

all published model checking results make use of a “black

screen” model checker (FDR, NuSMV etc)

FDR does not provide the interactive simulation functionality of CPN Tools and a comparable GUI, to perform an effective protocol failure analysisASK-CTL exploits the SCC graph and this may result in more efficient model checking, when compared to e.g. SPIN

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 66

The applied approach IV Colored Petri Nets in e-commerce

the IOTP verification (see past CPN workshops)- absence of deadlocks and livelocks- absence of unexpected dead transitions- absence of inconsistent terminal states- protocol verification with respect to the intended

service properties that depend on certain structural

properties of the model’s state space graph

different failure assumptions (e.g. reliable communication vs message losses)

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 77

The NetBill protocol three participants: the consumer (C) – the merchant

(M) - the bank server (B)/trusted third party C M price request M C price quote C M goods request M C encrypted goods accompanied by a product

checksum number C M electronic payment order (epo) & checksum no M B endorsed epo & the decryption key K & the

product checksum number B M signed result (success or not) and in case of

success the decryption key K M C signed result and in case of success the key K

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 88

The virtues of the NetBill protocol

money atomicity: there is no possibility of creation or destruction of money, while electronic cash is being transferred

goods atomicity: includes money atomicity and also ensures that there is no possibility of paying without having received goods or vice versa

certified delivery or strong fairness: includes money atomicity and goods atomicity and also allows C and M to prove the details of the transaction money atomicity & goods atomicity for NetBill have already been proved by FDR

certified delivery is not proved in related bibliography

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 99

Other electronic cash systems

Digicash, Payword, MicroMint and MiniPayfail to provide a certified delivery mechanism

interesting prospect: use CPN Tools to revise

them.

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1010

The CP-net (model assumptions)

we take into account C and M site failures non-reliable communication between the

protocol’s participants (message losses)

C’s account debit and M’s account credit take place at the same site that provides trivial transaction atomicity guarantees (which are outside the scope of NetBill)

we omit modeling B site failures, since we did not want to model the typical transaction execution mechanism found in most transaction processing textbooks

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1111

The CP-net hierarchy

The top-level CP-net (place stop: diagnostic strings for protocol terminationplace queryBank: C can always find out the result by querying B)

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1212

Color sets and variables

colset pPrmtrs =with START;

colset validORnot =with v | i;

colset request =record gReq:validORnot*

enGoods:validORnot*

epoReq:validORnot;

colset sRequest =union reqRec:request;

colset lReqQ =list sRequest;

colset result =with noFunds | paymentReceipt | noRecord;

var aRequest :request;

var q :lReqQ;

var valCode :validORnot;

var intVar :INT;

var res :result;

Different protocol execution scenarios are modeled by request typed tokens

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1313

C’s transition page

we model site failures, message losses and transaction abort cases, in order to check their effects with respect to the three levels of payment

atomicity

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1414

M’s transition page

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1515

B’s transition page (trusted third party)

atomic single site transaction execution: we initially remove the result typed token from queryBank and at the end we place an appropriate token value in ittwo places (debitC – creditM) make money atomicity self-evident but we want to provide a way to express it in ASK-CTL

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1616

The model’s occurrence graph

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1717

The occurrence graph analysis standard report Statistics------------------------------------------------------------------------ State Space Scc Graph Nodes: 59 Nodes: 59 Arcs: 103 Arcs: 103 Secs: 0 Secs: 0 Status: Full Boundedness Properties------------------------------------------------------------------------ Best Integers Bounds Upper Lower BankProcess'No_Transaction 1 1 0 BankProcess'creditM 1 1 0 BankProcess'debitC 1 1 0 Protocol'bankOut 1 1 0 Protocol'ePaymentOrder 1 1 0 Protocol'encrGoods 1 1 0 Protocol'endTransaction 1 1 0 Protocol'endorsedPaymentOrder 1 1 0 Protocol'goodsRequest 1 1 0 Protocol'prmtrs 1 1 0 Protocol'queryBank 1 1 0 Protocol'reqQueue 1 1 1 Protocol'stop 1 1 0

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1818

The occurrence graph analysis standard report Home Properties------------------------------------------------------------------------

Home Markings: None

 

Liveness Properties

------------------------------------------------------------------------

Dead Markings: 13 [59,658,57,56,55,...]

Dead Transitions Instances: None

Live Transitions Instances: None

 

Fairness Properties

------------------------------------------------------------------------

No infinite occurrence sequences.

the properties checked in the standard report constitute a necessary input source, for correctly expressing the CTL formulae of the required correctness propertiesi.e. in case of infinite occurrence sequences we might have to write the CTL formulae in a different way (consult the CTL function semantics)

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 1919

Money atomicity

implied by the transaction atomicity assumption for the B server

although in this case is self-evident, we show how to express it in CTL, such as to detect redundant debits before the occurrence of the expected credit

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2020

Money atomicity (continued)

C’s debit stateno redundant C debit

until the expected M’s creditfor all paths result

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2121

Non atomic goods delivery: C’s perspective

Irrespective of the considered failures, message losses and unilateral abort cases: when signs a valid epo it is possible to eventually perform C’s debit, without a subsequent protocol termination with a payment receipt that in fact includes the goods decryption key.

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2222

Non atomic goods delivery: C’s perspective

state of dispatch of a valid signed epoC’s debit state

no payment receipt no goods

path where possible to eventually occur C’s debit and at the same time in every state to not register the expected payment receipt

result

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2323

Non atomic goods delivery: M’s perspectiveIrrespective of the considered failures, message losses and unilateral abort cases:

when C sends a (not necessarily valid) epo it is possible to eventually register a payment receipt, without having previously debited C’s account

we model check 2 subtrees (valid epo OR invalid epo)

result

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2424

Non certified delivery: C’s perspective

Irrespective of the considered failures, message losses and unilateral abort cases:

state, where it is possible to end with a payment receipt without C having previously obtained the corresponding product checksum no

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2525

Protocol failure analysis protocol failure analysis aims in exploring all property

violation scenarios (if any) and pinpoints areas where design changes or revisions should be considered

we simulate the property violation paths interactively, in order to explore potential protocol revision alternatives

we inspect the terminal markings (dead markings) of property violation paths

it is important the CP-net to generate meaningful diagnostic strings in places like the place stop in our model

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2626

NetBill protocol analysis

in CPN Tools protocol termination inspection is performed by the provided ML functions (in the paper: protocol termination inspection for NetBill)

the latest version of CPN Tools allows firing transitions with an interactively chosen binding

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2727

Conclusion I we presented a Colored Petri net based

approach in modeling site failures, message losses and transaction abort cases

we model checked the forenamed failures and transaction aborts with respect to the three levels of payment atomicity

we proposed protocol failure analysis to be based on inspection of protocol’s terminal markings and interactive simulation of detected property violation scenarios

Model checking and failure analysis in e-commerce Model checking and failure analysis in e-commerce protocolsprotocolsCPN’05, Aarhus Oct 2005CPN’05, Aarhus Oct 2005 2828

Conclusion II CPN Tools can be an attractive alternative over

FDR, SPIN etc, if ASK-CTL will provide a counterexample for each property violation case

if ASK-CTL will implement advanced model checking features like for example on-the-fly model checking and others