Security-aware Modeling and Analysis for HW/SW Partitioning

Letitia W. Li

1,2

, Florian Lugou

and Ludovic Apvrille

ecom ParisTech, Universit

e Paris-Saclay, 450 route des Chappes, Biot, France

Institut VEDECOM, 77 rue des Chantiers, Versailles, France

Keywords:

Embedded Systems, Partitioning, ProVerif, Formal Veriﬁcation.

Abstract:

The rising wave of attacks on communicating embedded systems has exposed their users to risks of informa-

tion theft, monetary damage, and personal injury. Through improved modeling and analysis of security, we

propose that these ﬂaws could be mitigated. Since HW/SW partitioning, one of the ﬁrst phases, impacts future

integration of security into the system, this phase would beneﬁt from supporting modeling security abstrac-

tions and security properties, providing designers with useful partitioning feedback obtained from a security

formal analyzer.

In this paper, we present how our toolkit supports security modeling, automated security integration, and for-

mal analysis during the HW/SW partitioning phase for secure communications in embedded systems. We

introduce “Cryptographic Conﬁgurations”, an abstract representation of security that allows us to verify se-

curity formally. Our toolkit further assists designers by automatically adding these security representations

based on a mapping and security requirements.

1 INTRODUCTION

Many recent attacks targeted security vulnerabilities

on embedded devices such as the Tesla hack (Con-

stantin, 2016), mobile&smart phones (Maslennikov,

2010), avionics (Costin and Francillon, 2012), drones

(Rodday, 2016), and smart objects such as the Fitbit

(Apvrille, 2015). These security vulnerabilities leave

users susceptible to personal injury, theft of personal

information, or ﬁnancial damage.

Finding security ﬂaws in these systems is difﬁcult,

as their complexity is further increased by their het-

erogeneous nature; one must analyze both hardware

and software components, and the consequent interac-

tions. Moreover, correcting these security ﬂaws might

be difﬁcult once the system has been released - and

sometimes impossible - if the ﬂaws cannot be cor-

rected by software update only. As commonly stated,

these kinds of issues should be discovered early in the

development process.

The SysML-Sec methodology was introduced to

handle the design of such complex systems, in terms

of safety, performance, and security (Apvrille and

Roudier, 2015). SysML-Sec extends UML for the de-

sign of embedded systems. One of its important early

development phases is the hardware / software parti-

tioning phase, which distributes functions to be real-

ized by the system among candidate hardware archi-

tectures. This phase decides on the “best” architecture

according to several criteria such as cost of the plat-

form and its performance. To better address embed-

ded system security, the choice of architecture should

also be based on the ability of the architecture to sup-

port security features for secure communication.

Security properties of the components of the ar-

chitecture itself should be modeled based on attacker

capabilities. For example, communication buses and

memories can be internal and secure against an exter-

nal attacker, and functions mapped to the same pro-

cessor using an on-die RAM can consider their mes-

sage exchange secure. On the contrary, external buses

can be spied on. The chosen architecture also affects

where encryption algorithms need to be executed and

where cryptographic materials need to be stored to

fulﬁll security requirements.

Figure 1 shows the possible approaches to mod-

eling security during partitioning, in terms of secure

data exchange. Using the current HW/SW partition-

ing methodology of the Y-chart approach (Method A)

(Kienhuis et al., 2002), manually modeling security

only in terms of overhead or calculation complexity

is insufﬁcient due to the lack of support for security

assessment. Method B involves manually modeling

security in the application, and then performing map-

302

Li L., Lugou F. and Apvrille L.

Security-aware Modeling and Analysis for HW/SW Partitioning.

DOI: 10.5220/0006119603020311

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 302-311

ISBN: 978-989-758-210-3

Figure 1: Methods for Security in Partitioning: Method A shows the Y-chart approach. Method B shows security-aware

modeling with security analysis. Method C shows automated security generation.

ping and analysis. Method C improves upon B by au-

tomatically generating mappings with added security

mechanisms based on provided data security require-

ments. Afterwards, a designer may reﬁne or mod-

ify the automatically generated mapping (for exam-

ple, with additional or altered security mechanisms),

and then perform veriﬁcation and analysis to ensure

the ﬁnal mapping fulﬁlls safety, performance and se-

