SysML-Sec

A Model Driven Approach for Designing Safe and Secure Systems

Yves Roudier

and Ludovic Apvrille

EURECOM, 450 Routes des Chappes, 06410 Biot Sophia-Antipolis, France

Institut Mines-Telecom, Telecom ParisTech, CNRS LTCI, 450 Routes des Chappes, 06410 Biot Sophia-Antipolis, France

Keywords:

Model-Driven Engineering, Safety, Security, SysML, Embedded Systems.

Abstract:

Security ﬂaws are open doors to attack embedded systems and must be carefully assessed in order to determine

threats to safety and security. Subsequently securing a system, that is, integrating security mechanisms into

the system’s architecture can itself impact the system’s safety, for instance deadlines could be missed due to

an increase in computations and communications latencies. SysML-Sec addresses these issues with a model-

driven approach that promotes the collaboration between system designers and security experts at all design

and development stages, e.g., requirements, attacks, partitioning, design, and validation. A central point of

SysML-Sec is its partitioning stage during which safety-related and security-related functions are explored

jointly and iteratively with regards to requirements and attacks. Once partitioned, the system is designed in

terms of system’s functions and security mechanisms, and formally veriﬁed from both the safety and the se-

curity perspectives. Our paper illustrates the whole methodology with the evaluation of a security mechanism

added to an existing automotive system.

1 INTRODUCTION

Embedded systems and Cyber-Physical Systems pro-

gressively impact our daily lives, information sys-

tems, and industrial systems. Because these systems

are by essence connected, they are strongly exposed

to attacks. To cite only a few examples of past attacks

on similar connected systems, we can mention the

Microsoft XBox (Huang, 2002), ADSL routers (As-

solini, 2012), mobile&smart phones (Maslennikov,

2010) (Esser, 2011) (Apvrille and Strazzere, 2012),

avionic systems (Teso, 2013) or automotive systems

(Teso, 2013), and even home appliances such as re-

frigerators as demonstrated recently by a botnet in-

fecting LG fridges (Proofpoint, 2014). Such attacks

also target industrial systems whose sensors are more

and more commonly connected with vulnerable in-

formation systems, as demonstrated by the Stuxnet,

Flame, or Duqu (Maynor, 2006) attacks. The depend-

ability of such systems can of course be targeted by

such attacks with very various objectives, e.g., terror-

ist acts and ransomware.

The complexity of such systems in terms of code

size, distribution, and heterogeneity among others

is a major factor for the risks they face. We con-

tend that taking into account security from the very

ﬁrst development phases, and including both software

and hardware components, could lower the risk those

systems face, both in terms of security and safety.

We also think that safety and security should be de-

signed and validated all together, that is, from the

same models, and that the impact of the security

mechanisms execution over the safety-related func-

tions should be clearly established. Our solution re-

lies on a model-driven environment named SysML-

Sec. SysML-Sec covers all design and development

phases, including requirement capture, attack equa-

tions, functional model, hardware/software partition-

ing, designs of software components, and validation

of both safety and security properties. The valida-

tion itself shall be performed at partitioning and de-

sign stages. In the ﬁrst case, the objective is to assess

the effectiveness of the selected hardware/software ar-

chitecture to support both safety and security require-

ments, and resist to identiﬁed attacks. In the second

case, the validation should closely investigate whether

the design choices respect the safety and security re-

quirements.

SysML-Sec has already been presented

in (Apvrille and Roudier, 2013). This paper fo-

cuses on a new aspect, that is, how SysML-Sec

can also be used to evaluate the impact of security-

655

Roudier Y. and Apvrille L..

SysML-Sec - A Model Driven Approach for Designing Safe and Secure Systems.

DOI: 10.5220/0005402006550664

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (SPIE-2015), pages 655-664

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

oriented design onto systems with strong critical

aspects, e.g., critical embedded systems, or systems

whose attack may lead to strong economical loss,

e.g., new interconnected information systems such as

cloud services.

The paper is organized as follows. Section 2 fo-

cuses on the impact of attacks on safety-critical sys-

tems. Section 3 discusses different modeling ap-

proaches to efﬁciently take into account both the sys-

tem architecture and requirements in the develop-

ment process of a safe ad secure system. Then, we

present the methodology and the validation process

of the SysML-Sec framework in Sections 4 and 5,

respectively, with a strong emphasis on the relation

between safety and security properties and features.

An automative-based case study is given in section 6.

Section 7 concludes the paper.

2 IMPACT OF ATTACKS

Performing attacks relies on the exploitation of ei-

ther low-level vulnerabilities (e.g., buffer overﬂows)

or design weaknesses. Low-level vulnerabilities can

often be handled with good programming practices,

or by using efﬁcient security tests, e.g., different kinds

of fuzzing. On the contrary, design errors generally

come from a bad requirement and attack capture, or

from a bad partitioning of hardware / software compo-

