Verifying Data Secure Flow in AUTOSAR Models by Static Analysis

Cinzia Bernardeschi

, Marco Di Natale

, Gianluca Dini

and Maurizio Palmieri

Department of Information Engineering, University of Pisa, Largo L. Lazzarino 1, Pisa, Italy

Scuola Superiore Sant’Anna, Piazza Martiri della Libert

a 33, Pisa, Italy

Keywords:

AUTOSAR, Security, Information Flow, Static Analysis.

Abstract:

This paper presents a method to check data secure ﬂow in security annotated AUTOSAR models. The ap-

proach is based on information ﬂow analysis and abstract interpretation. The analysis computes the lowest

security level of data sent on a communication, according to the annotations in the model and the code of

runnables. An abstract interpreter executes runnables on abstract domains that abstract from real values and

consider only data dependency levels. Data secure ﬂow is veriﬁed if data sent on a communication always

satisfy the security annotation in the model. The work has been developed in the EU project Safure, where

modeling extensions to AUTOSAR have been proposed to improve security in automotive communications.

1 INTRODUCTION

Modern automotive electronics systems are real-time

embedded system running over networked Electronic

Control Units (ECU) interconnected by wired net-

works such as the Controller AreaNetwork (CAN) or

Ethernet. Moreover, wireless connectivity is increas-

ingly used for additional exibility and bandwidth for

features like keyless entry, diagnostic, and entertain-

ment.

Recent research has shown that it is possible for

external intruders to intentionally compromise the

proper operation and functionality of these systems.

Koscher et al. demonstrated that if an adversary were

able to communicate on one or more of a car in-

ternal network buses, then this capability could be

sufﬁcient to maliciously control critical components

across the entire car (including dangerous behavior

such as forcibly engaging or disengaging individual

brakes independent of driver input) (Koscher et al.,

2010). These results raise the question of whether and

how an adversary might be able to access a car inter-

nal bus (and thus compromise its ECUs) in the case

of absent direct physical access. Checkoway et al.

demonstrated that external attacks are indeed feasi-

ble (Checkoway et al., 2011) and categorized external

attack vectors as a function of the attacker ability to

deliver malicious input via particular modalities: indi-

rect physical access, shortrange wireless access, and

long-range wireless access. Charlie Miller and Chris

Valasek have recently demonstrated further remote at-

tacks (Wyglinski et al., 2013).

Recently, many research and industrial activities

have started to take security into account in the early

phases of the development cycle of automotive elec-

tronics systems, both by enforcing software program-

ming standards that prevent software defects that may

enable cyber-attacks (Checkoway et al., 2011), as

well as by implementing security mechanisms for se-

cure communication (Lemke et al., 2006) including

software delivery, installation and ﬂashing (Adels-

bach et al., 2006)(Stephan et al., 2006).

The AUTomotive Open System ARchitecture

(AUTOSAR) standard is the standard for the model-

ing and development of software components in the

automotive industry (AUTOSAR, a). In AUTOSAR,

safety and security services are being standardised

with respect to the set of basic services that may be

required by the application, such as the basic cryp-

tographic functionalities provided by the Crypto Ser-

vice Manager (CSM) or the deﬁnition of integrity-

related message authentication codes (MACs) in mes-

sages (SecOC component). These modules are not

currently matched by corresponding models for secu-

rity at the application level.

The work (Bernardeschi et al., 2016) aims at

bridging this gap. A set of modelling extensions to ad-

dress cybersecurity requirements at modelling stage

in AUTOSAR have been deﬁned, and a code genera-

tion tool has been developed that automatically syn-

thesizes the right services to use to achieve the se-

curity level speciﬁed by the developers. Security re-

704

Bernardeschi, C., Natale, M., Dini, G. and Palmieri, M.

Verifying Data Secure Flow in AUTOSAR Models by Static Analysis.

DOI: 10.5220/0006288707040713

In Proceedings of the 3rd International Conference on Information Systems Security and Privacy (ICISSP 2017), pages 704-713

ISBN: 978-989-758-209-7

quirements are assigned to system components and

in-vehicle communication links between components,

and they are realized as stereotypes extending the AU-

TOSAR implementation provided by the IBM Rhap-

sody tool.

However, the way in which security annotations

can be speciﬁed, does not consider the problem of

dependencies between data that traverse components

and communication links in the AUTOSAR model.

For example, if integrity is requested for input data to

the Brake actuation sub-system, all the communica-

tion links traversed from the sensors originating the

data to the Brake sub-system must be protected. Oth-

erwise, the security constraint cannot be satisﬁed. We