curity requirements.

This paper presents abstract security modeling of

data exchange during the HW/SW partitioning pro-

cess, and how our toolkit TTool (Apvrille, 2003) ex-

tends support to Methods B and C. In particular, our

contribution involves creation of Cryptographic Con-

ﬁgurations for abstract modeling of security mecha-

nisms and estimating performance costs for added se-

curity based on security requirements and a mapping.

Also, the paper shows how to formally evaluate the

placement and efﬁciency of security mechanisms with

regards to security properties at stake in the partition-

ing phase. Future works will elaborate on other types

of security.

Section 2 presents hardware/software partitioning

in our toolkit. Section 3 presents our case study on

which we demonstrate our methodology. Section 4

presents our approach to integrating security design

elements into a partitioning environment. Next, we

present the related work in Section 5. Finally, Section

6 proposes future work and concludes the paper.

2 CONTEXT

2.1 Partitioning

The HW/SW partitioning phase requires a description

of the application functionalities and their communi-

cations, the selection of a system’s hardware architec-

ture and the mapping of functional tasks - and their

communications - to different hardware and software

components. Partitioning is commonly performed at

a high-level of abstraction (also known as System-

Level Design Space Exploration) where application

functionalities are described mostly in terms of com-

munications and execution times. Design Space Ex-

ploration intends to select an architecture according to

criteria such as silicon area, power consumption, sat-

isfaction of safety properties and performance. The

performance includes the latencies between an input

and an ouput, the schedulability of the tasks on each

processor, the schedulability of bus transfers, and ﬁ-

nally the peak and average load on processors and

buses.

2.2 Modeling Partitioning in

SysML-Sec

A SysML-Sec partitioning consists of three modeling

stages: application modeling, architectural modeling,

and mapping modeling.

The application model comprises of a set of com-

municating tasks built upon block diagrams. The be-

havior of tasks is described abstractly with activity di-

agrams. Functional abstraction allows us to ignore the

exact calculations and data processing of algorithms,

and consider only their relative execution time. Data

abstraction allows us to consider only the size of data

sent or received, and ignore details such as type, val-

ues, or names.

The architectural model displays the underlying

architecture as a network of abstract execution nodes,

communication nodes, and storage nodes. Execu-

tion nodes consist of CPUs and Hardware Accelera-

tors. All execution nodes can be parametrized with

data size, instruction execution time, and clock ra-

tio. CPUs can further be customized with schedul-

ing policy, task switching time, cache-miss percent-

age, etc. Communication nodes include bridges and

buses. Buses connect execution and storage nodes

for task communication and data storage or exchange,

and bridges connect buses. Buses are characterized by

their arbitration policy, data size, clock ratio, etc., and

Security-aware Modeling and Analysis for HW/SW Partitioning

303

Figure 2: Drone Application Design.

bridges are characterized by data size and clock ratio.

Storage nodes are memory units, which are deﬁned

by data size and clock ratio.

Mapping partitions the application into software

and hardware as well as specifying 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 accel-

erator will be implemented in hardware. The exact

physical path of a data/event write may also be speci-

ﬁed by mapping channels to buses, bridges and mem-

ories.

2.3 Formal Veriﬁcation During

Partitioning

Once mapping is complete, formal veriﬁcation eval-

utates safety properties (reachability, liveness, dead-

lock), the scheduling of tasks and transactions on

buses, and the worst case execution time and CPU/bus

loads. Simulation is used for step by step execution of

the application, and for evaluation of precise timing

for a given execution trace.

Before the present contribution, security could not

be explicitly modeled in the mapping stage. The ad-

ditional computation power induced by the introduc-

tion of security mechanism could be evaluated by in-

dicating the execution complexity of a security mech-

anism, but its impact on security could not be mod-

eled or veriﬁed. For example, in (Schweppe et al.,

2011), it was shown how to evaluate the impact of

security computation on an automotive system. The

present contribution intends to perform architecture

exploration that takes into account both the fulﬁllment

of security requirements and their impact on the per-

formance of the system. This extension should help

in ﬁnding an architecture that can enforce the secu-

rity requirements while still respecting its safety and

performance properties.

3 CASE STUDY

Autonomous Drones offer many avenues of support