nents, including security mechanisms that those com-

ponents implement. Unfortunately, those errors are

more difﬁcult to correct once the system has been re-

leased. Moreover, security tools commonly used by

security experts, e.g. ProVerif (Blanchet, 2009) and

AVISPA (Armando et al., 2005), not take into account

the hardware/software partitioning.

Classical information systems are still widely tar-

geted by attackers. Nonetheless, the particularities of

information systems comprising communicating em-

bedded equipments make them even more “interest-

ing” targets for attackers. We can mention three dan-

gers related to those attacks:

• If an attack relies on a hardware vulnerability,

it can be difﬁcult, or even impossible, to cor-

rect (i.e., patch) the system via a software up-

date, in particular if functions have been imple-

mented mostly with hardware components, e.g.,

with hardware accelerators or network ﬁltering

techniques. In the case of usual information sys-

tems, a “simple” software update and a system re-

boot can generally solve the problem.

• Updating the software of embedded system is

much more complex than updating the software

of, e.g., PCs. For instance, to patch the software

of a vehicle, it is necessary to send a letter to the

owner, that will later bring the car to a mainte-

nance garage. Users of embedded systems are

also less used to update their systems, as recently

demonstrated with IP cameras. On the contrary,

updating a PC or a server has become a common

practice (the famous “Tuesday patch”), and can be

handled remotely in an automated way.

• The impact of attacks on safety critical systems

can be much higher than on other kinds of sys-

tems. Moreover, the growing interconnection

between information systems and smart objects

gives more chances to attackers to enter illegally

those systems, once he/she has managed to com-

promise one of the interconnected element. This

is the case, e.g., for botnets (DoS attacks, spams),

as demonstrated recently by the LG fridge at-

tack (Proofpoint, 2014), or for performing cryp-

tographic attacks.

3 THE FUNDAMENTAL ROLE OF

SYSTEM ARCHITECTURE TO

DEVELOP A SECURE SYSTEM

From our own experience, we think that main system

architectural elements must be ﬁrst modeled in order

to better capture and analyze potential attacks on the

system.

3.1 Software/Hardware Partitioning

Software-centric systems are commonly designed

with a V-cycle comprising the following stages: re-

quirements elicitation, software analysis, software de-

sign, implementation. Each of these stages are then

followed with a corresponding veriﬁcation state, that

commonly relies on testing, simulation and formal

veriﬁcation techniques. In the case of embedded sys-

tems, that approach is obviously applicable only once

functions to be software implemented have been spec-

iﬁed. In other words, the V-cycle can start only once

the software and hardware partitioning has been per-

formed.

System partitioning (a.k.a. Design Space Explo-

ration) is a process to analyze various functionally

equivalent implementation of systems speciﬁcation.

It usually relies on the Y-chart approach (Balarin

et al., 2003) depicted in Figure 1:

1. Applications are ﬁrst described as abstract com-

municating tasks: tasks represent functions inde-

pendently from their implementation form.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

656

2. Targeted architectures are independently de-

scribed from tasks. They are usually described

with a set of execution nodes (e.g., CPU), com-

munication nodes (e.g., buses), and storage nodes

(e.g., memories).

3. A mapping model deﬁnes how application tasks

and abstract communications are assigned to com-

putation and communication / storage devices, re-

spectively. For example, a task mapped on a hard-

ware accelerator is a hardware-implemented func-

tion whereas a task mapped over a CPU is a soft-

ware implemented function.

Figure 1: The Y-chart methodology.

Ideally, the result of the Y-chart approach shall be

an optimal hardware / software architecture with re-

gards to criteria at stake for that particular system

(e.g., cost, area, power, performance, ﬂexibility, relia-

bility, etc.). This process can be manually performed

by experiemnted engineers, or can be automated by

speciﬁc toolkits, e.g. (Balarin et al., 2003). This

partitioning step is of utmost importance. Indeed, if

critical high-level design choices are invalidated af-

terwards because of late discovery of issues (perfor-

mance, power, etc.), then it may induce prohibitive

re-engineering costs and late market availability.

3.2 Dimensioning

In some highly critical systems, models for design

space exploration are not intended for computing

and analyzing Worst Case Execution Time. On the

contrary, dimensioning-based techniques based on

network calculus (Leboudec and Thiran, 2001) are

adapted to compute worst case execution scenarios.

These techniques are typically used for deﬁning the

architecture of aeronautics systems. Dimensioning

models are part of our overall toolkit (Apvrille et al.,

2010), even if they are not (yet) used in SysML-Sec.

3.3 Model-Driven Engineering

Model-Driven Engineering is probably the main con-

tribution of the last decade in modeling approaches.

MDE targets system analysis, design, simulation,

code generation, and documentation. MDE generally

relies on the UML language, and on meta-modeling

techniques in order to deﬁne Domain-Speciﬁc Lan-

guages. OMG’s Model Driven Architecture for