introduce the concept of data secure ﬂow. Data secure

ﬂow is veriﬁed if, for every possible execution, data

sent on a communication always satisfy the security

annotation written in the model.

Dependencies between data in an AUTOSAR

model, can be studied using approaches for checking

secure information ﬂow in programs (D. E. Denning,

1977). In particular, we use an approach based on

abstract interpretation (Cousot and Cousot., 1992), a

static analysis technique for the automatic extraction

of information about the possible executions of com-

puter programs. Abstract interpretation has been used

in (Barbuti et al., 2002) to analyse secure information

ﬂow in a simple imperative language. We extend the

technique to cover the analysis of AUTOSAR models.

The main points of the approach are:

• an abstract interpreter executes the functional

units of software components on abstract domains

that abstract from real values and consider only

data dependency levels. A ﬁxpoint iterative anal-

ysis computes the dependency between data writ-

ten/read at ports of the software components.

• since the analysis computes all possible depen-

dencies for any real execution of the functional

units, the lowest security level of data sent on a

communication is counted.

• data secure ﬂow property is satisﬁed if the security

level computed by the analysis for data sent on a

communication always satisfy the security anno-

tations in the model.

We reduce the complexity of the analysis by

using static program analysis techniques (Nielson

et al., 2005), which analyse the source code with-

out executing the program. Static analysis techniques

are applied for enforcing information ﬂow security

in programs in several works, the reader can refer

to (Sabelfeld and Mayers, 2003) for a survey. One of

the advantages of our approach is that, being based

on abstract intepretation, the analysis can be fully

Figure 1: AUTOSAR architecture.

automated. Moreover, the analysis scales up, since

AUTOSAR software components are analysed sepa-

rately.

The paper is organized as follows: Section 2

brieﬂy introduces AUTOSAR and security annotated

AUTOSAR models. Section 3 outlines the data se-

cure ﬂow problem addressed by this work. Section 4

introduces the problem of dependency between data

read/written at ports of software components in an

AUTOSAR model. Section 5 presents the secure ﬂow

veriﬁcation technique by assuming data dependencies

already determined. The method used for computing

data dependencies at the ports is shown in Section 6.

Section 7 concludes the paper.

2 AUTOSAR

AUTOSAR (AUTOSAR, a) is an open industry stan-

dard for automotive software architecture, founded in

2003 and developed by a partnership of automotive

Original Equipment Manufacturers (OEMs), suppli-

ers and tool vendors. AUTOSAR provides a standard

language for the description of application compo-

nents and their interfaces; and a methodology for the

development process.

A fundamental concept in AUTOSAR is the sep-

aration between application and infrastructure, see

Figure 1. In particular, AUTOSAR deﬁnes a three-

layered architecture consisting of:

• Application layer

• Runtime Environment (RTE) layer

• Basic Software (BSW) layer

The application layer contains the Software Com-

ponents (SWCs) developed for the automotive sys-

tem functions by suppliers. The RTE layer is a mid-

dleware layer, automatically generated by tools and

providing a communication abstraction for software

components. Finally, the BSW provides basic ser-

vices and basic software modules to software com-

ponents.

Verifying Data Secure Flow in AUTOSAR Models by Static Analysis

705

Figure 2: An example of AUTOSAR application model.

The application SWCs communicate using ports

that express client-server relationships (in this case

the port is typed by an operation interface) or send-

receive data interactions (in this case the port is typed

by a data interface consisting of a set of typed data

items). The development of the SWCs is based on

the Virtual Functional Bus (VFB) speciﬁed by AU-

TOSAR to deliver the conceptual foundation for the

communication of SWCs with each other and the use

of BSW services.

The internal behavior of SWCs consists of

runnables or functional units, represented by a func-

tion entry point. Each runnable indicates the port it

uses. Internally, the runnable code accesses the ports

through a set of standard API for port communication

and port service request (denoted as RTE services).

A set of events triggering the execution of runnables

completes the set of the main modeling entities. A

runnable can be triggered by a timing event, by a data

send event, a data receive event or by the invocation

of a server call at the server port.

An example is shown in Figure 2. Runnable

r11 of SWC1 communicates with runnable r22 of

SWC2 through sender-receiver ports; Runnable r12

of SWC1 communicates with with runnable r21 of

SWC2 through client-server ports. Moreover, r21 is

triggered by the invocation of the service at the server

port.

AUTOSAR allows software components to be de-

veloped independently of the underlying hardware,

which means that they are transferable and reusable.

2.1 Security Annotated Autosar Models

