ADDRESSING SECURITY REQUIREMENTS THROUGH

MULTI-FORMALISM MODELLING AND MODEL

TRANSFORMATION

Miriam Zia, Ernesto Posse and Hans Vangheluwe

School of Computer Science, McGill University, 3480 University Street, Montreal, Canada

Keywords:

Multi-formalism modelling, model transformation, veriﬁcation, security requirements, e-health.

Abstract:

Model-based approaches are increasingly used in all stages of complex systems design. In this paper, we

use multi-formalism modelling and model transformation to address security requirements. Our methodol-

ogy supports the veriﬁcation of security properties using the model checker

FDR2 on CSP (Communicating

Sequential Processes

) models. This low-level constraint checking is performed through model reﬁnements,

from a behavioural description of a system in the

Statecharts formalism. The contribution of this paper lies in

the combination of various formalisms and transformations between them. In particular, mapping

Statecharts

onto CSP models allows for combination of the deterministic system model with non-deterministic models

of a system’s environment (including, for example, possible user attacks). The combination of system and

environment models is used for model checking. To bridge the gap between these

Statechart and CSP models,

we introduce

kiltera, an intermediate language that deﬁnes the system in terms of interacting processes. kiltera

allows for simulation, real-time execution, as well as translation into CSP models. An e-Health application is

used to demonstrate our approach.

1 INTRODUCTION

Model-driven approaches are becoming more preva-

lent in complex software systems engineering.

Methodologies are developed which control the com-

plexity of the software process and address system

speciﬁcations at higher levels of abstraction. Tools

are becoming available to automate the transforma-

tion between models, which possibly reside at differ-

ent abstraction levels (Muller et al., 2005; de Lara

and Vangheluwe, 2002), and to support their anal-

ysis (Bengtsson et al., 1995; Gardey et al., 2005).

By hiding implementation details, and manipulating

models described at an appropriate level of abstrac-

tion using suitable (possibly domain-speciﬁc) mod-

elling formalisms systems are developed from high-

level concepts, though model reﬁnements and analy-

sis.

Model-based approaches are increasingly used in

all stages of systems design, and in recent years, have

evolved around the development of dependable sys-

tems that must respect safety or reliability require-

Figure 1: A model-driven engineering approach. We focus

on the veriﬁcation branch.

ments, amongst others. While various methodolo-

gies have been designed to tackle these dependabil-

ity issues (Mustaﬁz et al., 2006), other emerging con-

straints, such as security and privacy, need to be ad-

dressed. Indeed, as the Internet evolves, from being

a basic communication mechanism to being a tool

for effective business operation and service provision,

more sensitive information is digitized. As a conse-

129

Zia M., Posse E. and Vangheluwe H. (2007).

ADDRESSING SECURITY REQUIREMENTS THROUGH MULTI-FORMALISM MODELLING AND MODEL TRANSFORMATION.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 129-137

DOI: 10.5220/0001347201290137

 SciTePress

quence, various e-applications require the access to,

manipulation, and transfer of this digital data, thus

making it susceptible to third-party attacks, or even

user abuses. Such e-systems must, therefore, be: 1)

secure, and designed in such a way that agents (users

or programs) can only perform allowed actions; and

2) privacy-sensitive, and effectively protect personal

data from unauthorized access or disclosure.

Research has been carried out in the study of com-

puter security and electronic privacy, and has mostly

tackled problems in the network and communica-

tion domains. The work in that area is geared to-

wards representing security threats in terms of at-

tack graphs (Sheyner et al., 2002) and in developing

model-checking methods for the veriﬁcation of the se-

curity of communication (Lowe, 1996) or registration

protocols (Germeau and Leduc, 1997). The latter re-

quire detailed model descriptions of the protocols, in

languages such as the

Communicating Sequential Pro-

cesses

(CSP) (Hoare, 1985) or LOTOS (ISO, 1989),

to be checked with veriﬁcation tools, such as the

Fail-

ures Divergences Reﬁnement Checker

(FDR2). How-

