Evolving Attacker Perspectives for Secure Embedded System Design

Letitia W. Li

1,2

, Florian Lugou

and Ludovic Apvrille

LTCI, T

ecom ParisTech, Universit

e Paris-Saclay, 75013, Paris, France

Institut VEDECOM, 77 rue des Chantiers, Versailles, France

Keywords:

Model-Driven Engineering, Security, Formal Veriﬁcation.

Abstract:

In our increasingly connected world, security is a growing concern for embedded systems. A systematic design

and veriﬁcation methodology could help detect vulnerabilities before mass production. While Attack Trees

help a designer consider the attacks a system will face during a preliminary analysis phase, they can be further

integrated into the design phases. We demonstrate that explicitly modeling attacker actions within a system

model helps us to evaluate its impact and possible countermeasures. This paper describes how we evolved the

SysML-Sec Methodology with “Attacker Scenarios” for the improved design of secure embedded systems.

1 INTRODUCTION

The advent of connected and soon autonomous vehi-

cles is projected to ease trafﬁc congestion, improve

safety, and free us from tedious daily commutes.

However, even with the limited connectivity of today,

connected cars have already been compromised in

various hacks (Miller and Valasek, 2015; Constantin,

2016).

The methodology of our lab, SysML-Sec

(Apvrille and Roudier, 2015), describes a design

process for safe and secure embedded systems. How-

ever, during our study of the security of connected

vehicles, we found that we lacked the ability to

precisely model certain published attacks, and thus to

consequently evaluate countermeasures against them.

While attack steps can be modeled in Attack Trees,

the description of each attack is usually limited to a

few words, thus limiting their usage to documentation

and not to formal evaluation.

Therefore, this paper introduces a new concept

called “Attacker Scenarios”, which precisely model

attacker actions within a system design, therefore us-

ing the same operators as for system design. Thus,

attacker scenarios are intended to interact with (and

possibly control) system models with communica-

tions via signals. The paper explains the modeling

capacities of attack scenarios — e.g., how to model

message injection in communication channels — as

well as how they integrate into our methodology. In

section 2, we discuss the high-level approach of us-

ing attack scenarios in system design, which we elab-

orate in section 3 to be speciﬁc for embedded sys-

tems. We then present the main phases of our method-

ology in greater detail, and how attacker scenarios

can be efﬁciently used within these phases: Require-

ments/Analysis in section 4, HW/SW Partitioning in

section 5, and Software Design in section 6. Next, we

present the related work in Section 7. Finally, Section

8 concludes the paper.

2 INTEGRATING ATTACKER

MODELS WITH SYSTEM

DESIGN

1. The process starts with considering the needs and

threats of the system, which are expressed respec-

tively in Requirements and Attack Tree Mod-

els. Attack Trees may impact the Security Re-

quirements – for instance, to handle a threat, a

new requirement is added – , so these may be de-

signed together. Each Attack Tree is a diagram

gradually reﬁning the different steps necessary to

realize a single root attack. Regardless of which

individual attack steps are possible for the attacker

to perform, our ultimate concern is to ensure the

root attacks cannot be performed.

2. Next, the System is Designed. The functional-

ity of system components is modeled, along with

attacker scenarios which describe the attacker’s

interactions with the system. Attacker Scenar-

ios can be either pre-built attacker models (Dolev-

Li, L., Lugou, F. and Apvrille, L.

Evolving Attacker Perspectives for Secure Embedded System Design.

DOI: 10.5220/0006535802870294

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 287-294

ISBN: 978-989-758-283-7

287

Requirements

Analysis

Hardware/

Software

Partitioning

Attack Tree

Application

Architecture

Mapping

Verification

Safety Security Performance

Software/

System

Design

Software Design

Verification

Safety

Security

+ Architectural

Countermeasures

+ Attacker Model

(Dolev-Yao)

+ Application

Countermeasures

+ Attacker Scenario

Attack Trace

Legend

Modeling

Security

Verification

User-defined

Automatic

Reconsideration

+ Security

Properties

Figure 1: Design Methodology.

Yao) or a custom-generated attack behavior.

3. Based on the Requirements of Step 1, Security

Properties are modeled with regards to the sys-

tem design. Security properties describe if a sys-

tem or data should be secure against a speciﬁc

type of attack. For example, if a security require-

ment states that all communications shall be con-

ﬁdential (unrecoverable by the attacker), then one

security property of conﬁdentiality is added for