for future diaster relief efforts. Their manuverabilty

allows them to access remote locations even with

damaged roads, or access damaged structures for re-

connaisance instead of risking relief workers. Com-

bined with detection systems, these drones may pro-

cess captured images and broadcast conditions of dis-

covered victims to relief headquarters.

However, use of drones during these precarious

situations induces problems of their own. Previous

work (Rodday, 2016) has demonstrated how an in-

secure remote connection to the drone allows an at-

tacker to hijack control. Captured images of victims

are sensitive and, for the sake of privacy, they should

not be allowed to be intercepted and posted online

or published (Tanzi et al., 2015). Also, drones ca-

pable of generating a 3D mapping of a building carry

a detailed architectural plan of an area, which could

be valuable to criminals targeting this location. Even

if an attacker physically steals a drone, the on-board

sensitive information should remain conﬁdential.

In this case study, we will consider a drone which

communicates with a Remote Control Center for mis-

sion directives using Wiﬁ to navigate to a target area

and search for victims. The drone itself consists of

a Main Controller, Image Processing Unit, Camera,

Infrared Sensor, and Motor Controller. Activity di-

agrams of the Main Controller and Remote Control

Center are shown in Figure 2. The Main Controller

calculates a trajectory based on mission commands

and image data, and uses IR data to check for vic-

tims. The drone constantly updates its status to Re-

mote Control Center. Channels through which sen-

sitive data are sent and that we wish to secure are

marked with a grey lock and question mark. Re-

mote Control Center is mapped to an external com-

puter, and the drone itself must contain the physical

Figure 3: Drone Sample Architecture and mapping.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

304

Figure 4: Overview of Modeling and Analysis.

sensors and drivers: Camera, IR, and Motor Con-

troller. Also, the drone and remote computer must be

modeled as communicating over an insecure bus, but

the remainder of the architecture and mapping is yet

to be determined. For example, moving task Image

Processing Unit to the remote computer decreases on-

board processing and saves battery power, but broad-

cast of unencrypted image data is undesired. While

our toolkit can perform rapid exploration of multi-

ple architectures, in the interest of space we present

two mappings: one with all processing on-board the

drone, and another leaving only the minimal tasks on

the drone. Figure 3 shows the two proposed map-

pings. We model that the remote CPU offers more

processing power, so it executes tasks faster. In the

following section, we present how our toolkit auto-

matically generates a secure model for each mapping

and subsequent analysis.

4 SECURE PARTITIONING

In this section, we present our contribution: exten-

sions to the HW/SW partitioning phase with secure

data exchange concepts to support Methods B and C

of Figure 1. Adding security semantics — and even

more, proving security properties — during the par-

titioning phase is a difﬁcult challenge. On the one

hand, the ideal security analysis would take into ac-

count every single detail of the system. On the other

hand, the designer needs to quickly describe his/her

system for efﬁcient design space exploration, which

requires providing an abstract description of the sys-

tem. We provide a security semantic that does not

require the designer to deal with implementation de-

tails that are irrelevant to partitioning. For example,

we are not interested during partitioning in the im-

plementation of encryption algorithms; we only need

to consider parameters that will affect the partition-

ing choice (satisfaction of security properties, execu-

tion time, data size). Our solution uses Cryptographic

Conﬁgurations, a tag indicating various security func-

tions and their overhead.

While the implementation details ultimately deter-

mine the security of a system, taking security into ac-

count in early development phases, without construct-

ing the entire software/system design, would prevent

costly late-stage reworking of designs that present

vulnerabilities due to early partitioning choices. Even

if actual security algorithms will be more complex,

basic security primitives and relative computation

complexities should be accurate and provide useful

feedback to designers when selecting a mapping.

An overview of the aspects of security modeling

and analysis is shown in Figure 4. Starting with a base

partitioning model, our toolkit automatically gener-

ates the secured models (which the designer can mod-

ify), and then ﬁnally translates a ﬁnal model into a

speciﬁcation handled by a formal veriﬁer — ProVerif

(Blanchet, 2001).

4.1 Modeling of Security Mechanisms

We introduce Cryptographic Conﬁgurations to allow

the security veriﬁer to track data encryption elements,