ever, what these approaches do not offer is a general,

application-independent methodology for represent-

ing a security problem at a high level, in such a way

as to abstract complex details from, for example, a

designer who needs to check that speciﬁc properties

hold on a new security protocol being developed.

In (Yeung et al., 2005) and (Roscoe and Wu,

2006), transformations are deﬁned, which trans-

late high-level behavioural models of a system into

models suitable for veriﬁcation with

FDR2. This

work represents a step towards a general method-

ology for the veriﬁcation of requirements through

multi-formalism modelling and model transforma-

tion. An example of this approach has been pro-

posed for designing controlled anonymous applica-

tions (Naessens, 2006). Our contribution lies in in-

troducing a multi-formalism model-driven method-

ology which supports requirements analysis and re-

ﬁnement, simulation-based performance analysis, and

code synthesis. It is geared towards security con-

straint analysis and veriﬁcation.

At each step of a multi-formalism design method-

ology, the system under consideration is modelled in

the most suitable formalism (Figure 1). At the high-

est level, a domain-speciﬁc model appropriately de-

scribes the domain problem. From this model, one

of two models can be derived. If the problem’s state-

space is too large for model-checking, a simulation

model is constructed in a formalism with strong sim-

ulation capabilities. The gathered simulation results

are used for performance analysis or are checked

against a set of rules derived from the requirements.

Figure 2: A model-based process for security requirement

analysis.

Alternatively, an analysis model may be constructed

in a formalism amenable to formal analysis and veri-

ﬁcation of the system requirements, covering all pos-

sible behaviours. Ultimately, an execution model is

synthesized from the domain model, thus providing

a continuous design process from the domain prob-

lem to the analysis model, and ﬁnally to the deployed

system. All steps in the evolution, from requirements

and constraints, to ﬁnal application, represent the sys-

tem at different levels of abstraction. Transformations

between models represent reﬁnements.

We present such a process to deal with security

requirements. As depicted in Figure 2, this pro-

cess allows for low-level constraint checking, through

model reﬁnements, from higher-level system speciﬁ-

cations. At a high level of abstraction, we have a be-

havioural description of the system in a known for-

malism, such as in

Statecharts. At a lower level, ver-

iﬁcation of desired properties is performed with ex-

isting tools, such as

FDR2,onCSP models. Since

models in

Statecharts only depict required system

behaviour and not that of the environment actors on

this system, our approach introduces a middle step

in the design, which acts as a central hub for model

transformations. Although

Statechart models could

be veriﬁed at this level, they are ﬁrst translated into

a language which allows for the concise description

of non-deterministic (environment) behaviour. These

intermediate models are described in the modelling

language

kiltera (Posse and Vangheluwe, 2007). The

nature of the

kiltera language allows a straightforward

translation into a

CSP model, which is subsequently

checked to ensure that, given the actors involved in

the environment, the original system design adheres

ICSOFT 2007 - International Conference on Software and Data Technologies

130

to the required security constraints.

The paper is structured as follows. Section 2

presents background concepts relating to the

CSP and

the

kiltera modelling languages, as well as the e-health

case study chosen to illustrate our methodology. Sec-

tion 3 proposes our modelling and veriﬁcation pro-

cess, for designing a secure infrastructure. The steps

involved in this process are illustrated on an e-health

use case. Finally, we draw some conclusion about our

methodology in Section 4.

2 BACKGROUND

Since UML Sequence Diagrams (Rumbaugh et al.,

1999) and Harel’s

Statecharts (Harel, 1987) are

widely used modelling formalisms, in this section we

focus, on the one hand, on giving an overview of the

CSP and kiltera languages, and on the other hand, on

introducing the e-health example used in this paper.

2.1 Multiple Formalisms

The Communicating Sequential Processes (CSP) and

kiltera languages were both designed for describing

systems of communicating components. In these lan-

guages, a process is described in terms of the possible

interactions it can have with its environment. Interac-

tions are described in terms of instantaneous atomic

synchronizations, or events. Each process is an in-

dependent computational unit and proceeds concur-