each communication exchange.

4. Formal Veriﬁcation: The security properties de-

scribed in Step 3 are veriﬁed on the system model

(step 2) with a security prover. The results of ver-

iﬁcation are either:

(a) All Security Properties are Satisﬁed, and no

root attacks can be performed. The system, if im-

plemented as speciﬁed, should be secure against

these conceived attacks in this form and fulﬁll the

requirements. (If new attacks arise afterwards or

the system model needs to be modiﬁed, then the

process must be repeated.)

(b) At Least One Security Property is Proven

False. If the prover can output an execution trace

demonstrating the property violation, then the At-

tack Trees of Step 1 can be enhanced with this

information. Then, to secure the system, either

we must reconsider (i) the Requirements of Step 1

(if the security requirements are too strict and un-

realistic), (ii) reconsider the security mechanisms

used to secure the model, or (iii) reconsider the

attacker model (An attacker is generally assumed

not to be willing to spend a cost more than the

value of the information recovered/system dam-

aged, and we can reconsider it if we have assumed

he/she has more resources than realistic.) After

modiﬁcations, we re-iterate through the process

until our system is veriﬁed secure.

Using this framework for integrating attacker be-

havior into system models, we next present our de-

tailed SysML-based methodology specialized for em-

bedded systems.

3 MODELING ATTACK

FRAMEWORKS FOR

EMBEDDED SYSTEMS

Embedded systems have faced a growing number

of attacks in recent years (Newman, 2016; Larson,

2017). Combining the ideas in the previous sec-

tion with the 3 phases of embedded system design

in SysML-sec (Analysis, Hardware Software Parti-

tioning, and System/Software Design), we present the

new methodology shown in Figure 1. As indicated,

we differentiate between the original modeling sub-

phases for embedded systems (in green), the security-

relevant sub-phases (in yellow), and the veriﬁcation

steps (in blue). The solid black arrows show steps the

designer must take in developing models manually,

the blue arrows show automated steps such as model

translation, and purple arrows show steps for recon-

sidering the model.

First, the Analysis phase considers the general

needs of the system. We rely on Requirements Di-

agrams, which describe the functional and security

needs of the system. Also, we design Attack Tree

Diagrams, which are based on SysML Parametric Di-

agrams, (Kordy et al., 2013), one for each main attack

against the system.

Next, in the Hardware/Software Partitioning

Phase, we design the functionality and candidate ar-

chitectures of a system in a highly abstracted way.

This phase follows the Y-Chart approach, modeling

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

288

application and architecture separately, and then map-

ping tasks to architecture (Kienhuis et al., 2002). The

Mapping model can then be evaluated in terms of

Safety, Security, and Performance. Security veriﬁca-

tion of the mapping is performed based on Security

Requirements and the Attacker Model. These results

can lead us to reconsider any of the existing models.

For security results, an attack trace is automatically

generated for each falsiﬁed security property. Based

on this attack trace, we can add Attacker Scenarios

to the application model, modeling possible attacks.

By examining the interaction of the attacker and sys-

tem, we can update our Attack Trees, and also accord-

ingly protect our system with Application-based and

Architecture-based security countermeasures.

Once a mapping is satisfactory, we proceed to the

Software Design Phase – a skeleton of this model

can be automatically obtained from partitioning mod-

els – where software models are much more detailed

that the high-level partitioning models. For instance,

partitioning models abstract algorithms as complexity

operations, while software models give the details of

these computations. Security veriﬁcation on the soft-

ware algorithms including security protocols may ﬁnd

that certain security requirements are not met. The at-

tack traces can again be used to generate new attacker

scenarios, which may require changes to the Attacker

Scenarios modeled in HW/SW Partitioning or Attack

Trees. The HW/SW Partitioning models may also be

revised. For example, if a security issue may not be

easily corrected with the selected hardware architec-

ture, we must return to the previous stage to recon-

sider those models.

System and Attacker Models are continually re-

ﬁned over iterations until our system is secure against

all predicted attacks.

4 ANALYSIS: SECURITY

REQUIREMENTS AND ATTACK

TREES

<<block>>

Vehicle

<<root attack>>

attackAutomaticBraking

<<attack>>

preventDataTransmission

<<attack>>

delayDataTransmission

<<attack>>

ddosController

<<attack>>

disableSensors

<<attack>>

manipulateLIDAR

<<attack>>

manipulateSensors

<<AND>>

<<attack>>

preventDataComputation