In (Bernardeschi et al., 2016), AUTOSAR models are

extended with security annotations. Two modelling

extensions are introduced:

• the trust level of a software component

• the security requirement of a communication link

A software component may be associated to a trust

level which speciﬁes to what extent the element can

be trusted to provide the expected function, or service

with respect to attacks targeted to compromise the

functionality of the element. Without loss of gener-

ality, we assume two trust levels: high and low. Soft-

ware components with high trust level are executed

on secure and reliable hardware.

To protect in-vehicle communications from cyber

threats such as eavesdropping, integrity and spooﬁng,

a communication link may be associated to a security

requirement which represents the level of security that

data sent on the link must satisfy. The proposed secu-

rity extensions are conﬁdentiality and integrity of the

exchanged information.

The security requirement can assume one of the

following values: none, conf, integr, both. These four

values codify no security, conﬁdentiality, integrity

and, both conﬁdentiality and integrity, respectively.

Figure 3 shows an example of AUTOSAR anno-

tated model. The example represents an application

in which data collected by sensors (lidars, radars and

cameras), together with the position information com-

ing from the GPS system, are used to detect road-

markings and objects (pedestrian, vehicles) on the

road. Path Planning, Lane Keeping and Lane Depar-

ture Warning are active safety functions that receive

such data and send commands to actuators (steering,

throttle and brakes).

For semplicity, we assume that 1) Throttle and

PathPlanning software components are assigned high

trust level; 2) the other components are assigned low.

Moreover, we assume that 1) Throttle request link is

annotated with data integrity security requirement; 2)

the other comminication links have no security re-

quirements.

Finally, we assume send/receive data communi-

cations between components. Moreover, in the ﬁg-

ure, dependencies between data read/writen at ports

of PathPlanning are shown as dotted lines internal to

the component.

3 PROBLEM STATEMENT: DATA

SECURE FLOW PROPERTY

We introduce the following deﬁnitions:

• Data Security. Every data is assigned a pair

htrust level,security requirementi that

characterises its degree of security. As data ﬂow

through the components and the communication

links, its data security is updated.

• Data Secure Flow Property. When the system is

in operation, data security of data sent on a link

must have no lower trust level than the level of the

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

706

Figure 3: An example of security annotated model.

receiver component and no lower security require-

ment than the requirement of the link, both ﬁxed

at design time through the security annotations in

the AUTOSAR model.

With reference to Figure 3, the trust level of data

received by Throttle component must be high. Throt-

tle receives data directly by PathPlanning, a high trust

level component, which in turn, receives data GPS,

which has a low trust level. Therefore Data se-

cure ﬂow is violated. Assume GPS has a high trust

level. Data sent on Throttle request link must sat-

isfy integrity requirement. The dependency between

data read/written at ports in PathPlanning, makes the

property false, because such data depends on Vehi-

cle position link, which does not have any security

requirement.

The problem is that security annotations are local

to single components and links, and the data secure

ﬂow property may or may not be satisﬁed due to data

dependencies in the model.

What we propose is a static analysis approach to

check data secure ﬂow property in security annotated

models. For the analysis, we deﬁne an ordering be-

tween security values with the meaning that if secu-

rity value s preceedes security value s

, then s is in

some way ”lower in security degree” to s

Fundamentals to the analysis are the structure of

the system model (components, runnables, ports and

links), the ordering relation mentioned above, and the

dependencies between data in the model.

4 DATA DEPENDENCIES IN AN

AUTOSAR MODEL

The basic idea is modelling ports as variables, and

modelling runnables as functions in the programming

language. In particular,

• for send-receive data communications, reading a

data at a port is equivalent to reading the variable;

writing a data at a port is equivalent to writing the

variable.

• for client-server communications, the client re-

quest is equivalent to a function call, that corre-

sponds to the invocation of the runnable imple-

menting the requested service.

• for updates of variables that trigger the execu-

tion of runnables, the write of the variables cor-

responds to the invocation of the functions imple-

menting the runnables. If a variable corresponds

to a port of a send/receive data communication, a

write of the variable may trigger a runnable local

to the sender SWC or a runnable at the receiver

SWC.

The analysis we present is based on abstract inter-

pretation technique (Cousot and Cousot., 1992):

• the standard operational semantics of the pro-

gramming language is enhanced to include infor-

mation useful in the analysis.

• abstract domains are identiﬁed and abstract se-

mantics rules are deﬁned that execute the program

on abstract domanins.

• the abstract rules compute the ﬂow of information

in the program

Verifying Data Secure Flow in AUTOSAR Models by Static Analysis