used in Methods B and C of Figure 1. Within activ-

ity diagrams, they appear as an upside-down pentagon

marked with their type, as shown in Figure 4. Crypto-

graphic Conﬁgurations can be typed as follows. Sym-

Security-aware Modeling and Analysis for HW/SW Partitioning

305

Figure 5: Window for speciﬁcation of Cryptographic Con-

ﬁguration.

metric Encryption, Asymmetric Encryption, and MAC

patterns encrypt data along with a key/keys speciﬁc

to the pattern. Hash calculates a hash of the data.

Nonces can be concatenated to messages before en-

cryption to verify authenticity. Advanced allows the

user to indicate their own encryption scheme, such as

combinations of Cryptographic operations.

Figure 5 shows the speciﬁcation of a Crypto-

graphic Conﬁguration. The designer can choose the

type, and then the corresponding performance proper-

ties. For example, encryption operations may be char-

acterized by an Encryption and Decryption Computa-

tional Complexity (a measure of the relative execution

cycles depending on the processor), and Overhead

(additional bits added to the message due to encryp-

tion). Within the encryption conﬁgurations, a speci-

ﬁed nonce may also be concatenated onto messages to

prevent replay attacks. Cryptographic material such

as nonces are characterized by a size in number of

bits. These parameters allow us to model the impact

of security mechanisms on performance when evalu-

ating candidate mapping.

Cryptographic Conﬁgurations can also secure

other cryptographic material such as keys. For ex-

ample, we can model key distribution, where one task

forges a key for Symmetric Encryption, and sends it

encrypted with another task’s public key. The receiv-

ing task can then decrypt the message with its own

private key to recover the shared key.

The security of the hardware architecture itself is

modeled by specifying if a bus is insecure or secure

(marked with a green shield) depending on the as-

sumed attacker capabilities. For example, on Figure

3, the Wiﬁ connection is modeled insecure and all

data broadcast is available to an attacker, where both

internal buses on the Remote Computer and Drone are

modeled as secure. In our case study, we ﬁrst limit our

protection to data broadcast wirelessly and to external

attackers.

To send encrypted data along a channel, the de-

signer must create a Cryptographic Conﬁguration, tag

all channels along which encrypted data is sent, and

ﬁnally recover the original data with the Decryption

operator. All the keys must be mapped to memories

before security veriﬁcation, and the toolkit warns a

designer if access to a key implies transmission across

a non-private channel.

4.2 Modeling of Security Properties

Figure 6: Translation result of a MAC cryptographic conﬁg-

uration.

The purpose of our work is to provide feedback to the

designer about various security-related properties of

the partitioning model. These properties are deﬁned

to match their counterparts in the prover (ProVerif)

speciﬁcation. A more formal deﬁnition of these prop-

erties can thus be found in the ProVerif user manual

or other publications (Blanchet, 2001) for instance.

4.2.1 Reachability

An element of a state machine of a task is said to

be reachable if there exists an execution trace of the

model in which this element is reached.

4.2.2 Conﬁdentiality

We say that an exchange on a channel, identiﬁed by

its cryptographic conﬁguration, is not conﬁdential if

the attacker is able to get the content of a message

exchanged using the cryptographic conﬁguration by

listening and sending messages, and performing com-

putations.

4.2.3 Integrity

Integrity – also called weak authenticity – is a prop-

erty of an exchange, characterized by an input opera-

tion and its associated output operation. This property

implies that each message received at the input oper-

ation was necessarily sent in the exact same form by

the associated output operation.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

306

For instance, an exchange tagged with a MAC

cryptographic conﬁguration would be used to model

the fact that the message is concatenated with its

MAC. An implicit veriﬁcation is also considered be-

fore fully admitting the message on the other end of

the channel. If the key used for computing this MAC

is only used at the output and input operations, in-

tegrity will be proved true since each time a message

m is accepted at the input operation (state B in Fig-

ure 6), this means that the message was received with

MAC(m), which can only be computed if m was sent

at the corresponding output operation (state A in Fig-

ure 6).

Note that encryption and decryption are modeled

with ProVerif by using a linked constructor and de-

structor function. This means that the decryption of a

received message only completes if this message was

previously forged by calling the encryption function

with the same key that is used to decrypt it. Thus, if