<<OR>>

<<attack>>

preventObstacleDetection

<<attack>>

preventBrakingFunction

<<attack>>

delayBrakingFunction

<<attack>>

manipulateCamera

<<attack>>

corruptControllerCode

<<attack>>

jamInCarCommunications

Figure 2: Attack Tree for Attacking Automatic Braking

Function on Connected Car.

The Analysis phase involves describing the require-

ments and use cases of the system, and simultane-

ously considers the possible attacks that the system

may face (Roudier et al., 2013). This analysis is ex-

pected to prepare the future system to be adapted to

counter the listed attacks. Analysis also prepares the

veriﬁcation phase since properties to be evaluated are

derived from requirements, and root attacks represent

attacks that shall not be reachable.

Throughout this paper, we demonstrate our

methodology on the design of a connected car

equipped with sensors, V2X, etc. Based on data from

the sensors, the system may need to send an emer-

gency brake command to the ECUs. V2X data may be

used to determine heavy trafﬁc along the road, and the

system should send its own V2X messages in the case

of unexpected reduced speed. Even without a con-

crete model of the system, we can choose security re-

quirements like “An attacker should not be able to af-

fect vehicle function”, reﬁned to “An attacker should

not be able to prevent emergency braking”.

Next, we model the possible attacks violating this

requirement, as shown in Figure 2. The root attack,

‘attack Automatic Braking’, is the ultimate goal of the

attack, and to perform this attack, an attacker needs

to perform a combination of the reﬁned attack steps.

Each attack step can be marked as possible or not,

and analyzer determines if the root attack is logically

possible. For example, if none of the 3 ways to at-

tack automatic braking ‘Prevent Brake Function Acti-

vation’, ‘Prevent Braking Function’, and ‘delay Brak-

ing Function’ are possible, then the root attack cannot

be carried out.

Depending on the system design, attack steps may

be added or removed, and the analyzer should be run

again to determine if each root attack is possible.

5 HW/SW PARTITIONING

The HW/SW Partitioning Phase involves the design

of the high-level functions and architecture of the

system. Based on the models and evaluation in this

phase, we can reﬁne our developed attack trees or dis-

cover new possible attacks, as explained below.

5.1 Modeling

A partitioning consists of three main types of models:

the application model, architectural model, and map-

ping model. First, we describe the base models in this

phase, and then discuss how to consider the attacker

capabilities.

The Application Model is a set of communicating

tasks built upon SysML block diagrams. The behav-

Evolving Attacker Perspectives for Secure Embedded System Design

289

Sensor_LIDAR

Sensor_Camera

SensorControl

Lidardata

envData

Sensor_Env

ECUGateway

V2XGateway

Central

V2Xdata

cameraData

broadcastData

cmdData

sensorData

sensorControl

<<BUS-RR>>

Bus0

CPU0

Sensor_Env

<<CPURR>>

CPU2

<<CPURR>>

Sensor_Camera

<<CPURR>>

SensorControl

CPU1

<<CPURR>>

Sensor_LIDAR

CPU3

CPU_ECU

<<CPURR>>

ECUGateway

CPU4

<<CPURR>>

V2XGateway

<<BUS-RR>>

Bus1

CPU_Central

<<CPURR>>

Central

<<BRIDGE>>

Bridge0

Figure 3: Application and Mappings Models for Connected

Vehicle Example.

ior of tasks is described abstractly with activity dia-

grams. The Architecture Model displays the under-

lying architecture as a network of abstract execution

nodes, communication nodes, and storage nodes. The

Mapping Model then partitions the application into

software and hardware, and speciﬁes the location of

their implementation on the architectural model. A

task mapped onto a processor will be implemented in

software, and a task mapped onto a hardware acceler-

ator will be implemented in hardware.

The application and architecture model for our

connected car is shown in Figure 3. The systems con-

tains a Central controller communicating with V2X,

and Sensor Control unit which manages the different

sensors. Different environmental conditions affect the

functionality of the system: during rain, braking dis-

tance changes, and the reliability of different sensors

is also affected. The architecture/mapping consists of

two central bus systems and one processor per task.

5.2 Security Countermeasures

In our previous work (Li et al., 2017), we demon-

strated how security can be considered in the HW/SW

Partitioning phase. As the V2X Gateway offers an ex-

terior connection to the outside world, we investigate

the consequences if it is compromised and allows an

attacker access to the internal vehicular communica-

tions (Henniger et al., ). In our example, we assume