707

The rules take into account explicit and implicit

ﬂow of information. Let v

and v

p j

be variables cor-

respondent to p

and p

ports.

An example of explicit information ﬂow is:

x := v

; v

p j

:= x + 3;

An example of implicit information ﬂow is:

if (v

== −1) then v

p j

:= 0 else v

p j

:= 1

In both the examples above, the value of variable v

p j

depends on the value of variable v

. Data written to

port p

depends on data read at port p

For functions, information ﬂows through function

parameters and return. An example of explicit infor-

mation ﬂow is:

x := v

; f (x);

The call to a function without parameters and re-

turn, can be the cause of an information ﬂow, in case

of implicit ﬂow:

if (v

== −1) then f ();

Function f is invoked depending on the value read at

port p

5 DATA SECURE FLOW

PROPERTY VERIFICATION

Given an AUTOSAR model, we use the following no-

tations and deﬁnitions:

• C = {c

,··· ,c

} is the set of SWCs.

• P = {p

,··· , p

} is the set of ports of the SWCs.

• L = {l

,··· ,l

} is the set of links. A link de-

notes a connection between two ports. The link

l = (p

, p

) connects the port p

to the port p

with p

output port of the sender SWC and p

in-

put port of the receiver SWC.

• trustlevel(c) is the trust level assigned to the

software component c.

• securityrequirement(l) is the security require-

ment assigned to link l.

In addition we use the following deﬁnitions and

functions:

• Given a port p, cmp(p) is the component to which

the port belongs.

• Given a port p, Deps(p) is the set of ports on

which the data written at port p depends (see sec-

tion 6).

Figure 4: Order relation on (a) trust levels (b) security re-

quirements.

Given a link l = (p

, p

) ∈ L,

1. hδ

,µ

i = hhigh, bothi

2. ∀p ∈ Deps(p

)

= glb(δ

,trustlevel(cmp(p)))

3. ∀l

= (q,q

),| q,q

∈ Deps(p)

= glb(µ

,securityrequirement(l

))

Figure 5: Algorthm for data security of link l.

Deﬁnition 1 (Trust Level). Let A = {low,high} be

the set of trust levels, ordered by low @ high, where

@ is the lower between levels, see Figure 4 (a). Let glb

denote the greatest lower bound, and lub the least up-

per bound between levels: it is glb(low, high) = low

and lub(low,high) = high.

Deﬁnition 2 (Security Requirement). Let B =

{con f ,integr,both,none} be the set of security re-

quirements of links, partially ordered by @, as shown

in Figure 4 (b). Let glb denote the greatest lower

bound, and lub the least upper bound between lev-

els. (B,@) is a lattice (i.e., every pair of elements of

B has both a greatest lower bound and a least up-

per bound). For example, glb(integr,con f ) = none;

lub(integr,con f ) = both

Note that conf and integr are not ordered, because

one is not ”lower in security degree” to the other.

5.1 The Method

In the analysis, we compute the lowest trust level and

the lowest security requirement of data sent on a link l

(htrust level,security requirementi), with the

algorithm shown in Figure 5. The algorithm records

in δ

and µ

such levels (hδ

,µ

i).

Assume l = (p

, p

). Data sent on the link l are

data written at port p

First the algorithm sets δ

equal to the greatest

trust level and µ

equal to the greatest security require-

ment. Then for each port p on which data sent on the

link l depends (p ∈ Deps(p

)) , δ

is updated to con-

sider the trust level of the SWC to which the port p

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

708

belongs: the trust level δ

is set equal to the greatest

lower bound between the currrent value and the trust

level of the SWC to which port p belongs. Finally,

for each link l

in the model traversed by data sent

on link l (source and destination ports of l

belong to

Deps(p

)), µ

is updated: the security requirement µ

is set equal to the greatest lower bound between the

currrent value and the security requirement of the link

. Note that, at each step δ

can only be downgraded;

analogously, µ

can only be downgraded.

An AUTOSAR model satisﬁes data secure ﬂow if

for each communication link, 1) the trust level of des-

tination component of the link is not greater than the

trust lowest trust level of data sent on the link, and 2)

the security requirement of the communication link

is not greater than the lowest security requirement of

data sent on the link.

Deﬁnition 3 (Data Secure Flow Property). Given

an AUTOSAR model with security annotations, the

model satisﬁes the data secure ﬂow property if, for

each link l = (p

, p

) ∈ L, with hδ

,µ

i the data secu-

rity of data sent at l:

trustlevel(cmp(p

)) v δ