instance speciﬁcally targets two abstraction levels,

namely the Platform-Independent Model (PIM) and

Platform Speciﬁc Model (PSM): embedded systems

are thus clearly targeted by MDE. Proﬁles have also

been deﬁned by the OMG to more speciﬁcally address

embedded systems: SPT (OMG, 2005) and MARTE

(Vidal et al., 2009), but none of them addresses re-

quirements modeling. Conversely, the SysML OMG

proﬁle (OMG, 2012) clearly takes into account re-

quirements with explicit modeling capabilities and di-

agrams, but ignores some problematics inherent to

embedded systems, e.g., the partitioning issue.

Other methodologies, like for example Extreme

programming (XP) (Beck and Andres, 2004) or Ag-

ile Software Development (Waters, 2012) have also

been proposed to develop software-oriented systems.

However, their software focus means that they totally

ignore the partitioning issue. They also make trace-

ability and reﬁnement extremely hard to achieve, also

because requirements are mostly separate from the

design process.

4 SPECIFYING THE SECURITY

NEEDS OF A SYSTEM

Security and privacy are commonly after-thought in

new connected and distributed information systems

(e.g., cloud services) and embedded system, in con-

trary to safety. Thus, security needs appear after the

system has already been released, generally when se-

curity vulnerabilities are discovered. Nonetheless,

those vulnerabilities have a critical aspect whenever

the can be exploited to impact economical or safety-

related components.

4.1 Security Goals and Threats

Many research works have already addressed the

modeling and analysis of security requirements and

threats, mostly in the scope of information systems.

Nhlabatsi et al. (Nhlabatsi et al., 2010) classify them

in four categories: goal-oriented approaches, model-

driven approaches, process-oriented approaches and

last problem-oriented approaches. The two ﬁrst are

the two closest to SysML-Sec. KAOS is a well-known

goal-oriented approach (Van Lamsweerde, 2007) that

relies on the explicit model of security goals and anti-

goals. TwinPeaks (Nuseibeh, 2001) also follows a

goal-oriented approach with an agile iterative process

between goals and system architecture. UMLSec is

SysML-Sec-AModelDrivenApproachforDesigningSafeandSecureSystems

657

a model-oriented approach. It includes tools for the

speciﬁcation and veriﬁcation of distributed systems

with security mechanisms, including cryptographic

protocols. Model-oriented approaches are considered

as more adapted to the design of security mechanisms,

but goal-oriented approaches offers a better way to

analyze security requirements during the ﬁrst design

iterations.

4.2 SysML-Sec: A SysML-based

Model-oriented Approach

The ﬁrst objective of SysML-Sec (Apvrille and

Roudier, 2013) is to facilitate the collaboration and

communication between experts in system design

and experts in system security and privacy. More-

over, SysML-Sec intends to cover all development

methodological stages of these system. SysML-Sec

combines a goal-oriented approach for capturing re-

quirements, and a model-oriented approach for sys-

tem architecture and threats. In contrary to Twin-

Peaks (Nuseibeh, 2001), SysML-Sec follows the Y-

chart scheme (Balarin et al., 2003) and its underly-

ing allocation techniques. The latters facilitates the

identiﬁcation of resources to be protected and the link

between resources, safety requirements, and security

requirements.

4.3 Methodology

The SysML-Sec methodology is ﬁrst based on an Y-

Chart-based system analysis, and then on a software

design phase following the well-known V-cycle. This

methodology is given at Figure 2.

The analysis stage intends to identify and ana-

lyze both requirements and attacks altogether with

the identiﬁcation of main functions (“application”),

candidate hardware architectures, and the mapping of

main functions over execution nodes (mapping). Dur-

ing the functional stage, simulations and (formal) ver-

iﬁcations are used in order to identify safety-related

issues, e.g., deadlock situations, non -reachability of

error states, etc. Functional models are untimed,

which means that no performance study can be lead.

Yet, the mapping of functions over execution nodes

gives to the former a logical and physical execution

time. Thus, post-mapping simulations and formal

veriﬁcations are intended to demonstrate the system

performance on the selected hardware architecture,

including the study of latencies, the load of proces-

sor and buses, and communication time. Obviously,

the results are due to the logical parts of the appli-

cation, to the way the underlying hardware behaves,

but also to the security mechanisms. For example,

a given security protocol may impact a bus load, a

cryptographic function may impact a processor load:

Both can consequently increase the overall system la-

tency. The mapping scheme, for example, mapping

a cryptographic function over a hardware accelera-

tor, or on a general-purpose processor, also impacts

system latencies. The performance study thus really

intends to study altogether both safety and security

functions mapped in different conditions. The result

of this study is a hardware/software architecture that

complies with both safety and security requirements,

and that can resist to attacks, and according to a given

risk level.

The goal of the design stage is to design the soft-

ware components, that is, functions mapped onto pro-

cessors at previous stage. During the design, soft-