the attacker has access to all communications along

the two main buses (i.e., Bus0 and Bus1).

Even before performing formal veriﬁcation, we

can add preliminary security countermeasures to our

mapping model to protect important communications.

As all inter-task data is being sent on buses accessible

to the attacker, we must secure the communications

with Application Countermeasures, which include en-

crypting data to prevent it from being comprehensible

to an attacker, or concatenating data with a calculated

Message Authentication Code (MAC) to ensure the

message cannot be modiﬁed.

Architectural Countermeasures such as Hardware

Security Modules and Firewalls can also be added.

Since security operations can be computationally-

intensive and require the secure storage of crypto-

graphic elements (e.g., keys), there exist specialized

co-processors Hardware Security Modules which can

perform cryptographic operations faster than a normal

processor and can store cryptokeys.

Firewalls ﬁlter communications and can block an

attacker without having to attempt to decrypt/analyze

the contents of his/her communications. Filtering

communications could prevent an attacker from in-

jecting code to a certain extent, if we limit the size of

allowed messages.

In our ﬁrst secured model, we only add application

countermeasures, in the form of MACs to data that we

do not want the attacker to forge, most importantly

commands to the ECU. In our next step, we evalu-

ate if these countermeasures are sufﬁcient and prevent

the ‘Attack Braking Function’ attack described in the

Analysis Phase.

5.3 Evaluation of Security

Data sent across channels can be evaluated in terms

of conﬁdentiality and authenticity. We perform secu-

rity veriﬁcation with ProVerif, a veriﬁcation tool op-

erating on a pi-calculus speciﬁcations of communi-

cating processes (Blanchet, 2001). ProVerif assumes

a Dolev-Yao attacker, who can read and write on any

public channel, create new messages, and apply cryp-

tographic primitives. We also transform the security

requirements described in the Analysis phase into for-

mal security queries, which we send to ProVerif. The

veriﬁer can check if queried data can be recovered by

the attacker (which violates conﬁdentiality), injected

by the attacker (which violates weak authenticity), or

replayed by the attacker (which violates strong au-

thenticity).

As shown in the methodology, veriﬁcation re-

sults for properties proven false are shown as ‘Attack

traces’ showing the attacker actions performed. Com-

mand data sent from the central controller to ECUs

was concatenated with their MAC, to ensure that the

attacker cannot modify the command.

This attack could be prevented if the original mes-

sage was concatenated with a sequence number or

timestamp. We could also reconsider the architecture,

such that the attacker would have no access to the bus

between Central and ECU Gateway.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

290

<<BUS-RR>>

Bus1

54%

<<CPURR>>

CPU4

60%

Central

<<CPURR>>

CPUECU

ECUGateway

<<CPURR>>

CPUECU

ECUGateway

21%

<<CPURR>>

CPU4

Central

66%

<<BUS-RR>>

Bus1

Attacker Scenario

interval

Loop

cmdData(1)

[bus access?]

[else]

analyzeCmd

cmdData(1)

forgeCmd

injectCode(V2X)

Loop

chl

cmdData(1)

Without Attacker

With Attacker

Performance

Results

<<CPURR>>

CPUV2X

V2X

40%

20%

<<CPURR>>

CPUV2X

V2X

Read Public

Channel

Write Public

Channel

Code Injection

Figure 4: Attacker Scenario and impact on performance.

5.4 Attacker Scenarios

To better evaluate the attacker impact on a system, we

model Attacker Scenarios in the form of an additional

task on the component diagram. They describe their

abstract behavior in terms of their injected data.

An attacker scenario consists of one or many at-

tacker tasks, representing separate functions working

together to carry out an attack on a system. An at-

tacker task’s behavior includes all possible actions

of a normal application task (read/write data on a

channel, control operations, execution of calculations,

etc). In addition, where regular tasks can only read

and write on channels directly associated with them-

selves, the attacker tasks may read and write on any

public channel. A public channel is deﬁned to be any

channel mapped to a path including at least one bus

accessible to the attacker. Furthermore, attacker tasks

possess an additional capability: ‘Code Injection’,

which replaces an application task’s behavior with an

attacker-determined one, modeling an attacker’s ca-

pability to change a task’s execution ﬂow which may

include code modiﬁcation.

We can also examine the impact on the system

when sending forged messages, whether sent by the

attacker directly or by a task whose code has been

modiﬁed. We previously noted that replay attacks

could be prevented by adding a sequence number to