∧ securityrequirement(l) v µ

6 DEPENDENCIES BETWEEN

PORTS OF AN AUTOSAR

MODEL

A port p

does not depend on port p

if data sent at p

are independent from data received at p

. We formally

deﬁne port dependencies as follows.

Deﬁnition 4 (Port Dependencies). Let us consider

an AUTOSAR model. A port p

does not depend on

the port p

if: for each pair of values v

at p

with v

6= v

, it is: p

,··· , p

i−1

, p

i+1

,··· , p

) =

,··· , p

i−1

, p

i+1

,··· , p

) for each possible ex-

ecution, where p

,··· , p

i−1

,x, p

i+1

,··· , p

) is the

value written on port p

when x is read from input

port p

In the analysis, we deﬁne an AUTOSAR model as

a tuple A = (R,Var,C, Θ), that consists of a set R of

runnables, a set Var of variables, a set C of connec-

tions (links), a set Θ of levels. In particular

• Var = V P ∪ V IR ∪ V G is a set that consists of

the set V P of port variables, the set V IR of inter-

runnable variables, and the set V G of global vari-

ables of SWCs.

• R is the set of all runnables. A runnable r ∈ R is a

function r : Var → Var.

• C = {(src,dst) | src ⊆ V P ∧ dst ⊆ V P} is a set

of connections between port variables (src is the

source and dst is the destination port of the con-

nection).

• Θ = {θ

,··· ,θ

} is the set of levels, one level for

each port. The level of port p

is called θ

6.1 Data Dependency Levels

We assume the following set Θ = {θ

,θ

,··· ,θ

} of

dependency levels, one for each port. We consider

the powerset Σ = 2

, i.e. the set of all subset of Θ, or-

dered by subset inclusion. (Σ,⊆) is a complete lattice

(every pair of elements of Σ has both a greatest lower

bound, glb, and a least upper bound, lub). The lub

is given by the union (∪) and the glb is given by the

intersection of subsets (∩). Given X ⊆ Y , X ∪Y = Y

and X ∩ Y = X . The analysis operates over levels in

Σ. The singleton set {θ

} denotes a dependency from

input port p

. The set {θ

,θ

} denotes dependency on

both input ports p

and p

. The minimum of Σ is the

empty set.

6.2 Analysis of a Runnable

In the following we describe the basic concepts of the

analysis.

A program is a sequence q of commands. Let m

be a memory that contains all the variables accessed

by the program.

The execution of a program is a transition system

obtained by executing q starting from the initial mem-

ory, by applying the rules of the operational semantics

of the language. As an example, the rule for a simple

expression consisting of variable x is:

Expr

var

hx,mi −→

expr

m(x)

The semantics of the exptression x is the value of

x in memory m.

The rule for the assignment x := e is the follow-

ing, where e is an expression, and m[k/x] the memory

m, where the variable x is assigned the new value k:

Ass

he,mi −→

expr

hx:=e,mi −→ m[k/x]

If k is the evaluation of the expression e in mem-

ory m, the semantics of x:=e changes the memory by

assigning value k to variable x.

The operational semantics of the language is ex-

tended to convey the set of data dependency levels

during the execution.

• Each value is annotated with the set of dependen-

cies (both implicit and explicit);

Verifying Data Secure Flow in AUTOSAR Models by Static Analysis

709

Data become pairs (k,τ), where k is the value and

τ is the dependency level.

• and each command is executed under an environ-

ment σ that represents the lub of the dependencies

of the open implicit ﬂows.

The notation (x:=e)

, represents the execution of

the assignment under an environment σ.

For example, the dependencies of a variable ex-

pression, is given by le lub between the level of the

data in the variable and the level of the environment

in which the command is executed.

The previously introduced rules become the fol-

lowing, where M is the memory deﬁned on extended

values:

Expr

var

M(x) = (k,τ)

,Mi −→

expr

(k, σ t τ)

Ass

,Mi −→

expr

h(x:=e)

,Mi −→ M[v/x]

The abstract semantics, abstracts from actual val-

ues and maintains only annotations on data dependen-

cies. let M

]

be the abstract memory. The abstract se-

mantics for the previous rules is following:

Expr

var

]

(x) = τ

]

i −→

expr

lub(σ,τ)

Ass

]

i −→

expr

τ,σ

= lub(σ,τ)

h(x:=e)

]

i −→ M[σ

/x]

A program is executed on the abstract domain

starting from the abstract initial memory, and apply-

ing the abstract rules. We note that all branches of

conditional/iterative instructions are always executed,

due to the loss of real data in the abstract semantics.