a symmetric key is shared only by the sender and the

receiver, integrity will be maintained for any message

encrypted by the sender using this key.

4.2.4 Strong Authenticity

Like integrity, strong authenticity is a property at-

tached to an exchange. Strong authenticity implies

weak authenticity, but also requires that, given mul-

tiple executions of the system that would happen in

parallel (we call each of these executions a session), a

message received at this input operation is sent by the

associated output operation of the same session.

If a MAC cryptographic conﬁguration is used as

earlier and a message m is received at the input op-

eration, then the message was necessarily sent by the

associated output operation. However, this output op-

eration could generate the message m in one session,

and m could be received in two different sessions.

MAC is indeed not sufﬁcient to guarantee strong au-

thenticity. This failure to provide strong authenticity

makes the system vulnerable to replay attacks. Thus,

strong authenticity can be ensured combining MAC

and nonces cryptographic conﬁgurations.

4.3 Automated Security Generation

While Cryptographic Conﬁgurations can be manually

handled by the designer, it is also possible to auto-

matically generate these security elements, as shown

in Method C of Figure 1. Based on security re-

quirements provided by the designer, our toolkit au-

tomatically generates Cryptographic Conﬁgurations

for each channel whose data must be secure. Cur-

rently, we support automatic preservation of conﬁden-

tiality (protecting against leakage of sensitive data)

and strong authenticity (protecting against tampering

and replay). When both need to be guaranteed, Cryp-

tographic Conﬁgurations are generated so that sensi-

tive data will be concatenated with a nonce and then

encrypted before being transmitted across an insecure

channel. This automated encryption adds a basic esti-

mation of security, which the designer can later mod-

ify. This transformation is shown in Figure 4 and de-

scribed in Algorithm 1.

In our illustrated example, we present two tasks,

where outTask sends data along a channel ch to in-

Task. We assume that they have pre-shared keys. To

ensure strong authenticity of the exchange, ﬁrst in-

Task forges a nonce n and sends it to outTask. A new

channel nonceChannel is generated for this purpose.

Upon receiving the nonce, outTask concatenates it to

the data to be sent, and then in this case uses symmet-

ric encryption to encrypt the combined message. The

encrypted message is sent to inTask, which then de-

crypts it. The decrypted message is split to separate

out the nonce, and if the received nonce matches the

sent one, then inTask accepts the sent data.

foreach channel ch do

foreach bus in path do

if bus = public then

ch.security ← insecure;

end

if ch.security = insecure then

inTask.addChannel(nonceChannel);

outTask.addChannel(nonceChannel);

New: n [CryptoConf]

ch.inTask.forgeNonce(n);

ch.inTask.send(n);

New: autoEncrypt [CryptoConf]

autoEncrypt ← ch.outTask.encrypt(ch.data |

n);

ch.outTask.send(autoEncrypt);

recData ← ch.inTask.receive(autoEncrypt);

decData | n2 ← ch.inTask.decrypt(recData);

if n = n2 then

symData ← decData;

end

Algorithm 1: Pseudocode of secure model generation. Note

that “|” means concatenate.

4.4 Formal Veriﬁcation of Security

Properties

Security analysis is performed with ProVerif, a ver-

iﬁcation tool operating on pi-calculus speciﬁcations

(Blanchet, 2001). A ProVerif speciﬁcation con-

sists of a set of processes communicating on pub-

lic and private channels. Processes can split to cre-

Security-aware Modeling and Analysis for HW/SW Partitioning

307

Figure 7: Security Veriﬁcation results for Mapping 2 and auto-generated secured Mapping 2.

ate concurrently executing processes, and replicate

to model multiple executions (sessions) of a given

protocol. Cryptographic primitives such as symmet-

ric and asymmetric encryption or hash can be mod-

eled through constructor and destructor functions.

ProVerif assumes a Dolev-Yao attacker, which is a

threat model in which anyone can read or write on

any public channel, create new messages or apply

known primitives. Other works used ProVerif to an-

alyze security in real-world systems such as EVITA

(Pedroza et al., 2011) and Direct Anonymouse Attes-

tation (Smyth et al., 2015).

Once a complete application modeling has been

mapped to an architecture, a ProVerif speciﬁcation