rently with all other processes. Furthermore, a pro-

cess is not necessarily a purely sequential computa-

tion, as it may be itself composed of parallel subpro-

cesses. In

CSP, a process is deﬁned by its interface,

grouping all the events it may engage in, and through

which it interacts with other processes. In

kiltera,a

process is a modular component with a well deﬁned

interface consisting of a set of ports, through which

all interactions occur.

CSP, three semantic models are available to

reason about observable behaviour of processes, and

to provide foundations for speciﬁcation and veriﬁca-

tion techniques. The simplest of these mathematical

models is the traces model. In

CSP, each process is

represented by its set of ﬁnite sequences of commu-

nications it can perform, or set of traces. In the traces

model, system constraints are speciﬁed on traces, by

characterizing which traces are acceptable, and which

are not. These speciﬁcations are then used for traces

reﬁnement.

In contrast,

kiltera’s focus is on simulation of dy-

namic systems with an explicit notion of time and

structural change. Simulation is typically used for

performance analysis (non-functional requirements).

kiltera combines the interaction and mobility model

of the π-calculus (Milner et al., 1989) with the time

model of

Timed-CSP (Reed and Roscoe, 1986) in a

single framework. Its formal semantics are given in

terms of timed-labelled transition systems, which pro-

vides a basis for formal system analysis as well as a

framework to relate

kiltera to other languages and for-

malisms.

2.2 e-Health Case Study

adapID

is a project aimed at developing a framework

for secure and privacy-preserving applications based

on the Belgian e-ID card. The electronic ID card in

Belgium is the ﬁrst smart card with advanced pub-

lic key cryptology capabilities, and contains digital

personal data that may identify the card holder, and

possibly lead to some privacy risks for the individual

citizens. The focus of the project is on the develop-

ment of a framework for advanced secure applications

of the e-ID which do not reduce personal privacy of

the users. Our focus primarily lies in e-health appli-

cations, and the security constraints they need to ad-

dress.

E-health addresses the problem of improving the

quality and efﬁciency of health care, as well as the

reduction of corresponding costs, through the innova-

tion of information and communication technologies.

These advances all rely on the development of infor-

mation systems, which store patient related informa-

tion. Since a patient’s medical history is accessible by

care givers, it aids them in administering more appro-

priate services. However, abuses of the system pose

severe security and privacy risks, for example if the

e-health application is misused or if unauthorized ac-

cess to a medical record is obtained.

2.2.1 Use Case: Visiting a Pharmacist

The following introduces a simpliﬁed “visiting a phar-

macist” e-health system to be developed. We will use

this case study to illustrate the methodology described

in Section 3, and verify the security constraints it must

adhere to.

The actors in one of the use cases in this case study

are a pharmacist and a patient. A patient receives

an electronic prescription from a doctor, who signs it

with his e-ID card to guarantee its integrity. To get the

prescription ﬁlled, the patient visits a pharmacist who

uses his e-ID card to prove his pharmacist credential.

Once the pharmacist shows his recognition, the pa-

tient anonymously shows him the prescription, with-

https://www.cosic.esat.kuleuven.be/adapid/

ADDRESSING SECURITY REQUIREMENTS THROUGH MULTI-FORMALISM MODELLING AND MODEL

TRANSFORMATION

131

out his or the doctor’s identity ever being revealed.

The drugs are issued to Patient upon veriﬁcation of

the validity of the prescription.

The security requirements related to this use case

are as follows:

1. A malicious patient or pharmacist should not be

able to successfully show a non-valid credential;

2. A malicious patient should not succeed in submit-

ting a forged, altered or already ﬁlled prescription.

In either case of abuse, it should be possible to

deanonymize the culprits.

3 MODEL-BASED PROCESS

This section describes the multi-formalism modelling

process illustrated in Figure 3. Note that this is a con-

crete reﬁnement of Figure 2 Note also that we only

describe a simple use case her. Related work (Whittle

and Schumann, 2000; Whittle and Jayaraman, 2006)

shows how use cases (representing requirements) can