ware components are progressively reﬁned until the

point where executable code generation is feasible.

This reﬁnement also includes security-related func-

tions, e.g., security protocols. During the ﬁrst reﬁne-

ments, simulation can be used to debug the models.

When the model is of reasonable size, formal veri-

ﬁcation can also be used to assess safety properties

(e.g., the reachability of a given state, or its liveness),

and security properties (e.g., the conﬁdentiality of a

given block attribute, the authenticity of a message).

When the model is too large to be veriﬁed, model-

to-code transformations are used to perform security

and safety tests. This paper do not address the design

stage, but it is described in (Apvrille and Roudier,

2013).

y-chart

Attacks

Requirements Application Architecture

Application mapped on architecture

System design

mapping

Simulation,

Formal verification

Testing

Figure 2: The SysML-Sec methodology.

4.4 Toolkit

The free and open-source TTool software supports

all SysML-Sec methodological stages, including the

models capture and their simulations and veriﬁca-

tions. In fact, TTool is a multi-proﬁle toolkit which

main strength is to offer a press-button approach for

performing simulation and formal proofs from mod-

els. Proofs can be performed automatically for both

safety and security properties. For the partitioning

stage, TTool relies on the DIPLODOCUS UML pro-

ﬁle (Apvrille et al., 2006), even if security aspects pre-

sented in this paper are speciﬁc to SysML-Sec. Re-

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

658

quirements, attacks, software design and all captured

and analyzed with AVATAR (Apvrille and De Saqui-

Sannes, 2013) which covers the V development cy-

cle. Formal veriﬁcations and simulations can be per-

formed either with TTool’s integrated model checkers

and simulators, or with external formal veriﬁcation

toolkits, e.g. UPPAAL (Bengtsson and Yi., 2004),

CADP (Garavel et al., 2007) and ProVerif (Blanchet,

2009).

5 SAFETY AND SECURITY

ORIENTED VALIDATIONS

Model-oriented approaches do favor the early vali-

dation of models. SysML-Sec supports such valida-

tion, either from partitioning models, or from design

models. Validations are supported by TTool with a

press-button approach: models can be transformed

by TTool into a formal speciﬁcations. TTool has its

own model-checker, but it can also relies on exter-

nal provers. Once the validation results have been

obtained (property is satisﬁed, property is not satis-

ﬁed, property cannot be proved), the model is back-

annotated with the results. Formal validation is more

likely to be used to prove speciﬁc and precise safety

and security property, e.g., that a given data is conﬁ-

dential. Simulation is more likely to be used when-

ever the impact of a security mechanism over safety

properties (e.g., latency-related properties) must be

studied. This impact is mostly studied at partitioning

stage.

5.1 Safety Properties

Such validations concern the following models: func-

tional models, partitioning models, and design mod-

els. Properties can be proved with the use of sim-

ulation techniques (Apvrille and De Saqui Sannes,

2011), of formal veriﬁcation techniques (Apvrille and

De Saqui-Sannes, 2013) (Bengtsson and Yi., 2004),

or by generating an executable code (only from re-

ﬁned design models) and performing tests on that

code (Apvrille and Becoulet, 2012). From design di-

agrams, safety proofs take into account both safety

and security mechanisms, because the latter impact

the behaviour of software components, e.g., taking a

given execution path.

The system architecture and behaviour are com-

monly modeled with graphical languages. On the

contrary, languages used for expressing properties

still mostly rely on textual languages, e.g. LTL/CTL,

or languages derived from those ones. Yet, it is pos-

sible in SysML-Sec to model all logical and timing

properties with SysML parametric diagrams (Knor-

reck et al., 2011).

5.2 Security Properties

In the design stage, formal proofs of conﬁdentiality

and authenticity properties can be performed. If pos-

sible, security requirements must ﬁrst be reﬁned into

conﬁdentiality and authenticity properties modeled as

pragmas in SysML-Sec block diagrams. TTool can

then transformed the design diagrams into a security-

oriented formal speciﬁcation in pi-calculus (Pedroza,

2013). This speciﬁcation can be given as input to

ProVerif, along with the conﬁdentiality and authen-

ticity properties to be proved (Blanchet, 2009).

5.3 Safety and Security, Safety vs.

Security

It is not a common practice to assess the relation-

ship between safety and security at partitioning stage.

Yet, we believe that this should be addressed as

soon as possible in the development cycle, as sug-

gested by the SysML-Sec methodology. Eames and

Moffet (D. P. Eames and Moffett, 1999), and more

recently Pi

etre-Cambac

es (Pietre-Cambacedes and

Bouissou, 2013) and Raspotnig (Raspotnig and Op-

dahl, 2013) have proposed ways to handle the links

between safety and security properties. More pre-

cisely, (Pietre-Cambacedes and Bouissou, 2013) and

(Raspotnig and Opdahl, 2013) aim at explicitly de-