messages before calculating the MAC. However, the

ECU Gateway must still process those messages even

if it will detect that they are forged. We can evaluate

the attacker impact on the system using simulation.

If we assume a rate at which the attacker can inject,

then we can evaluate using a simulation the impact of

performance. If we notice that the bus or processors

are processing mostly only the attacker messages or

show dramatically increased load, these performance

metrics can be used to conclude about the Availability

of a system.

The top of Figure 4 shows an attacker scenario

where the attacker has two options depending if it

has read/write access to the bus directly. The three

Attacker Behavior Elements are marked with the At-

tacker mask symbol, and labeled with their action.

With access to the bus, the attacker attempts to read

the public channel of current ECU commands and

then inject a fake one (by writing to the public chan-

nel ECUcmd) that differs signiﬁcantly (for example,

injecting a command to turn sharply while driving

straight on a freeway). Otherwise, the attacker will

perform code injection and change the functionality

of the V2X Gateway to constantly inject messages to

prevent legitimate commands from being processed.

We analyze the performance results in the second

case, as shown in the bottom of Figure 4. The load

of each architectural component is calculated as ac-

tive cycles divided by total execution cycles. In this

case, we notice a signiﬁcant increase in computations

performed on the ECU, and an increase in Bus load.

This new modeling capability allows us to analyze the

property ‘Availability’.

These Attacker Scenarios can be reﬁned in the fol-

lowing Software/System Design Phase, after which

we reconsider the attack trees to consider these new

attacks.

6 SOFTWARE DESIGN

The Software Design phase models the software part

of the system in greater detail. The general frame-

works of the Software models are generated automat-

ically from HW/SW Partitioning models, leaving the

user to reﬁne abstract elements, e.g. the implementa-

tions of algorithms.

The security of channels is determined by the ar-

chitecture in the previous stage. Indeed, while the ar-

chitecture diagrams are not part of this phase, they are

initially used to choose whether the connections be-

tween blocks of the Software Design models are ac-

cessible to the attacker or not.

6.1 Attacker Model

Attacker Scenarios in Software/System Design can

be used to analyze the data communications in more

detail. For example, we can analyze the communi-

cations between the sensors. In the previous phase,

we assumed that the attacker could access the bus on

which the different sensors communicate. Therefore,

Evolving Attacker Perspectives for Secure Embedded System Design

291

[else]

[|(lidardist-cameradist)/

lidardist|>threshold]

[mode==1]

setMode

modeNormal

modeRain

[mode==2]

error

valid

calculate Distances based

on Sensor Data

calculate ﬁnal distance

based on combination of

camera and lidar distances

...

calculate ﬁnal distance

based on only camera

distance

...

<<block>>

Sensor_Environment

~ out envData(int data)

<<block>>

SensorControl

~ in camData(int data)

~ in envData(int data)

<<block>>

Sensor_Camera

~ out camData(int data)

<<block>>

Sensor_LIDAR

~ out lidarData(int data)

<<block>>

Attacker

~ out camData(int data)

~ out lidarData(int data)

~ out envData(int data)

Figure 5: Sensor Software Design Models with Attacker.

we model the communications between the compo-

nents in this phase as occurring on a public channel

accessible to the attacker, as shown in the top of Fig-

ure 5, where public channels are marked with the eye

in a triangle. In our system, the Sensor Control block

implements a plausibility and coherence check on the

data received by the sensors as shown in Figure 5. The

attacker cannot inject arbitrary data that would greatly

differ from the other data present in the system, for

then the system will detect an anomaly. If the calcu-

lated distance to the nearest obstacle differs by over

X%, then the system could assume a malfunction or

attack was taking place and warn the user. In case of

rain, however, LIDAR data is not used and no coher-

ence check takes place.

However, if it were possible for the attacker to im-

itate both the LIDAR and the camera, then the system

would accept the forged data. If it should be possi-

ble to attack the environmental sensor (which may be

user set or acquiring meteorological data by internet),

then the attacker would only need to attack one of the

other two sensors.

6.2 Reconsideration of Attack Trees

In the last two sections, we examined different possi-

ble attacks on the system, including Denial of Service

attacks on the ECU Gateway, forging sensor data, etc.

We notice that the preliminary Attack Tree in Fig-

ure 2 was incomplete, as it did not cover all these at-

tack scenarios. For example, the attack ‘Manipulate

Sensors’ could also involve manipulating the Envi-

