model checking and failure analysis in e-commerce protocolscpn’05, aarhus oct 20051 colored petri...
Post on 21-Dec-2015
215 views
TRANSCRIPT
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 [email protected] - http://delab.csd.auth.gr/~katsaros/
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