In previous work (Barbuti et al., 2002), it is proved

that the transition system built by executing q with

the enhanced semantics is the same as the transition

system built with the standard semantics, for a simple

high level language. We extended the semantics rules

to include indirections, structures, arrays and function

calls (we assume Misra-C as programming language

of runnables (AUTOSAR, b)).

In particular, to deal with shared memory and

functions calls, a context ﬁle is introduced (similarly

to the approach in (Avvenuti et al., 2012)).

Variables are scalar in the following. For struc-

tures, a variable is used for each ﬁeld. For arrays, we

abstract from array indexes.

6.3 Context File

A context ﬁle is deﬁned to record information stored

in the shared memory of a SWC and information

about runnable calls.

The context ﬁle maintains:

• for each variable v ∈ Var, the entry v : σ, where σ

is the dependency level of data assigned to v;

• for each runnable r ∈ R, the entry

r(σ

,...,σ

)σ;σ

, where σ

,...,σ

are the

levels for the actual parameter, σ is the level

for the result and σ

is the level of the calling

environment.

In particular, during the analysis, for each vari-

able, the context ﬁle maintains the maximum depen-

dency level of data recorded in the variable.

For each runnable, the context ﬁle maintains how

the runnable is called in terms of the maximum level

of the calling environment, the actual parameters

and return. We assume parameters and return of

runnables, for generality.

Each port variable is initialised to the level of the

port. All other variables are initially assigned the low-

est level (

0). Runnables are initially assigned the low-

est level for calling environment, parameters and re-

turn.

Entries in the context ﬁle are manged in a special

way. Their dependency level never decreases. An as-

sigment to a variable in the context ﬁle, updates the

dependency level of the variable in the context ﬁle to

the lub between its current level and the level of the

assigned expression. Analogously, for runnable en-

tries.

Example. In the following, we will consider one

software component of a simple example of an AU-

TOSAR application (MathWorks, a). The software

component manages three runnable entities, 2 input

ports, 4 output ports and 4 inter-runnable variables

(irv1, irv2, irv3, irv4). Runnable 1 performs the sum

of the value read from the input port in1 and the value

from irv3 and writes the result in irv1; runnable 2 per-

forms the subtraction between irv1 and irv2, accumu-

lates the result and writes it on irv4 and on the out-

put port 4; ﬁnally Runnable 3 multiplies irv4 and the

value read from input port in2 and writes the result in

irv2. The data sent to the other output ports (1, 2 and

3) and in irv3 oscillate between 1 and -1 and is not

related to the other elements of the component.

The code of runnable r1 in the example is shown

in Figure 7.

For simplicity, we use in1, in2, and out1, out2,

out3, out4 as names of input/output port variables.

For example, RPort DE1 is called in1 and PPort DE1

is called out1.

A runnable is abstractly executed starting from its

local memory and the context ﬁle. The initial context

ﬁle and the local memories for the software compo-

nent are shown in Table 1.

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

710

Figure 6: A software component and its runnables.

FUNC(void) Run1(void) {

int8_T Delay_n;

Delay_n = rtDWork.Delay_DSTATE_a;

if(((int32_T)Rte_IStatus_Run1_RPort_DE1())==0)

{

rtB.Add = Rte_IRead_Run1_RPort_DE1()+

((real_T) Rte_IrvIRead_Run1_IRV3());

}

Rte_IrvIWrite_Run1_IRV1(rtB.Add); (*)

rtDWork.Delay_DSTATE_a = (int8_T)((int32_T)

(-((int32_T)rtDWork.Delay_DSTATE_a)));

Rte_IWrite_Run1_PPort_DE1(Delay_n);

}

Figure 7: Code of runnable r1.

6.4 Calls to RTE Functions

We deal with calls to RTE functions in the runnable

code as follows.

• Send/Receive data communication ports

RTE function for writing/reading a port are

mapped to read/write of the corresponding vari-

able:

Rte IRead Run1 RPort DE1() is mapped to the

read of variable RPort DE1

Rte IWrite Run1 PPor DE1(Delay n) is

mapped to the write of variable of the port:

PPort DE1 := Delay n.

• Updates of variables that trigger runnables

The calling environment of the triggered runnable

is updated in the context ﬁle. The runnable is ex-

ecuted into an environment which depends on the

level of the variable.

• Client/server ports

RTE function for client/server communication

This function trigger the runnable that implements

the service. The calling environment of the trig-

gered runnable is updated in the context ﬁle. The

runnable implementing the service is executed

into an environment which depends on the level

of the environment of the caller.