ronment sensor. Also, we can elaborate on some of

the listed attack steps, such as ‘prevent Braking Func-

tion’ that would involve the attack sub-steps ‘attack

V2X Gateway’ to gain control, and then ‘replay ECU

commands’. The preliminary Attack Tree of Figure 2

must be enhanced to add the new attacks which may

be possible in our system, as shown in Figure 6.

When we add countermeasures, certain attack

steps become impossible. For example, we could add

a ﬁrewall to ensure in-car communications cannot be

jammed. Furthermore, we could add timestamps to

ECU commands before calculating a MAC to prevent

replay attacks as we described in section 5.4.

As the root attack is still logically possible, more

countermeasures must be added to protect our sys-

tem. Subsequent iterations through the design pro-

cess could involve ensuring the sensor data could not

be forged, or considering if keys should be periodi-

cally distributed. Then, the security veriﬁcation could

evaluate if there exist vulnerabilities in the implemen-

tation of those security protocols, which may suggest

future attacker scenarios, and consequently, modiﬁ-

cations to the displayed Attack Tree or new Attack

Trees.

7 RELATED WORK

Regarding security in embedded systems, multiple

works develop toolkits for the design process only

(Balarin et al., 2003; Rosales et al., 2014; Kangas

et al., 2006), and many study the veriﬁcation of se-

curity, but few study both in one framework. Of the

works which investigate both, (Hansson et al., 2010)

relies on Architecture Analysis and Design Language

(AADL) models to consider architectural mapping

during security veriﬁcation. The authors note that a

system must be secure on multiple levels: software

applications must exchange data in a secure manner,

and also execute on a secure memory space and com-

municate over a secure channel. Our work, however,

investigates protections against an external attacker

instead of access control.

Another approach performs Design Space Explo-

ration on a vehicular network protecting against re-

play and masquerade attacks (Lin et al., 2015). The

project evaluates possible security mechanisms, their

effects on message sizes, and candidate architectures

during the mapping phase. While their work tar-

gets automotive systems and network communica-

tions, our analysis may be applied more broadly for

any embedded system. Also, we focus on the integrity

and conﬁdentiality of data itself instead of on speciﬁc

attacks.

7.1 Security Modeling and Veriﬁcation

Attack Defense Trees (Kordy et al., 2013) analyze the

possible attacks against a system, in conjunction with

the defenses that the system may implement. The sup-

porting toolkit ADTool analyzes attack scenarios to

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

292

<<block>>

Vehicle

<<root attack>>

attackAutomaticBraking

<<attack>>

preventDataTransmission

<<attack>>

delayDataTransmission

<<attack>>

jamInCarCommunications

<<attack>>

ddosController

<<attack>>

disableSensors

<<attack>>

manipulateSensors

<<AND>>

<<attack>>

preventDataComputation

<<OR>>

<<attack>>

preventObstacleDetection

<<attack>>

preventBrakingFunction

<<attack>>

delayBrakingFunction

<<attack>>

manipulateCamera

<<attack>>

corruptControllerCode

<<attack>>

manipulateCamera

<<attack>>

manipulateEnvSensor

<<AND>>

<<OR>>

<<Sequence>>

<<attack>>

attackV2XGateway

<<attack>>

ddosECUGateway

<<OR>>

<<attack>>

manipulateLIDAR

<<attack>>

replayECUcommand

<<countermeasure>>

AddFirewall

<<countermeasure>>

checkMAC+Timestamp

Figure 6: Modiﬁed Attack Tree after System Design and Evaluation.

determine the cost, probability, time, etc, required for

a successful attack.

The Knowledge Acquisition in Automated Spec-

iﬁcations approach Security Extension aims to iden-

tify security requirements for software systems (van

Lamsweerde, 2004). The methodology uses a goal-

oriented framework and builds a model of the sys-

tem, and then an anti-model which describes possi-

ble attacks on the system. Both models are incre-

mentally developed: threat trees are derived from the

anti-model and the system model adds security coun-

termeasures to protect against the attacks described in

the anti-model.

The Combined Harm Assessment of Safety and

Security for Information Systems (CHASSIS) method

considers safety and security together in a common

model (Raspotnig et al., 2013). Safety and security

hazards in the form of misuse cases are developed,

and then trade-off analysis to unify all requirements

and identify when safety and security conﬂict. While

these techniques targeting the requirements and anal-

ysis phase offer a detailed approach to considering

threats against safety and security, they are not yet

