Panagiotis Katsaros [email protected] - delab.csd.auth.gr/~katsaros

Formal analysis based on the use of CP-Formal analysis based on the use of CP-netsnetsMdH, MdH, Västerås, SwedenVästerås, Sweden, Apr 06, Apr 06 11 / 28 / 28

Towards a formal analysis approach based on the use of Colored Petri Nets, Timed Colored Petri Nets and the CPN

Tools

Panagiotis [email protected] - http://delab.csd.auth.gr/~katsaros/

Department of Informatics

Aristotle University of Thessaloniki

G R E E C E


Few words for CP-nets Colored Petri Nets is a Petri Net (PT-net) based

modeling language that as all other PT-net languages

provides an explicit representation of both states (markings) and events (transitions)

provides an easy to understand and intuitively appealing graphical representation

has a well-defined formal semantics that builds upon true concurrency, instead of interleaving

use of appropriate tools to generate interactive simulations of the modeled systems and to apply a wide range of formal analysis alternatives


Few words for CP-nets CP-nets compared to simple PT-nets

provide a more compact and much more convenient modeling language, in a similar way as high-level programming languages are much more adequate for practical programming than assembly code

have been developed over the last 28 years (research team lead by Prof. K. Jensen in Aarhus Un., Denmark) and today constitute a mature modeling language supported by an advanced toolset (CPN Tools with about 3500 worldwide installations used in academic & industrial problems)


Few words for CP-nets CP-nets compared to simple PT-nets

provide a compact description of control and synchronization, integrated with a description of data manipulation

provide support for building large system models, by relating smaller CP-nets to each other in a well-defined way (hierarchical CP-nets)

provide a CP-net variant called Timed CP-nets to analyze systems with time-dependent behavior, like for example systems with timing constraints

in CPN Tools, models are saved in an XML representation (possible to automatically generate CP-nets)


Few words for CP-nets

A very simple CP-net places (their markings, that is, their tokens collectively represent CP-net’s states)they are typed (tokens have data values) and they can have initial values

transitions represent events (incoming arcs remove tokens – outgoing arcs add tokens)

(* declarations *)

colset E = with e;

colset INT = int;

colset BOOL = bool;

colset STRING = string;

colset daytime = with day | night;

colset sList=list STRING;

var anInt:INT;

var messages:sList;

var aDayTime:daytime;


Our approach use an automaton-driven model building approach for

individual CP-net components build the CP-net model hierarchy generate the state space graph and perform the standard

state space analysis (standard report) check the system’s safety and liveness properties

(terminal self loops, deadlocks, livelocks, fairness properties etc)

model check other correctness properties by querying the state space graph or by applying a Computation Tree Temporal Logic (CTL) formula over the generated graph

possible to be extended in building CP-nets for component-based software and for systems with timing constraints (Timed CP-nets) and then in model checking the required correctness properties


Case study: electronic payment transactions

we model check the NetBill electronic payments system with respect to a range of transaction atomicity guarantees that the system should provide in all circumstances

we build the state machines for each one of the three transaction parties, namely the Consumer (C), the Merchant (M) and the Trusted Third Party (TTP)

we assume that the TTP fulfills a range of trust assumptions and we model check the transaction guarantees of interest in all cases of participants’ system failures (fail-stop failures), message losses and fraudulent behavior