scribing conﬂicts between such requirements, and

also to provide “reinforcements”, that is, require-

ments with different scope that drives the architecture

models in the same direction.

As we show in the next section, SysML-Sec

makes it possible to assess the compatibility of secu-

rity mechanisms with regards to safety properties in

partitioning stage, relying on validation techniques.

Similar studies can be lead during the design stage.

During the partitioning stage, mechanisms are

evaluated according to the system latency and the us-

age of the platform, e.g., the necessary computation

power, the load of buses, and the respect of real time

deadlines. Partitioning models are typically validated

by generating a known average trafﬁc in the system,

and then introducing security mechanisms so as to

evaluate the impact of the latter on the former. The

reﬁnement of SysML-Sec models leads to introduce

ﬁne-grained cryptographic functions where properties

to be proved are more likely to be the reachability of

the given state of a security protocol. Thus, at design

stage, we also rely on provers so as to assess the con-

sistency of requirements and the coverage of attacks.

SysML-Sec-AModelDrivenApproachforDesigningSafeandSecureSystems

659

Figure 3: EVITA automotive reference architecture.

6 EXAMPLE: SAFETY AND

SECURITY ANALYSIS OF A

COMMUNICATING VEHICLE

This section illustrates the use of SysML-Sec for the

identiﬁcation of requirements and attacks and for the

deﬁnition of safe and secure system architecture. The

automotive system that serves as case study is taken

from the European FP7 EVITA project (Kelling et al.,

2009). EVITA has deﬁned the ﬁrst generic secu-

rity architecture for automotive communicating sys-

tems. This architecture contains safety critical ECUs

(Electronic Control Units) interconnected with CAN

or Flexray buses. Automotive systems are likely to be

attacked either for economical reasons (activating op-

tional features for free, stealing a car), either for crim-

inal purpose. The interconnection of automotive sys-

tems to information systems (roads signs, tolls, etc.)

and Internet will offer new ways to conduct attacks

onto those systems.

A reference automotive architecture is given in

Figure 3. It is built upon several domains (Power-

train, chassis & Safety, Communication Unit, Head

Unit, etc.). Domains may contain several sub do-

mains, each of them containing several buses and pro-

cessors. A main CAN/FlexRay bus interconnects all

ECUs bridges together. At last, the communication

and head units have external interfaces (Bluetooth,

LTE, etc.).

We now apply the SysML-Sec methodology with

the addition of a security mechanism to the reference

architecture. This mechanism is the distribution of

cryptographic session keys between domains and sub-

domains. An ECU1 asks the “key master” to generate

a session key so as to communicate in a secure way

with other domains ECUN of this session.

6.1 Security Requirements

Security requirements are captured within SysML

requirements diagrams. Security requirements are

stereotyped << SecurityRequirement >> and con-

tains an extra kind ﬁeld (conﬁdentiality, access con-

trol, integrity, freshness, etc.). Usual SysML rela-

tions between requirements (containment, derive) can

be used, in particular to trace requirements through-

out the different abstraction levels. Figure 4 presents

an excerpt of security requirements dealing with the

prevention of the injection of wrong commands into

the system. The main requirement is reﬁned into

authenticity, integrity and freshness requirements for

all communication between ECUs involved in system

functions.

6.2 Threats and Attacks

Attacks are commonly captured with attack

trees (Schneier, 1999). Such trees allow an efﬁ-

cient decomposition of attacks into sub-attacks. Yet,

they are not adapted to the description of complex

scenarios. Yet, attacks currently lead on embedded

systems are generally composed of complex sce-

narios, sometimes involving complex logical and

timing relations, e.g., the Zeus/Zitmo attack exploits

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

660

<<Security Requirement>>

PreventSendingFakeCommand

ID=FSR-1

Kind="Functional"

Risk="High"

Targeted attacks=""

<<Security Requirement>>

IntegrityOfMessageAttributesAlongFunctionalPath

ID=FSR-1.1.3

Text=""

Kind="Integrity"

Risk="High"

Targeted attacks=""

<<Security Requirement>>

MessageFreshnessAlongFunctionalPath

ID=FSR-1.1.2

Text=""

Kind="Freshness"

Risk="High"

Targeted attacks=""

<<Security Requirement>>

PreventManInTheMiddleAttack

ID=FSR-1.1

Text="Internal attack"

Kind="Integrity"

Risk="High"

Targeted attacks=""

<<Security Requirement>>

PreventReplacementOfChipsOnLocalBusses

ID=FSR-1.2

Text=""

Kind="Controlled access (authorization)"

Risk="High"

Targeted attacks=""

<<Security Requirement>>

AuthenticationOfFunctionalPath

ID=FSR-1.1.1

Text="This includes the authentication of functions,

and of the functions on the ECUs"

Kind="Data origin authenticity"

Risk="High"

Targeted attacks=""

Figure 4: Excerpt of security requirements.