automated.

Unlike these works, our work allows formal veri-

ﬁcation of attack trees to check the possibility of exe-

cuting a root attack, and then continues on to design-

ing the system itself in the subsequent stages.

(Vasilevskaya and Nadjm-Tehrani, 2015) pro-

posed modeling security in embedded systems with

attack graphs to determine the probability that data

assets could be compromised. While their approach

is also UML-based, they focus on estimating proba-

bilities of success for attacks, while ours focuses on

verifying adequate placement of encryption.

UMLSec (J

urjens, 2002) is a UML proﬁle for ex-

pressing security concepts, such as encryption mech-

anisms and attack scenarios. It provides a modeling

framework to deﬁne security properties of software

components and of their composition within a UML

framework. It also features a rather complete frame-

work addressing various stages of model-driven se-

cure software engineering from the speciﬁcation of

security requirements to tests, including logic-based

formal veriﬁcation regarding the composition of soft-

ware components. However, UMLSec does not take

into account the HW/SW Partitioning phase neces-

sary for the design of IoTs.

The authors of (Dawkins and Hale, 2004) lever-

aged Attack Trees to analyze network security. Both

system vulnerabilities and attacker capabilities are

modeled and analyzed to determine the possible at-

tacks a system may face. (Hong and Kim, 2016)

also used a hierarchical attack representation model

(HARM) to assess different moving target defenses,

modeling both system vulnerabilities and attack

graphs and trees. (Ge et al., 2017) described a simi-

lar framework modeling attacks and defenses in IoTs.

While similar to our work as they described the sys-

tem vulnerabilities along with the attacker actions,

our toolkit models system behavior including counter-

measures instead of only vulnerabilities, and is sup-

ported by formal veriﬁcation.

8 CONCLUSION

Our Model-Driven methodology combines Attack

Trees with Embedded System Design, developing an

iterative design process evolving system models and

attacker models collaboratively. As demonstrated us-

ing a connected car case study, Attack Trees devel-

oped in the preliminary ﬁrst steps of modeling have

an incomplete vision of the system, and need to be

further reﬁned as the system is developed. Security

Evaluations reveal additional attacks, or provide im-

plementation details for existing predicted attacks. As

long as there exist executable root attacks, the system

must be further protected with additional countermea-

sures.

Future work will seek to better automate the gen-

eration of Attacker Scenarios. Attack traces could be

automatically translated into the attacker’s functional

model. We could reconstruct functional attack scenar-

ios based on attack traces and automatically integrate

them to the attack trees so that the designer is able to

improve system design or rework the attacker model

depending on the effect of the scenario on the system.

Evolving Attacker Perspectives for Secure Embedded System Design

293

We also plan to provide a toolbox of Attacker

Models, to provide the designer with some templates

or example attack scenarios, such as DDoS attacks,

replay attacks, brute-forcing of keys, etc., that he/she

can then further enhance. While our current security

prover ProVerif has limited support for mathematical

operations, we plan to integrate safety and security

veriﬁcation to allow formal evaluation of plausibil-

ity and coherence checks that we currently perform

with simulation. We may ﬁnd a different security

prover, or integrate security reasoning into our reach-

ability graphs. Furthermore, we’d like to better con-

nect analysis and implementation, such as connect-

ing Requirements Diagrams with implemented coun-

termeasures, etc. Our ultimate goal will be a com-

prehensive methodology for systematic modeling and

veriﬁcation of security.

REFERENCES

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

Driven Approach for Designing Safe and Secure Sys-

tems. In 3rd International Conference on Model-

Driven Engineering and Software Development, Spe-

cial session on Security and Privacy in Model Based

Engineering, France. SCITEPRESS Digital Library.

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.

Blanchet, B. (2001). An efﬁcient cryptographic protocol

veriﬁer based on prolog rules. In Proceedings of the

14th IEEE Workshop on Computer Security Founda-

tions, CSFW ’01, pages 82–, Washington, DC, USA.

IEEE Computer Society.

Constantin, L. (2016). Researchers hack Tesla Model S

with remote attack. http://www.pcworld.com/article/

3121999/security/researchers-demonstrate-remote-

attack-against-tesla-model-s.html.

Dawkins, J. and Hale, J. (2004). A systematic approach

to multi-stage network attack analysis. In Informa-

tion Assurance Workshop, 2004. Proceedings. Second

IEEE International, pages 48–56. IEEE.