Katsaros, P. A roadmap to electronic payment transaction guarantees and a Colored Petri Net model checking approach, Technical Report, Department of Informatics, Aristotle University of Thessaloniki, Greece, 2006 (50 pages - available in http://delab.csd.auth. gr/~katsaros/publications.htm)


The top-level CP-net(* declarations *)

colset validORnValid = with v | i;

colset accBalance = with gValue | lessMoney;

colset State = with IDLE | WAIT | W_FAILED |

ABORTED | COMMITTED| C_FAILED | COMPLETED|

DISPUTED_TR | LISTEN| NO_RECORD |

L_FAILED| STARTED_TR | ST_FAILED| N_FAILED;

colset NetBillMSg= union gRequest:validORnValid + eGoods:validORnValid+ pORequest:validORnValid+ trResult:STRING+ dKey:validORnValid+ query:E;

colset NetBillMQ= list NetBillMSg;

var p,q,r,s: NetBillMQ;var mes,mes2: NetBillMSg;

var gReq:validORnValid;var pOrder:validORnValid;

var enGoods: validORnValid;

var balance: accBalance; var timer,timer2: BOOL;

var key: validORnValid; var st: State;


Consumer’s state machine and CP-net

irrespective of the occurred site failures a consumer either aborts or completes a purchase transaction and the received goods are either the ordered ones or are not as expected for the ordered ones

ID LE

W A IT

W _FA ILED

ABORTED COMM ITTED

C _FA ILED

COM PLETEDD ISPU TED _TR

C 1

C 2C 3C 4

C 5

C 6

C 7

C 1 1C 1 2 C 1 4

C 8 C 9C 1 0

C 1 5

C 1 3C 1 6

C 1 7

C 1 8C 1 9


Consumer’s state machine and CP-net


Merchant’s state machine and CP-net

we abstract from candidate recovery mechanisms (which would result in loss of generality) by adopting the assumption that merchant’s site does not provide recovery with respect to the ongoing purchase transaction

L ISTEN

ABORTED

STARTED _TR

COM PLETED ST_FA ILED

M 2

M 3

M 1

L_FA ILED

M 6

M 7

M 9M 1 0M 5

M 1 1

M 4

M 8M 1 2

M 1 3


Merchant’s state machine and CP-net


TTP’s state machine and CP-net

trust assumptions imply that irrespective of the occurred site failures or message losses the TTP either aborts or completes the purchase transaction and delivers the transaction result as expected

N_FA ILED

L_FA ILED

ST_FA ILEDSTARTED _TR

T T P 1 ABORTEDNO _RECORD

COM PLETED

T T P 2T T P 3

T T P 4 T T P 5T T P 6

T T P 7

T T P 8

T T P 9

T T P 1 0

T T P 1 1

T T P 1 2

T T P 1 3

T T P 1 4


TTP’s state machine and CP-net


Standard state space analysisStatistics

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

State Space

Nodes: 6439

Arcs: 18915

Secs: 30

Status: Full

Scc Graph

Nodes: 2678

Arcs: 11257

Secs: 2

Boundedness Properties

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

Best Integers Bounds Upper Lower

Consumer'decrKey 1 1 0 TTP'TTP 1 1 1

Consumer'encrGoods 1 1 0 TTP'amount 1 1 0

Consumer'goodsReq 1 1 1 TTP'decrKey 1 1 0

Consumer'pOrderReq 1 1 0 TopLevel'ConToMer 1 1 1

Merchant'Merchant 1 1 1 TopLevel'ConToTTP 1 1 1

Merchant'decrKey 1 1 0 TopLevel'Consumer 1 1 1

Merchant'pOrderReq 1 1 0 TopLevel'MerToCon 1 1 1

Strongly Connected Components Graph

upper and lower bounds of all token values that is possible to appear in the CP-net’s places in all reachable states (markings)


Standard state space analysisHome Properties

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

Home Markings: None

Liveness Properties

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

Dead Markings: 72 [963,665,592,5905,5890,...]

Dead Transitions Instances: None

Live Transitions Instances: None

Fairness Properties

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

Consumer'C1 1 No Fairness


Consumer'C11 1 Fair

Consumer'C12 1 Fair

Consumer'C13 1 Fair

Consumer'C14 1 Just

Consumer'C15 1 Just

Consumer'C16 1 Just


Consumer'C18 1 Fair

Consumer'C19 1 Fair



Merchant'M13 1 No Fairness



TTP'TTP1 1 No Fairness

TTP'TTP10 1 No Fairness

markings or sets of markings to which it is always possible to return

- markings with no enabled transitions- transitions not enabled in a reachable marking- transitions that always can become enabled once more

information about how often the individual transitions occur (impartial, fair, just)


Model checking system’s safety & liveness properties

CPN Tools provides appropriate functions for querying the generated state space graph

to find the dead markings (valid termination states or deadlocks):let

val fid = TextIO.openOut "ListOfDeadMarkings.txt" val _ = TextIO.output(fid, "List of dead markings: \n") val _ = EvalNodes(ListDeadMarkings(), fn n => INT.output(fid,n) ) val _ = TextIO.output(fid, "\nNumber of dead markings: ") val _ = INT.output(fid,length (ListDeadMarkings())) in TextIO.closeOut(fid) end

type ListOfDeadMarkings.txt List of dead markings: 963 665 592 5905 5890 5875 5860 5269 5249 5229 5209 519 518 516 515 3555 3549 3543 3537 3380 3377 3373 3370 3366 3360 3169 3166 3144 3138 3132 3126 2969 2966 2962 2959 2955 2949 2758 2755 2716 2708 2687 2679 2648 2640 2619 2611 1925 1922 1921 1920 1851 1841 1833 1815 1805 1797 1793 1790 1786 1783 1725 1715 1707 1689 1679 1671 1667 1664 1660 1657 1084 Number of dead markings: 72



to verify the absence of self-loop terminal nodes:

fun SelfLoopTerminal n=(OutNodes(n)=[n]) fun InValidTerminal()=PredNodes(EntireGraph, fn n => (SelfLoopTerminal n), NoLimit); let val fid = TextIO.openOut "ListOfSelfLoops.txt" val _ = TextIO.output(fid, "List of self loop terminals: \n") val _ = EvalNodes(InValidTerminal(), fn n => INT.output(fid,n) ) in TextIO.closeOut(fid) end

type ListOfSelfLoops.txt List of self loop terminals:



to verify the absence of unexpected dead markings (deadlocks):fun ValidTerminal n=(length (hd (Mark.TopLevel'ConToMer 1 n))=0 andalso

length (hd (Mark.TopLevel'MerToCon 1 n))=0 andalso length (hd (Mark.TopLevel'ConToTTP 1 n))=0 andalso length (hd (Mark.TopLevel'TTPtoCon 1 n))=0 andalso length (hd (Mark.TopLevel'MerToTTP 1 n))=0 andalso length (hd (Mark.TopLevel'TTPtoMer 1 n))=0 andalso (Mark.Consumer'Consumer 1 n=[ABORTED] andalso Mark.TTP'TTP 1 n=[ABORTED] andalso (Mark.Merchant'Merchant 1n=[ABORTED] orelse Mark.Merchant'Merchant 1n=[L_FAILED] orelse Mark.Merchant'Merchant 1n=[ST_FAILED]) orelse Mark.Consumer'Consumer 1 n=[DISPUTED_TR] andalso Mark.TTP'TTP 1 n=[COMPLETED] andalso (Mark.Merchant'Merchant 1 n=[COMPLETED] orelse Mark.Merchant'Merchant 1 n=[ST_FAILED] orelse Mark.Merchant'Merchant 1 n=[ABORTED]) orelse Mark.Consumer'Consumer 1 n=[COMPLETED] andalso Mark.TTP'TTP 1 n=[COMPLETED] andalso (Mark.Merchant'Merchant 1 n=[COMPLETED] orelse Mark.Merchant'Merchant 1 n=[ST_FAILED] orelse Mark.Merchant'Merchant 1 n=[ABORTED]))) fun InValidTerminal()=PredNodes(ListDeadMarkings(), fn n => not (ValidTerminal n), NoLimit); let val fid = TextIO.openOut "DeadlockMarkings.txt" val _ = TextIO.output(fid, "List of deadlock markings: \n") val _ = EvalNodes(InValidTerminal(), fn n => INT.output(fid,n) ) in TextIO.closeOut(fid) end

type DeadlockMarkings.txt List of deadlock markings:



to verify the absence of livelocks (reachable cycles with no exit):

if the state space and its Scc graph are isomorphic and also there are no self-loops, then the protocol model is free of livelocks

if the state space contains self-loops or if there is at least one strongly connected component that consists of more than one node, then we need to show that all terminal components are trivial that is, they consist of a single node and no arcs.

fun ListTerminalSCCs()=PredAllSccs(SccTerminal); fun InValidTermSCC()=PredSccs(ListTerminalSCCs(), fn n => not (SccTrivial n), NoLimit); let val fid = TextIO.openOut "AbsenceOfLivelocks.txt" val _ = if InValidTermSCC()=[] then TextIO.output(fid, "No Livelocks!") else TextIO.output(fid, "Livelocks detected!") in TextIO.closeOut(fid) end

type AbsenceOfLivelocks.txt No Livelocks!


Model validation

model validation is performed by model checking the system’s model assumptions (e.g. trust assumptions for the shown payment system)

for system properties that imply certain temporal dependencies for the occurrence of certain events we use the ASK-CTL library to express them as Computation Tree Temporal Logic formulae


Computation Tree Temporal Logic Formulae money atomicity: there is no possibility of creation or

destruction of money, while electronic cash is being transferredwe model check that there is no reachable path, where for every state neither M nor C has the money and there is also no reachable path, where for every state both M and C have the moneyfun debitC a = (ArcToTI a = TI.TTP'TTP7 1); val debitTIs = PredArcs(EntireGraph, fn a => (debitC a), NoLimit); fun moneyLoss n = ((Mark.TopLevel'conBalance 1 n=[] andalso Mark.TopLevel'merBalance 1 n=[]) orelse (Mark.TopLevel'conBalance 1 n<>[] andalso Mark.TopLevel'merBalance 1 n<>[])); val debitAction = AF("No debit!",debitC); val mLossForm = MODAL(NF("",moneyLoss)); val noMoneyConservation = INV(ALONG(mLossForm)); fun verify a = eval_arc noMoneyConservation a; val results = map verify debitTIs; let val fid = TextIO.openOut "MoneyConservation.txt" val _ = if (cf(true,results)>0) then TextIO.output(fid,"No money conservation!") else TextIO.output(fid,"Protocol does not create or destroy money!") in TextIO.closeOut(fid) end

type MoneyConservation.txt Protocol does not create or destroy money!


Computation Tree Temporal Logic Formulae

Other transaction guarantees verified as CTL formulae:

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

certified delivery: includes money atomicity and goods atomicity and also allows C and M to prove the details of the transaction (not proved before in related work)

protection of participants’ interests:C’s protection guarantee: if M is entitled to a payment, then C actually receives the goods, or C can claim them in an offline dispute handlingM’s protection guarantee: . . .(not proved before in related work)


Additional model checking tasks

to generate a property violation scenario (counterexample), if any:in the NetBill payment system we generated a replay attack scenario (double spending) by the use of appropriate state space querying functions (countermeasures had already been proposed by the system’s inventors)

model checking concurrent payment transactions and intruder attack scenariosmain problem: inappropriate model structure is easy to result in a computationally expensive state spacesolution alternatives:

- to generate the state space only partially, according to specific search criteria

- to apply clever state space reduction techniques


CP-net analysis alternatives place invariant or transition invariant analysis

place invariant analysis aims to formulate some equations which we postulate to be satisfied independently of the steps that occurtransition invariants are similar to place invariants, but they are use to determine transition occurrence sequences that have no total effect, i.e. they have the same start and end markings

make possible to prove general system properties without fixing system parameters

it is possible to check invariants without considering the set of all reachable markings (no need to generate the state space)

formulating appropriate equations for a system property is not a easy task in all cases

very limited tool support


Timed CP-nets

Each token, in addition to its data value carries a time stamp. The time stamp tells us when the token is ready to be used by a transition.

We specify how the different activities and states “consume” time. It is possible to specify al kinds of delays (constant, interval, or probability distribution).

The nodes in the generated state space graph contain a time value and a timed marking.


Timed CP-nets

Possible analyses:

- to prove properties like for example: “for each instance of a

given transition firing (activity start) exists an instance of the

corresponding transition firing (activity end) such that the

deadline of execution is less than a fixed time value”

- to calculate the maximal time used for the execution of

certain activities (worst execution time analysis)

- simulation based performance evaluation


Conclusion CP-nets seem to be a modeling language for many different

types of analysis

need to invest on a systematic (and possibly automated) model building approach which should possibly employ specialized state space reduction techniques

Future research prospects: possibilities to exploit Timed CP-net model analysis for the

schedulability analysis of systems with timing constraints

possibilities to exploit existing know-how in order to systematically generate CP-nets for component-based software

to investigate the effectiveness of existing or new state space reduction techniques in different component software cases

Documents

Panagiotis Katsaros [email protected] - delab.csd.auth.gr/~katsaros