a time-limited authentication token.

We thus decided to introduce a richer attack model

based on SysML parametric diagram: attack equa-

tions. These equations are meant to offer a set of con-

straints linking together sub-attacks, in order to build

more complex attacks.

Attacks are captured with “properties” of SysML

blocks. Since Blocks represent resources of the

system, a visual emphasis on architectural elements

to protect is obtained. Constraints are used to re-

late attacks together: << OR >>, << AND >>,

<< SEQU ENCE >>, << BEFORE >>, <<

AFT ER >>. Each constraint has a denotational cor-

respondence, e.g. the equation of a << OR >> be-

tween two attacks a1 and 2 is a = a

∨ a

, with a being

the resulting attack. Attacks can also be linked to re-

quirements, and vice-versa.

Figure 5 depicts a simpliﬁed attack of our case

study. A main resource AutomotiveECUsandBuses

is the target of an attacker wishing to steal the car

(Steal car root attack). To successfully perform that

attack, the attacker ﬁrst need to connect on the system

bus so as to be able to open the doors and then start

the engine. Opening the doors is actually optional

since the attacker could decide to break the windows,

and thus, doors-related attacks are optional (See the

parenthesis around the (2) and (3) in the sequence

constraint). To access to the system bus, the attacker

can either connect with a remote interface (Bluetooth,

Internet), either through a debug interface (OBD-II

plug). For both solutions, he then needs to bypass

the automotive system ﬁrewall.

6.3 Hardware/Software Partitioning

A SysML block instance diagram is used to describe

functions, and their relations. Data and event ﬂows

between functions can be described with ports and

links. Semantically speaking, data ﬂow do not model

values of those data, but only the quantity of ex-

changed data: this grandly simpliﬁes proofs and sim-

ulations at that level of abstraction (memo: validation

takes into account both software and hardware com-

ponents). Also, in the scope of complex systems, we

have demonstrated that this does not impact partition-

ing decisions (Jaber, 2011).

The architectural and mapping models rely on a

UML deployment diagram, but the allocation mech-

anism of SysML or MARTE could be used for that

purpose. the mapping of functional blocks, and their

communications, is based on artifacts added to de-

ployment nodes, that latter being assets to be pro-

tected. They are likely to be also depicted in the attack

diagrams.

In order to evaluate the impact of security mech-

anisms, two simulations are performed onto two dif-

ferent partitioning. A ﬁrst simulation is performed on

the automotive system with no security mechanisms

The purpose of that simulation is to evaluate the CAN

bus load, because it is in charge of conveying urgent

and non-urgent messages between domains. The av-

erage load with no security is 40%.

A second simulation evaluates how the perfor-

mance of the previous system is impacted by the key

distribution protocol. For that purpose, a subset of the

automotive system is modeled: cryptographic hard-

SysML-Sec-AModelDrivenApproachforDesigningSafeandSecureSystems

661

<<block>>

AutomotiveECUsAndBuses

<<attack>>

Plug_on_OBD

<<OR>>

<<attack>>

Bypass_internal_firewall

<<AND>>

<<attack>>

Listen_to_OpenDoor_messages

<<attack>>

Connect_to_System_Bus

<<attack>>

Inject_or_Replay_OpenDoor_Message

<<SEQUENCE>>

<<block>>

CommunicationUnit

<<attack>>

CompromisedCommunicationUnitThroughInternet

<<block>>

HeadUnit

<<block>>

Bluetooth

<<attack>>

Connect_to_Bluetooth

<<root attack>>

Steal_Car

(3)

(2)

<<attack>>

Start_engine

Figure 5: Describing an attack with a SysML parametric diagram.

<<CPURRPB>>

HSM_ECUN

KDP Perf Design_Sec::HSM_ECUN

<<CPURRPB>>

CPU_ECUN

KDP Perf Design_Sec::CTP_ECUN

KDP Perf Design_Sec::KeyManager_ECUN

<<BUS-RR>>

InternalBusECUN

47%

<<MEMORY>>

MemoryECUN

<<BRIDGE>>

BridgeECUN

<<CPURRPB>>

HSM_KM

KDP Perf Design_Sec::HSM_KM

<<CPURRPB>>

CPU_KM

KDP Perf Design_Sec::KM

KDP Perf Design_Sec::CTP_KM

47%

<<BUS-RR>>

InternalBusKM

95%

<<MEMORY>>

MemoryKM

<<BRIDGE>>

BridgeKM

<<CPURRPB>>

HSM_ECU1

KDP Perf Design_Sec::HSM_ECU1

<<CPURRPB>>

CPU_ECU1

KDP Perf Design_Sec::DistributionManager_ECU1

KDP Perf Design_Sec::CTP_ECU1

KDP Perf Design_Sec::App_ECU1

47%

<<BUS-RR>>

InternalBusECU1

47%

<<MEMORY>>

MemoryECU1

<<BRIDGE>>