can be generated from the partitioning model as

shown in Figure 4. Inﬁnite parallel processes are gen-

erated for each task, and each task sends and receives

data or performs cryptographic operations as shown.

In (Lugou et al., 2016), we presented a translation

from a software model consisting of states, actions,

and cryptographic operations. We leverage this trans-

lation by ﬁrst converting our partitioning model into

an equivalent software model representation, and use

the existing translation process to generate a ProVerif

model.

The main ideas of the translation are to convert

each functional task into a software-model block, and

to transform cryptographic conﬁgurations into their

corresponding cryptographic primitives. Since our

software model will be used only for security veri-

ﬁcation, we only concern ourselves with aspects of

the architecture if they impact the security of the sys-

tem. We therefore preserve the existance of each

task, its behavior including security operations, and

all inter-task communications. Furthermore, to pre-

serve a task’s accessible keys, we add the key as an

attribute to each software block if its corresponding

task could access a memory storing that key through

a secure path. On the other hand, we disregard simu-

lation parameters such as cache miss or pipeline size.

We also do not distinguish between tasks mapped to

CPUs and Hardware Accelerators since, while the

tasks mapped to Hardware Accelerators would ulti-

mately not be present in a software model, we must

nonetheless maintain their existance to examine inter-

task communications at this stage.

Also, each communication path between tasks –

mapped to a set of buses, bridges, memories – is trans-

lated into an abstract software-model channel. Any of

the communication nodes to which a path is mapped

can be tagged by the user as secure – which corre-

sponds in our context to the impossibility for an at-

tacker to access it. If a path is mapped to a set of

communication nodes that are all tagged as secure,

the resulting software-model channel will be private.

Otherwise, a public channel is used.

4.5 Veriﬁcation Results

ProVerif veriﬁcation is performed on the translated

speciﬁcation, and results are displayed on the graph-

ical diagrams for user convenience so they are visi-

ble as the user continues to reﬁne the design. Figure

7 shows the security veriﬁcation results for the un-

secured mapping 2 with remote processing, and then

the veriﬁcation results for the automatically generated

secured model.

Data exchanged across channel vulnerable to an

attacker is indicated by a crossed-out red lock. How-

ever, data proved conﬁdential is indicated by a green

lock. The name of the mapping is displayed next

to veriﬁcation results. If a channel sends data en-

crypted with a Cryptographic Conﬁguration, then we

display the security veriﬁcation result for both unen-

crypted and encrypted data. For example, imgData is

sent across a channel that is mapped to an insecure

path in architecture for mapping Mapping2

enc, but

data sent across that channel encrypted with Crypto-

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

308

Table 1: Performance Results over Mappings.

Mapping

Drone CPU Usage

(%)

Drone Bus Usage

(%)

Execution Time

(cycles)

Mapping 1 (On-board

processing)

95.8 1.7 2933

Mapping 1 Secured 99.8 0.4 5748

Mapping 2 (Remote

processing)

55.8 0.1 1855

Mapping 2 Secured 77.3 0.1 3419

graphic Conﬁguration autoEncrypt imgData is con-

ﬁrmed secure. Weak Authenticity and Strong Authen-

ticity are indicated by the split lock with the half-locks

colored green for veriﬁed true and half-locks colored

red and crossed out for veriﬁed false. For example, on

the unsecured model, missionCmnd is veriﬁed regard-

ing strong and weak authenticity while motorCmnd is

not. When the authenticity results refer to data se-

cured by a Cryptographic Conﬁguration, the lock is

annotated with the name of that conﬁguration.

As shown, initially image data and motor com-

mands can be guaranteed neither conﬁdential nor

authentic, but our automatically generated secured

model ensures that data encrypted with Cryptographic

Conﬁgurations are secure.

4.6 Impact of Security on Safety and

Performance

Security mechanisms add overhead, affecting safety

properties, schedulability, and performance. Forging

a nonce or performing encryption occupy computa-

tion cycles, and encrypted data may include extra bits

compared with original data. In addition, sending an

encrypted message sometimes means sending more

bits, therefore message transfer time is increased, and

more memory is used to store the extra data. A cho-

sen ‘best’ mapping may later be demonstrated non-

optimal with the addition of necessary security mech-