be described using a collection of sequence diagrams

and activity diagrams. The latter show allowed se-

quences of use cases for subsequent translation into

Statecharts.

3.1 Overview

Initially, the functional software requirements of a

system, for which we want to address security con-

straints, are described by a

Sequence Diagram.A

Statecharts functional system design model satisfy-

ing the requirements is derived from this description

to represent the structure and behaviour of the desired

system.

Secondly, we construct an environment model in

kiltera, to describe all possible interactions of the user

with the system. We now have two models: a de-

terministic

Statechart model of the functional system

and a non-deterministic

kiltera model of the system

environment. Then, the

Statecharts model is trans-

lated into a

kiltera one with an equivalent behaviour.

The

kiltera functional system model is then integrated

with the system environment (actors) model. Grouped

together, these

kiltera models are a representation of

the behaviour of environment and the system. At this

point, it is possible to carry out extensive simulations

(1) to gain insight into the dynamic behaviour of the

system and (2) to analyze performance metrics (non-

functional requirements). This aspect is not elabo-

rated further in this paper.

Thirdly, a second set of model transformation

rules is used to transform the

kiltera behaviour and

environment model into an equivalent, but lower-level

CSP representation. Combined with a CSP descrip-

tion of security requirements, a system security veriﬁ-

cation model is checked with the tool

FDR2. Finally,

the output from the model checker conﬁrms whether

the constraints are satisﬁed in the proposed design of

the system, or whether further modiﬁcations need to

be applied to the top level

Statecharts model.

In the following, we further discuss the steps in-

volved in this proposed methodology, and illustrate

each step with an application to the use case described

in Section 2.2.1.

3.2 Capturing Requirements:

Modelling with Sequence Diagrams

and Statecharts

Our model-driven process begins with a speciﬁca-

tion of the system requirements, in the form of a

Se-

quence Diagram

. The Sequence Diagram, illustrated

in Figure 4 summarizes the required behaviour of the

“Visiting a pharmacist” use case, and represents the

ﬂow of actions between the two actors of the system

(the pharmacist and the patient). From this speciﬁca-

tion, a

Statechart model (Figure 5) is automatically

constructed as a very preliminary system design of

the ﬁnal application. The sending and receiving of

events in the different orthogonal components corre-

sponds to message sending in Figure 4. The transla-

tion between

Sequence Diagrams and Statecharts is

described in (Sun, 2007). Referring back to Figure 1,

another advantage of using this formalism is that we

can synthesize executable code from it (Feng, 2004).

3.3 Adding Non-deterministic

Environment Scenarios:

Statecharts

and kiltera

At this point, properties of the design encoded in the

Statechart model could be veriﬁed directly. Non-

deterministic formalisms such as

kiltera are more

suitable (than

Statecharts) to describe large num-

bers of environment scenarios (corresponding to non-

functional constraints) compactly. We prefer not to

use

Statecharts for veriﬁcation. For this reason, we

propose a series of model transformations and reﬁne-

ments, resulting in a

CSP model ready for checking.

Note that we are currently working on a formalization

of these transformations. The ﬁrst such transforma-

tion generates a description in

kiltera. Here we pro-

vide a brief sketch of how

Statecharts are translated

into

kiltera processes. Each Statechart blob (AND

or OR state) is mapped to a

kiltera process, preserv-

ICSOFT 2007 - International Conference on Software and Data Technologies

132

Figure 3: From behaviour models to veriﬁcation models: a multi-formalism and model transformation approach for addressing

security constraints.

ing the nesting structure of the Statechart. For each

composite blob, we create an additional

kiltera pro-

cess called a “relay”, which keeps track of the cur-

rently active substate(s), takes care of events relevant

to that blob, and forwards messages intended for other

“blobs”. Each

kiltera process corresponding to a blob

has two ports: one which connects it to its parent “re-

lay” and one output port. All messages go through

these ports and therefore the structure of the overall

kiltera process is completely modular, unlike a State-

chart

which may have transitions that cross a blob’s

boundaries. Finally, the obtained