Ge, M., Hong, J. B., Guttmann, W., and Kim, D. S. (2017).

A framework for automating security analysis of the

internet of things. Journal of Network and Computer

Applications, 83:12–27.

Hansson, J., Wrage, L., Feiler, P. H., Morley, J., Lewis, B.,

and Hugues, J. (2010). Architectural Modeling to Ver-

ify Security and Nonfunctional Behavior. IEEE Secu-

rity Privacy, 8(1):43–49.

Henniger, O., Apvrille, L., Fuchs, A., Roudier, Y., Ruddle,

A., and Weyl, B. Security Requirements for Automo-

tive On-Board Networks. In ITST 2009, Lille, France.

Hong, J. B. and Kim, D. S. (2016). Assessing the effective-

ness of moving target defenses using security models.

IEEE Transactions on Dependable and Secure Com-

puting, 13(2):163–177.

urjens, J. (2002). UMLsec: Extending UML for Secure

Systems Development. In Proceedings of the 5th In-

ternational Conference on The Uniﬁed Modeling Lan-

guage, UML ’02, pages 412–425, London, UK, UK.

Springer-Verlag.

Kangas, T., Kukkala, P., Orsila, H., Salminen, E.,

annik

ainen, M., H

ainen, T. D., Riihim

aki, J.,

and Kuusilinna, K. (2006). UML-based Multipro-

cessor SoC Design Framework. ACM Trans. Embed.

Comput. Syst., 5(2):281–320.

Kienhuis, B., Deprettere, E., van der Wolf, P., and Vissers,

K. (2002). A Methodology to Design Programmable

Embedded Systems: The Y-Chart Approach. In Em-

bedded Processor Design Challenges, pages 18–37.

Springer.

Kordy, B., Kordy, P., Mauw, S., and Schweitzer, P. (2013).

Adtool: Security analysis with attackdefense trees. In

Joshi, K., Siegle, M., Stoelinga, M., and DArgenio, P.,

editors, Quantitative Evaluation of Systems, volume

8054 of Lecture Notes in Computer Science, pages

173–176. Springer Berlin Heidelberg.

Larson, S. (2017). FDA conﬁrms that St.

Jude’s cardiac devices can be hacked.

http://money.cnn.com/2017/01/09/technology/fda-st-

jude-cardiac-hack/.

Li, L. W., Lugou, F., and Apvrille, L. (2017). Security-

Aware Modeling and Analysis for HW/SW Parti-

tioning. In Confer

ence on Model-Driven Engineer-

ing and Software Development (Modelsward’2017),

Porto, Portugal.

Lin, C.-W., Zheng, B., Zhu, Q., and Sangiovanni-

Vincentelli, A. (2015). Security-Aware Design

Methodology and Optimization for Automotive Sys-

tems. ACM Transactions on Design Automation of

Electronic Systems (TODAES), 21(1):18.

Miller, C. and Valasek, C. (2015). Remote exploitation of

an unaltered passenger vehicle. Black Hat USA.

Newman, L. (2016). The Botnet That

Broke the Internet Isn’t Going Away.

https://www.wired.com/2016/12/botnet-broke-

internet-isnt-going-away/.

Raspotnig, C., Katta, V., Karpati, P., and Opdahl, A. L.

(2013). Enhancing CHASSIS: A Method for Com-

bining Safety and Security. In Availability, Reliability

and Security (ARES), 2013 Eighth International Con-

ference on, pages 766–773.

Rosales, R., Glass, M., Teich, J., Wang, B., Xu, Y., and

Hasholzner, R. (2014). MAESTRO— Holistic Actor-

Oriented Modeling of Nonfunctional Properties and

Firmware Behavior for MPSoCs. ACM Trans. Des.

Autom. Electron. Syst., 19(3):23:1–23:26.

Roudier, Y., Idrees, M. S., and Apvrille, L. (2013). To-

wards the Model-Driven Engineering of Security Re-

quirements for Embedded Systems. In proceedings of

MoDRE’13, Rio de Janeiro, Brazil.

van Lamsweerde, A. (2004). Elaborating Security Require-

ments by Construction of Intentional Anti-Models. In

Proc. of the 26th International Conference on Soft-

ware Engineering , ICSE ’04, pages 148–157.

Vasilevskaya, M. and Nadjm-Tehrani, S. (2015). Quanti-

fying Risks to Data Assets Using Formal Metrics in

Embedded System Design, pages 347–361. Springer

International Publishing, Cham.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

294