BridgeECU1

<<BUS-CAN>>

MainCAN

KDP Perf Design_NoSec::highPrioLoad

channel

KDP Perf Design_NoSec::lowPrioLoad

channel

99%

<<CPURRPB>>

CPU_Source

KDP Perf Design_Sec::LoadSource

<<CPURRPB>>

CPU_Sink

KDP Perf Design_Sec::LoadSink

Figure 6: Simulation with the key distribution mechanism.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

662

ware accelerators (HSM - Hardware Security Mod-

ule), the ECU asking for a session key (ECU1), the

Key Master (KM), and the ECUs that will participate

to the session and thus need the session key. The sim-

ulation shows a much higher load on the main CAN

bus during a key distribution, and a much higher la-

tency was observed for all classes of trafﬁc not re-

lated to the key distribution (Schweppe et al., 2011):

this security mechanism do impact the safety of the

system. To solve that issue, one solution we exper-

imented with was to split in several successive mes-

sages the authentication information.

7 CONCLUSION AND FUTURE

WORK

Many attacks are now conducted on embedded sys-

tems and cyber-physical systems. A short time-to-

market combined with strong safety and security re-

quirements encourages the introduction of new devel-

opment methodologies for those systems.

SysML-Sec integrates in the same development

cycle semi-formal speciﬁcations of both safety and

security features and properties. Simulations and for-

mal proofs on models can be easily conducted with

TTool, so as to assess architectural choices and design

choices, in terms of performance, safety properties,

and security properties. Moreover, SysML is based

on a well known and recognize language for system

engineering, and is totally supported by TTool.

SysML-Sec has been deﬁned and used in the

scope of the EVITA project, that is, to secure an

automotive embedded system. The case study pre-

sented in this paper is extracted from this project, and

demonstrates the interest and choices of SysML-Sec.

One important objective of our work is now to add

reasoning capabilities to SysML-Sec. More precisely,

our goal is to verify that critical functionalities are

not inhibited by the introduction of security mecha-

nisms, e.g. message ciphering or network ﬁltering.

This could be done with logic inference rules.

REFERENCES

Apvrille, A. and Strazzere, T. (2012). Reducing the window

of opportunity for android malware. gotta catch’em

all. Journal in Computer Virology, 8(1-2):61–71.

Apvrille, L. and Becoulet, A. (2012). Prototyping an Em-

bedded Automotive System from its UML/SysML

Models. In ERTSS’2012, Toulouse, France.

Apvrille, L. and De Saqui Sannes, P. (2011).

AVATAR/TTool : un environnement en mode

libre pour SysML temps r

eel. G

enie Logiciel,

(98):22–26.

Apvrille, L. and De Saqui-Sannes, P. (2013). Requirements

analysis. Embedded Systems: Analysis and Modeling

with SysML, UML and AADL.

Apvrille, L., Mifdaoui, A., and De Saqui-Sannes, P. (2010).

Real-time distributed systems dimensioning and vali-

dation: The turtle method. Studia Informatica Univer-

salis, 8(3):47–69.

Apvrille, L., Muhammad, W., Ameur-Boulifa, R., Coudert,

S., and Pacalet, R. (2006). A UML-Based Environ-

ment for System Design Space Exploration. In Elec-

tronics, Circuits and Systems, 2006. ICECS ’06. 13th

IEEE International Conference on, pages 1272 –1275.

Apvrille, L. and Roudier, Y. (2013). SysML-Sec: A SysML

environment for the design and development of secure

embedded systems. In APCOSEC 2013, Yokohama,

Japan.

Armando, A., Basin, D., Boichut, Y., Chevalier, Y.,

Compagna, L., Cuellar, J., Drielsma, P., Hem, P.,

Kouchnarenko, O., Mantovani, J., Mdersheim, S.,

Oheimb, D., Rusinowitch, M., Santiago, J., Turuani,

M., Vigan, L., and Vigneron, L. (2005). The avispa

tool for the automated validation of internet secu-

rity protocols and applications. In Etessami, K. and

Rajamani, S., editors, Computer Aided Veriﬁcation,

volume 3576 of Lecture Notes in Computer Science,

pages 281–285. Springer Berlin Heidelberg.

Assolini, F. (2012). The Tale of One Thousand and One

DSL Modems, kaspersky lab.

Balarin, F., Watanabe, Y., Hsieh, H., Lavagno, L.,

Passerone, C., and Sangiovanni-Vincentelli, A.

(2003). Metropolis: An Integrated Electronic System

Design Environment. Computer, 36(4):45–52.

Beck, K. and Andres, C. (2004). Extreme Programming

Explained: Embrace Change (2nd Edition). Addison-

Wesley Professional.

Bengtsson, J. and Yi., W. (2004). Timed automata: Seman-

tics, algorithms and tools. In Lecture Notes on Con-

currency and Petri Nets, pages 87–124. W. Reisig and