kiltera model gets

simpliﬁed. This simpliﬁcation can increase simula-

tion and veriﬁcation performance, albeit at the cost of

sacriﬁcing some modularity. The advantage of us-

ing

kiltera at this level is due to its simulation engine.

Such simulation capability is not supported for

CSP

models, for which the closest equivalent to a simula-

tor would be the tool

ProBE (Formal Systems Europe

Ltd., 2003), an animator for

CSP processes allowing

the user to manually explore the behaviour of models.

Running simulations of a

kiltera model is useful

for exploring a subset of the system’s entire state-

space, or for performance analysis. As a matter of

fact, we can deﬁne performance metrics to be checked

on the simulation results. Examples of a performance

metric are the likelihood that a security constraint

in breached, or an estimate of how many security

breaches occur over the simulated time interval. The

system modelled in

Statecharts (Figure 5) consists

of self-contained interacting components, which can

conceptually be considered as communicating pro-

cesses. The ﬂow of actions between these processes

deﬁnes the sequence and type of interactions that can

occur between them, and is used to deﬁne the pro-

Figure 4: UML Sequence Diagram representing the “Visit-

ing a pharmacist” system requirements.

cess event interface. These processes can be seen as

synchronizing over the set of events which are com-

mon to the orthogonal

Statechart components. Note

that we are using Statemate

Statecharts for histori-

cal reasons. Future work will map onto UML

Stat-

echarts

. This has the advantage that it will make

classes (whose instances appear in Figure 4) explicit.

Currently, those classes are implicitly associated with

the Statemate

Statecharts’s orthogonal components.

From Figure 4, we note that the interactions taking

place between the two actors of the system, can be

viewed as occurring between a Pharmacist and a Pa-

tient processes. Below is the description of the Patient

process in

kiltera:

ADDRESSING SECURITY REQUIREMENTS THROUGH MULTI-FORMALISM MODELLING AND MODEL

TRANSFORMATION

133

Figure 5: A Statechart. model of a design satisfying the requirements.

process

Patient[secureComm, authority]

(PatientCredential, Prescription):

sync send

PatientCredential to secureComm ->

sync receive

PharmacistCredential from secureComm ->

PharmacistCredential = "pharmacistCred"

then

sync send

Prescription to secureComm ->

sync receive

result from secureComm ->

result = "FillPres"

then

Prescription := "filledpres" ->

Patient[secureComm, authority]

(PatientCredential, Prescription)

else

send

"reportPhCredFraud" to authority

The system environment is introduced into the model

in the form of attack threats by the system actors.

As such, the environment is not modelled in external

components, but also inside the system components.

In the case of our e-health application for example,

the system actors may present invalid credentials, or

attempt to produce fraudulent prescriptions.

A simulation run on the

kiltera behaviour and en-

vironment model generated for the “Visiting a phar-

macist” use case, generates the following trace

<t=0.004 send patientCred port=secureComm in Patient>

<t=0.004 receive patientCred port=secureComm in Pharmacist>

<t=0.005 send ptValidatedCred port=authority in Pharmacist>

<t=0.007 send pharmacistCred port=secureComm in Pharmacist>

<t=0.007 receive pharmacistCred port=secureComm in Patient>

<t=0.008 send phValidatedCred port=authority in Patient>

<t=0.009 send filledpres port=secureComm in Patient>

<t=0.009 receive filledpres port=secureComm in Pharmacist>

<t=0.011 send FillPres port=secureComm in Pharmacist>

In this output, we notice a suspicious sequence of

events, probably reﬂecting a breach of a security con-

straint. Indeed, it appears as though a previously pro-

cessed prescription is being reﬁlled. This could rep-

resent a ﬂaw in the system design, and certainly in-

dicates that the

Statechart model should be reviewed.

The trace syntax has been altered from its original and

made more concise for clarity.

We can now perform the kiltera to CSP model trans-

formation, and do full model checking of all possi-

ble behaviours using FDR2. Since both languages

deﬁne similar constructs (though

kiltera adds variable

structure –not used here– and time), the translation