F := F

,T := R

while(T 6=

select r ∈ T

T := T − {r}

:= EXEC(r,F)

if(F

6= F)

F := F

T := R

Figure 8: Analysis of an AUTOSAR model.

6.5 Analysis of an AUTOSAR Model

The analysis of an AUTOSAR model is based on an

iterative process that performs the abstract execution

of all runnables in R, using an abstract context ﬁle. In

the initial abstract context, the level of each port vari-

able is ﬁxed to the level of the port, and the level of

every other variable is set to

0. If during the analysis

a level in the context ﬁle changes, all runnables must

be re-executed.

The analysis uses an abstract interpreter, named

EXEC, that analyses a single runnable. EXEC per-

forms an abstract execution of the runnable starting

from a context ﬁle F and producing a newcontext ﬁle

. The state of a runnable is a tuple hσ,q,F,M

]

where q is the code of the runnable, F is the abstract

context ﬁle and M

]

is the abstract memory and σ is

the environment.

The analysis terminates when, starting from a con-

text ﬁle, all runnables are executed and the context is

not changed.

The main steps of the iterative analysis are shown

in Figure 8, where F

is the initial context.

A the end of the analysis, the context ﬁle records

the dependencies for ports of all the software com-

ponents. The approach is conservative, in the sense

that all possible dependencies for any real execution

of the runnables are detected. False dependencies are

possible, since in the abstract analysis all branches of

control instructions are executed, even those that in

real execution would have never been executed.

Example In the following, we report results of the

application of the method to the example.

The analysis starts from Table 1, that reports the

inital context ﬁle and local memories of runnables.

Let us consider the abstract execution of runnable

1. The if instruction causes the beginning of an im-

plicit ﬂow. According to the semantics rules, instruc-

tions in both branches of an if are executed under an

environment set to the level of the condition of the

if. On entering the if instruction, the environment

is upgraded to the level of the variable (RPort

DE1).

The implicit ﬂow terminates at instruction (*), which

is the ﬁrst instruction out of the scope of the if. At

Verifying Data Secure Flow in AUTOSAR Models by Static Analysis

711

this point, the environment is downgraded to the level

before the execution of the conditional instruction.

Table 2 reports the state of the memory at the end

of the analysis of the three runnables.

Table 1: Initial context ﬁle and local memories.

Variables Dependencies

Context ﬁle

in1 { in1 }

in2 { in2 }

rtb.Add

rtdWork.Delay DSTATE a

rtdWork.Delay DSTATE m

rtdWork.Delay DSTATE

rtdWork.Integrator DSTATE

irv1

irv2

irv3

irv4

out1 { out1 }

out2 { out2 }

out3 { out3 }

out4 { out4 }

Runnable R1

Delay n

Runnable R2

Delay

SubtracterBuffer

Runnable R3

tmp

*tmp

OutputBuffer

With our static analysis we can assert that the out-

put port out4, irv2 and irv4 depend on both the input

ports, meanwhile the irv1 only depends on input port

in1. With a simple approach where all output vari-

ables of a runnable depends on all its input variables

irv1 would depend on input port i2 too.

7 CONCLUSIONS

Security in automotive is becoming increasingly im-

portant and should be taken into account from the

early stages of the system design.

In this paper we present a methodology for the

veriﬁcation of data secure ﬂow in security annotated

AUTOSAR models.

The method we present is based on information

ﬂow analysis and abstract interpretation. The analy-

sis computes the lowest security level of data sent on

a communication, according to the annotations in the

Table 2: Final context ﬁle and local memories.

Variables Dependencies

Context ﬁle

in1 { in1 }

in2 { in2 }

rtb.Add { in1 }

rtdWork.Delay DSTATE a

rtdWork.Delay DSTATE m

rtdWork.Delay DSTATE

rtdWork.Integrator DSTATE { in1, in2 }

irv1 { in1 }

irv2 { in1, in2 }

irv3

irv4 { in1, in2 }

out1 { out1 }

out2 { out2 }

out3 { out3 }

out4 { out4, in1, in2 }

Runnable R1

Delay n

Runnable R2

Delay

SubtracterBuffer { in1, in2 }

Runnable R3

tmp { in2 }

*tmp { in2 }

OutputBuffer

model and the code of runnables. In particular, our

approach for data ﬂow analysis can be put at an inter-

mediate level between a syntactic approach (Volpano

et al., 1992; Bernardeschi et al., 2004) and a fully se-

mantic one (Leino and Joshi., 1998). The approach

is dynamic and thus allows us to be more permissive