anisms.

We evaluated the performance of the mappings for

our disaster relief drone. Table 1 shows simulation

results over 10,000 runs for Mapping 1 with all tasks

mapped to the drone (On-board processing), and for

Mapping 2 with minimal tasks mapped to the drone

(Remote processing), and both their automatically

generated secured models. As expected, Mapping

1’s onboard CPU has much higher usage than Map-

ping 2’s, and since computationally intensive tasks are

performed on a slower drone CPU, execution time is

increased as well. Upon securing all data broadcast

wirelessly, there is a signiﬁcant increase in on-board

CPU usage and execution time. We could explore

other architectures, such as addition of extra CPUS or

Cryptographic Accelerators dedicated to performing

encryption, assuming the drone could support addi-

tional components.

To minimize the monetary and performance costs,

security mechanisms and dedicated cryptographic ac-

celerators should be added only where necessary. As

shown, our toolkit determines the location of insecure

data exchange and suggests a basic placement of secu-

rity mechanisms for an architecture. A designer can

then adapt and customize the model or architecture

accordingly with provided performance results. For

any provided architecture and mapping, our toolkit

formally veriﬁes the conﬁdentiality and weak/strong

authenticity of sensitive data.

5 RELATED WORK

Many design environments focus on the design pro-

cess of embedded systems (Balarin et al., 2003; Ros-

ales et al., 2014; Kangas et al., 2006), and many on

the veriﬁcation of security, but few study both in one

framework. (Hansson et al., 2010) relies on Archi-

tecture Analysis and Design Language (AADL) mod-

els 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 communicate over a

secure channel. Our approach, however, considers se-

curity regarding protection against external attackers

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.

Security-aware Modeling and Analysis for HW/SW Partitioning

309

5.1 Security Modeling

Many works address the modeling of security during

software design only. SecureUML enabled the design

and analysis of secure systems by adding mechanisms

to model role-based access control (Lodderstedt et al.,

2002). Authorization constraints are expressed in Ob-

ject Constraint Language (OCL) for formal veriﬁca-

tion. Our security model focuses on protecting against

an external attacker instead of access control. In con-

trast to formula-based constraints or queries, our ap-

proach to security analysis relies on graphically an-

notating the security properties to query within the

model.

Another work (Vasilevskaya and Nadjm-Tehrani,

2015) proposed modeling security in embedded sys-

tems with attack graphs to determine the probability

that data assets could be compromised. While their

approach is also UML-based, they focus on estimat-

ing probabilities of success for attacks, while ours fo-

cuses 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.

5.2 Formal Veriﬁcation of Security

Assessing security properties when designing soft-

ware components relies on formal approaches. Heit-

meyer et al. veriﬁed data separation between parti-

tions with possibly different security levels for em-

bedded devices. (Drouineaud et al., 2004) introduces

a ﬁrst order Linear Temporal Logic (LTL) into the Is-

abelle/HOL theorem prover, allowing the modeling of

both a system and its security properties, but unfortu-

nately leading to non-easily reusable speciﬁc models.

Many other projects formally verify security pro-

tocols using a variety of modeling and programming

languages. (Avalle et al., 2014) provides a recent sur-

vey of various works. From F#, C, and Java-coded

protocols, the surveyed works generate models for

evaluation in a variety of abstract modeling languages

such as Horn clauses, ASPIER, and First-order logic.

Our toolkit however, translates graphical models.

The Software Architecture Modeling (SAM)

framework (Ali et al., 2009) aims to bridge the gap

between informal security requirements and their for-

mal representation and veriﬁcation. SAM uses for-

mal and informal security techniques to accomplish

deﬁned goals and mitigate ﬂaws. SAM relies on a

well established toolkit - SMV - and considers a threat

model, but the ”security properties to proof” process

is not yet automated. In contrast, our work focuses on

automatic formal veriﬁcation from an abstract parti-

tioning model.

6 FUTURE WORK AND

CONCLUSION

Designing safe and secure embedded systems re-

quires us to explicitly take into account these two con-

straints early during the development process. Since

safety and security can strongly impact the HW/SW

partitioning of these systems, the paper proposes a

new approach to capture both security mechanisms

and security properties, and evaluate them with re-