between models is mostly concerned with the trans-

lation of time into a CSP clock process. Note that

if we did not require efﬁcient simulation capabilities,

we could skip the intermediate

kiltera step and directly

translate

Statecharts to CSP.

3.4 Veriﬁcation with FDR2 of the

Generated

CSP Model

We perform veriﬁcation of security constraints on a

model translated from the behaviour and environment

model described in Section 3.3. Following

CSP ter-

minology, this model is referred to as the implemen-

tation of the desired system.

Security requirements are directly captured in

terms of restrictions on traces that the implementation

process may engage in. These restrictions on traces

are referred to as

CSP trace speciﬁcations: either a

description of a set of permissible traces, or alterna-

tively, a set of unacceptable traces leading to an er-

roneous (security-breaching) state. Either way, this

description is given in terms of a process (which we

refer to as security speciﬁcation process), which cor-

responds to a set of traces it can exhibit. We take this

set to give precisely that secure behaviour which is

required.

The speciﬁcation process, along with the imple-

mentation model, are input into the

FDR2 tool and its

traces-reﬁnement checker will verify whether the im-

plementation trace-reﬁnes the security speciﬁcation.

ICSOFT 2007 - International Conference on Software and Data Technologies

134

In CSP trace-reﬁnement, an implementation process

is said to reﬁne the speciﬁcation if all possible se-

quences of communication which it can perform are

also possible for the speciﬁcation process.

If the required security constraints are not effec-

tively implemented in the original

Statecharts model,

in the case where the speciﬁcation process described

the permissible secure behaviour,

FDR2 will reﬂect

the failure to pass the

CSP security trace speciﬁca-

tions. In fact, the tool outputs a counter-trace, result-

ing from a sample execution that led to a security-

violating state. In the case that the speciﬁcation pro-

cess described unacceptable behaviour, the breach of

security is revealed if

FDR2 ﬁnds that the implemen-

tation reﬁnes the erroneous behaviour description.

Therefore, in either case, the veriﬁcation indicates

a ﬂaw in the original design, and points out the ar-

eas which need to be further tuned to achieve secu-

rity. Design changes are directly made to the top-level

Statecharts model, which is again transformed into a

CSP model for further veriﬁcation.

Applying this step to our example, the following

is the

CSP process equivalent to that described in Sec-

tion 3.3:

PATIENT

(PatientCredential, prescription) =

secureComm!PatientCredential

-> secureComm?PharmacistCredential ->

PharmacistCredential == pharmacistCred

then

pharmacistAccredited

-> session!Prescription -> PATIENT

else

pharmacistNotAccredited

-> contactAuthority -> PATIENT

The security constraints described in Section 2.2.1 are

translated into permissible sequences of event occur-

rences, which describe a secure behaviour of the sys-

tem. For the second security constraint, relating to the

validity of the prescription, the following three speci-

ﬁcation processes are described:

VALID_PRES_FILLING = patientAccredited

-> pharmacistAccredited -> prescriptionIsValid

-> fillprescription -> commit

-> VALID_PRES_FILLING

FORGED_PRES_FILLING = patientAccredited

-> pharmacistAccredited -> prescriptionIsForged

-> deanonymizePatient -> FORGED_PRES_FILLING

FILLED_PRES_FILLING = patientAccredited

-> pharmacistAccredited -> prescriptionIsFilled

-> deanonymizePatient -> FILLED_PRES_FILLING

The CSP implementation model generated above

was reﬁnement-checked against these speci-

ﬁcation processes, and was found to fail the

FILLED

PRES FILLING speciﬁcation. In fact, the

kiltera simulation in Section 3.3 had already warned

us regarding this problem. The prescription-related

security requirements were not fully addressed

in the initial system design. This resulted in the

Figure 6: An FDR2. screenshot, reﬂecting the

successful check of a security requirement. Here,

FILLED

PRES FILLING is the speciﬁcation process, ﬁlled-

Prescription

SECURITY PROPERTY is the security asser-