G. Rozenberg (eds.), LNCS 3098, Springer-Verlag.

Blanchet, B. (2009). Automatic Veriﬁcation of Correspon-

dences for Security Protocols. Journal of Computer

Security, 17(4):363–434.

D. P. Eames, D. P. and Moffett, J. (1999). The integration

of safety and security requirements. In SAFECOMP,

pages 468–480.

Esser, S. (2011). Exploiting the iOS Kernel. In BlackHat

2011.

Garavel, H., Lang, F., Mateescu, R., and Serwe, W. (2007).

CADP 2006: A Toolbox for the Construction and

Analysis of Distributed Processes. In Proceedings of

the 19th International Conference on Computer Aided

Veriﬁcation CAV 2007.

Huang, A. (2002). Keeping Secrets in Hardware: the Mi-

crosoft XBox Case Study, AI Memo 2002-008, Mas-

sachusetts Institute of Technology, Artiﬁcial Intelli-

gence Laboratory. Technical report.

Jaber, C. (2011). High-Level SoC Modeling and

Performance Estimation Applied to a Multi-

SysML-Sec-AModelDrivenApproachforDesigningSafeandSecureSystems

663

CoreImplementation of LTE EnodeB Physical

Layer. PhD thesis, Telecom ParisTech.

Kelling, E., Friedewald, M., Leimbach, T., Menzel, M.,

ager, P., Seudi

e, H., and Weyl, B. (2009). Speciﬁca-

tion and Evaluation of e-Security Relevant Use cases.

Technical Report Deliverable D2.1, EVITA Project.

Knorreck, D., Apvrille, L., and De Saqui-Sannes, P. (2011).

TEPE: A SysML Language for Time-Constrained

Property Modeling and Formal Veriﬁcation. ACM

SIGSOFT Software Engineering Notes, 36(1):1–8.

Leboudec, J. and Thiran, P. (2001). Network Calculus.

Springer Verlag LNCS volume 2050.

Maslennikov, D. (2010). Russian cybercriminals on the

move: proﬁting from mobile malware. In The 20th

Virus Bulletin Internation Conference, pages 84–89,

Vancouver, Canada.

Maynor, D. (2006). Scada security and terrorism:

We’re not crying wolf! In Invited presentation

at BlackHat BH 2006. Presentation available at:

https://www.blackhat.com/presentations/bh-federal-

06/BH-Fed-06-Maynor-Graham-up.pdf, USA.

Nhlabatsi, A., Nuseibeh, B., and Yu, Y. (2010). Security Re-

quirements Engineering for Evolving Software Sys-

tems: a survey. Technical Report 1, The Open Univer-

sity.

Nuseibeh, B. (2001). Weaving Together Requirements and

Architectures. IEEE Computer, 34(3):115–117.

OMG (2005). OMG Proﬁle for Scheduling, Performance

and Time. In http://www.omg.org/spec/SPTP/.

OMG (2012). OMG Systems Modeling Language. In

http://www.sysml.org/specs/.

Pedroza, G. (2013). Assisting the design of secured appli-

cations for mobile vehicles. In Ph.D. of Ecole doctor-

ale informatique, t

ecommunications et

electronique

of Paris.

Pietre-Cambacedes, L. and Bouissou, M. (2013). Cross-

fertilization between safety and security engineering.

Rel. Eng. & Sys. Safety, 110:110–126.

Proofpoint (2014). Your Fridge is Full of

SPAM: Proof of An IoT-driven Attack. In

http://www.proofpoint.com/threatinsight/posts/your-

fridge-is-full-of-spam-proof-of-a-Iot-driven-

attack.php.

Raspotnig, C. and Opdahl, A. L. (2013). Comparing

risk identiﬁcation techniques for safety and secu-

rity requirements. Journal of Systems and Software,

86(4):1124–1151.

Schneier, B. (1999). Attack Trees: Modeling Security

Threats.

Schweppe, H., Roudier, Y., Weyl, B., Apvrille, L., and

Scheuermann, D. (2011). C2X communication: Se-

curing the last meter. In The 4th IEEE International

Symposium on Wireless Vehicular Communications:

WIVEC2011, San Francisco, USA.

Teso, H. (2013). Aircraft Hacking. In HITB Security Con-

ference, Amsterdam, The Netherlands.

Van Lamsweerde, A. (2007). Engineering Requirements

for System Reliability and Security. Software System

Reliability and Security, 9:196–238.

Vidal, J., de Lamotte, F., Gogniat, G., Soulard, P., and

Diguet, J.-P. (2009). A Co-Design Approach for Em-

bedded System Modeling and Code Generation with

UML and MARTE. In Design, Automation and Test in

Europe Conference and Exhibition, 2009. DATE’09,

pages 226–231.

Waters, K. (2012). All About Agile: Agile Management

Made Easy! CreateSpace Independent Publishing

Platform.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

664