gards to security and performance properties.

Our contribution enhances partitioning models

with annotations for secure data exchange (including

cryptographic conﬁgurations), offers a utility to au-

tomatically generate secured models, and proposes a

model-to-ProVerif transformation, all implemented in

our toolkit. We have tested our toolkit on partitioning

and securing larger systems, leading us to conclude

that our method can be used to model, secure, and

analyze real world industrial embedded systems in a

variety of disciplines (such as telecom and automotive

systems, up-to-date cryptographic protocols, etc.).

Our future work will extend our security modeling

to access control, timestamps, self-updating nonces

(sequence numbers), and other considerations. Proof

of accuracy and soundness of the transformation is an-

other important future work. We also plan to facilitate

the capture of security constraints and mechanisms.

We envision that our contribution to modeling of

security during partitioning offers designers increased

support in the design of secure embedded systems.

REFERENCES

Ali, Y., El-Kassas, S., and Mahmoud, M. (2009). A rig-

orous methodology for security architecture modeling

and veriﬁcation. In Proceedings of the 42nd Hawaii

International Conference on System Sciences, volume

978-0-7695-3450-3/09. IEEE.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

310

Apvrille, A. (2015). Geek usages for your Fitbit Flex tracker

Hack.lu, Luxemburg, October 2015. Slides at fra-

madrive.org/index.php/s/Wk6nxAKMpVTdQl4.

Apvrille, L. (2003). TTool. ttool.telecom-paristech.fr.

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.

Avalle, M., Pironti, A., and Sisto, R. (2014). Formal veriﬁ-

cation of security protocol implementations: a survey.

Formal Aspects of Computing, 26(1):99–123.

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.

Costin, A. and Francillon, A. (2012). Ghost in the

Air(Trafﬁc): On insecurity of ADS-B protocol and

practical attacks on ADS-B devices. In BLACKHAT

2012, July 21-26, 2012, Las Vegas, NV, USA, Las Ve-

gas, USA.

Drouineaud, M., Bortin, M., Torrini, P., and Sohr, K.

(2004). A ﬁrst step towards formal veriﬁcation of se-

curity policy properties for RBAC. In QSIC’04, pages

60–67, Washington, DC, USA.

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.

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. F., Wolf, P. v. d., and Vis-

sers, K. A. (2002). A Methodology to Design Pro-

grammable Embedded Systems - The Y-Chart Ap-

proach. In Embedded Processor Design Challenges:

Systems, Architectures, Modeling, and Simulation -

SAMOS, pages 18–37, London, UK, UK. Springer-

Verlag.

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.

Lodderstedt, T., Basin, D. A., and Doser, J. (2002). Se-

cureUML: A UML-Based Modeling Language for

Model-Driven Security. In Proceedings of the 5th In-

ternational Conference on The Uniﬁed Modeling Lan-

guage, UML’02, pages 426–441, London, UK, UK.

Springer-Verlag.

Lugou, F., Li, L. W., Apvrille, L., and Ameur-Boulifa, R.

(2016). SysML Models and Model Transformation for

Security. In Confer

ence on Model-Driven Engineer-

ing and Software Development (Modelsward’2016),

Rome, Italy.

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.

Pedroza, G., Knorreck, D., and Apvrille, L. (2011).

AVATAR: A SysML Environment for the Formal Veri-

ﬁcation of Safety and Security Properties. In The 11th

IEEE Conference on Distributed Systems and New

Technologies (NOTERE’2011), Paris, France.

Rodday, N. (2016). Hacking a Professional Drone. Slides

at www.blackhat.com/docs/asia-16/materials/asia-16-

Rodday-Hacking-A-Professional-Drone.pdf.

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.

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.

Smyth, B., Ryan, M. D., and Chen, L. (2015). Formal

analysis of privacy in Direct Anonymous Attestation

schemes. Science of Computer Programming, 111(2).

Tanzi, T. J., Sebastien, O., and Rizza, C. (2015). Designing

Autonomous Crawling Equipment to Detect Personal

Connected Devices and Support Rescue Operations:

Technical and Societal Concerns. The Radio Science

Bulletin, 355(355):35–44.

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.

Security-aware Modeling and Analysis for HW/SW Partitioning

311