tion, and the remaining are implementation processes.

unsuccessful check of the FILLED PRES FILLING

speciﬁcation, and the following counter event trace

was produced by

FDR2 to reﬂect the execution of a

sequence of events leading to this outcome:

pharmacistLocalAuthentication

patientLocalAuthentication

secureComm.patientCred

patientAccredited

secureComm.pharmacistCred

pharmacistAccredited

session.filledpres

prescriptionIsFilled

fillprescription

The counter-example shows that although a prescrip-

tion was veriﬁed and found to have previously been

ﬁlled, the system allowed a reﬁlling of the prescrip-

tion. A second implementation of this system is gen-

erated from a modiﬁed

Statecharts design where the

issue of ﬁlled prescriptions is dealt with by reporting

the fraud. When

FDR2 is run on this design speciﬁ-

cation, it outputs a successful assertion of the security

requirement, as shown in Figure 6.

4 CONCLUSION

In most e-applications today, it is crucial to guaran-

tee that security requirements are successfully im-

plemented. Methods should be provided which can

check if security has been attained in a system design.

In this paper, we have presented a process based on

multi-formalism modelling and model transformation

ADDRESSING SECURITY REQUIREMENTS THROUGH MULTI-FORMALISM MODELLING AND MODEL

TRANSFORMATION

135

targeted towards veriﬁcation of domain-speciﬁc secu-

rity constraints, and have demonstrated it through the

application on an e-health case study.

At the highest level, we started from a

Se-

quence Diagram

representation of software require-

ments, used these to obtain, through automatic trans-

formation, an initial design of the system in

State-

charts

, transformed this model into a kiltera model,

then extended and modiﬁed it to consider the system

environment. Then, we further transformed the ex-

tended

kiltera model into a CSP description and, ﬁ-

nally, reﬁned it with a

CSP speciﬁcation of the se-

curity requirements. The reﬁnement checking tool

FDR2 was used to verify that security was respected

in the system implementation. A negative response

by the checker indicated that the original

Statecharts

model neglected to address all security-related re-

quirements. Note that after the above analysis (and

possible modiﬁcation of the design), the Statecharts

model can be used for code synthesis of the ﬁnal ap-

plication.

We have shown how a multi-formalism approach

can be useful for designing secure systems. The ver-

iﬁcation results gave us increased conﬁdence that se-

curity requirements were effectively addressed. Pro-

ductivity is increased as many of the steps in the pro-

cess can be automated.

We are working on a toolchain which imple-

ments the modelling and transformation steps de-

scribed above. Using the toolchain will allow us to in-

vestigate how well our approach scales to a full-blown

application using the Belgian e-ID card. This work is

done using our meta-modelling and model transfor-

mation tool AToM

(de Lara and Vangheluwe, 2002).

ACKNOWLEDGEMENTS

This work was made possible thanks to the support of

the Flemish government (IWT-Vlaanderen) through

the adapID project. Hans Vangheluwe greatfully ac-

knowledges partial support for this work through his

National Sciences and Engineering Research Council

of Canada (NSERC) Discovery Grant. We thank the

anonymous reviewers for their pertinent and construc-

tive comments.

REFERENCES

Bengtsson, J., Larsen, K. G., Larsson, F., Pettersson, P., and

Yi, W. (1995). U

PPAAL — a Tool Suite for Automatic

Veriﬁcation of Real–Time Systems. In Proc. of Work-

shop on Veriﬁcation and Control of Hybrid Systems

III, number 1066 in LNCS, pages 232–243. Springer.

de Lara, J. and Vangheluwe, H. (2002). AToM

: A tool

for multi-formalism and meta-modelling. In FASE

’02: Proceedings of the 5th International Conference

on Fundamental Approaches to Software Engineer-

ing, pages 174 – 188. Springer.

Feng, H. (2004). DCharts, A Formalism For Modeling and

Simulation Based Design of Reactive Software Sys-

tems. Master’s thesis, McGill University.

Formal Systems Europe Ltd. (2003). ProBE User Manual.