than a syntactic approach. Moreover, the approach is

based on a transition system and thus has the advan-

tage of being fully automatic.

On a security annotated AUTOSAR model, secu-

rity properties can be speciﬁed and formally proved.

Moreover, the possibility of automatically generate

security components reduces errors in the develop-

ment phase.

ACKNOWLEDGEMENTS

This work has been developed under the framework

of the European project SAFURE (Safety And Se-

curity By Design For Interconnected Mixed-Critical

Cyber-Physical Systems) under grant agreement No

644080. Moreover, the research has been supported

in part by the PRA 2016 project entitled Analysis

ForSE 2017 - 1st International Workshop on FORmal methods for Security Engineering

712

of Sensory Data: from Traditional Sensors to Social

Sensors, funded by the University of Pisa.

REFERENCES

Adelsbach, A., Huber, U., and Sadeghi, A.-R. (2006). Se-

cure software delivery and installation in embedded

systems. In Embedded Security in Cars, pages 27–49.

Springer.

AUTOSAR (a). http://www.autosar.org.

AUTOSAR (b). https://www.autosar.org/ﬁleadmin/ﬁles/

releases/2-0/software-architecture/rte/standard/

autosar sws rte.pdf.

Avvenuti, M., Bernardeschi, C., De Francesco, N., and

Masci, P. (2012). Jcsi: A tool for checking secure

information ﬂow in java card applications. Journal of

Systems and Software, 85(11):24792493.

Barbuti, R., Bernardeschi, C., and De Francesco, N.

(2002). Abstract interpretation of operational seman-

tics for secure information ﬂow. Inf. Process. Lett.,

83(2):101–108.

Bernardeschi, C., De Francesco, N., Lettieri, G., and Mar-

tini, L. (2004). Checking secure information ﬂow in

java bytecode by code transformation and standard

bytecode veriﬁcation. Software - Practice and Expe-

rience, 34(13):1225–1255.

Bernardeschi, C., Del Vigna, G., Di Natale, M., Dini,

G., and Varano, D. (2016). Using AUTOSAR High-

Level Speciﬁcations for the Synthesis of Security

Components in Automotive Systems, pages 101–117.

Springer International Publishing, Cham.

Checkoway, S., McCoy, D., Kantor, B., Anderson, D.,

Shacham, H., Savage, S., Koscher, K., Czeskis, A.,

Roesner, F., Kohno, T., et al. (2011). Comprehensive

experimental analyses of automotive attack surfaces.

In USENIX Security Symposium. San Francisco.

Cousot, P. and Cousot., R. (1992). Abstract interpreta-

tion frameworks. Journal of Logic and Computation,

4(2):511–547.

D. E. Denning, P. J. D. (1977). Certiﬁcation of programs

for secure information ﬂow. Communications of the

ACM, 7(20):504–513.

Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno,

T., Checkoway, S., McCoy, D., Kantor, B., Anderson,

D., Shacham, H., et al. (2010). Experimental security

analysis of a modern automobile. In Security and Pri-

vacy (SP), 2010 IEEE Symposium on, pages 447–462.

IEEE.

Leino, K. and Joshi., R. (1998). A semantic approach to se-

cure information ﬂow. In Proc. 4th International Con-

ference, Mathematics of Program Construction, LNCS

1422, pages 254–271. Springer Verlag.

Lemke, K., Paar, C., and Wolf, M. (2006). Embedded secu-

rity in cars. Springer.

MathWorks (a). Generate autosar-compliant

code for multiple runnable entities

(https://it.mathworks.com/help/ecoder/examples/

autosar-code-generation-for-multiple-runnable-

entities.html).

Nielson, F., Nielson, H. R., and Hankin, C. (2005). Princi-

ples of Program Analysis. Springer.

Sabelfeld, A. and Mayers, A. (2003). Language-based

information-ﬂow security. IEEE journal on selected

areas in communications, 21(1).

Stephan, W., Richter, S., and Muller, M. (2006). Aspects of

secure vehicle software ﬂashing. In Embedded Secu-

rity in Cars, pages 17–26. Springer.

Volpano, D., Smith, G., and Irvine, C. (1992). A sound type

system for secure ﬂow analysis. Journal of Computer

Security, 4(3):167–187.

Wyglinski, A. M., Huang, X., Padir, T., Lai, L., Eisenbarth,

T. R., and Venkatasubramanian, K. (2013). Security of

autonomous systems employing embedded computing

and sensors. Micro, IEEE, 33(1):80–86.

Verifying Data Secure Flow in AUTOSAR Models by Static Analysis

713