Technical report.

Gardey, G., Lime, D., Magnin, M., and Roux, O. H. (2005).

Romeo: A Tool for Analyzing Time Petri Nets. In

Etessami, K. and Rajamani, S. K., editors, Com-

puter Aided Veriﬁcation, 17th International Confer-

ence, pages 418–423. Springer.

Germeau, F. and Leduc, G. (1997). Model-based Design

and Veriﬁcation of Security Protocols using LOTOS.

Harel, D. (1987). Statecharts: A Visual Formalism for

Complex Systems. Science of Computer Program-

ming, 8(3):231–274.

Hoare, C. A. R. (1985). Communicating Sequential Pro-

cesses. Prentice-Hall.

ISO (1989). LOTOS — a formal description technique

based on the temporal ordering of observational be-

haviour. ISO IS 8807.

Lowe, G. (1996). Breaking and ﬁxing the Needham-

Schroeder public-key protocol using FDR. In Tools

and Algorithms for the Construction and Analysis of

Systems, volume 1055, pages 147–166. Springer.

Milner, R., Parrow, J., and Walker, D. (1989). A Calculus

of Mobile Processes, Parts I and II. Reports ECS-

LFCS-89-85 86, Computer Science Dept., University

of Edinburgh.

Muller, P.-A., Fleurey, F., and J

equel, J.-M. (2005).

Weaving Executability into Object-Oriented Meta-

Languages. In Briand, L. and Williams, C., editors,

MODELS’05, pages 264–278. Springer-verlag.

Mustaﬁz, S., Sun, X., Kienzle, J., and Vangheluwe, H.

(2006). Model-Driven Assessment of Use Cases for

Dependable Systems. In MoDELS’06, pages 558–

573.

Naessens, V. (2006). A Methodology for Anonymity Control

in Electronic Services using Credentials. PhD thesis,

K.U.Leuven.

Posse, E. and Vangheluwe, H. (2007). kiltera: a simula-

tion language for timed, dynamic-structure systems.

In Proceedings of the 40th Annual Simulation Sympo-

sium. SpringSim’07, pages 293 – 300.

Reed, G. M. and Roscoe, A. W. (1986). A Timed Model

for Communicating Sequential Processes. In Kott, L.,

editor, ICALP, volume 226 of Lecture Notes in Com-

puter Science, pages 314–323. Springer.

Roscoe, A. W. and Wu, Z. (2006). Verifying Statemate Stat-

echarts Using CSP and FDR. In Liu, Z. and He, J., ed-

itors, ICFEM, volume 4260 of LNCS, pages 324–341.

Springer.

ICSOFT 2007 - International Conference on Software and Data Technologies

136

Rumbaugh, J., Jacobson, I., and Booch, G., editors (1999).

The Uniﬁed Modeling Language reference manual.

Addison-Wesley Longman Ltd., Essex, UK.

Sheyner, O., Haines, J., Jha, S., Lippmann, R., and Wing,

J. M. (2002). Automated Generation and Analysis of

Attack Graphs. In SP ’02: Proceedings of the 2002

IEEE Symposium on Security and Privacy, Washing-

ton, DC, USA. IEEE Computer Society.

Sun, X. (2007). A Model-Driven Approach to Scenario-

Based Requirements Engineering. Master’s thesis,

McGill University.

Whittle, J. and Jayaraman, P. K. (2006). Generating Hier-

archical State Machines from Use Case Charts. Pro-

ceedings of the 14th IEEE International Requirements

Engineering Conference (RE’06), 0:16–25.

Whittle, J. and Schumann, J. (2000). Generating statechart

designs from scenarios. In ICSE, pages 314–323.

Yeung, W. L., Leung, K. R. P. H., Wang, J., and Dong,

W. (2005). Improvements Towards Formalizing UML

State Diagrams in CSP. In APSEC, pages 176–184.

IEEE Computer Society.

ADDRESSING SECURITY REQUIREMENTS THROUGH MULTI-FORMALISM MODELLING AND MODEL

TRANSFORMATION

137