HIGHER LAYER AUTHENTICATION FOR BROADCAST IN

CONTROLLER AREA NETWORKS

Bogdan Groza and Pal-Stefan Murvay

Faculty of Automatics and Computers, Politehnica University of Timisoara, Bd. V. Parvan, Timisoara, Romania

Keywords:

Authentication, Broadcast, Controller area network.

Abstract:

Controller Area Network (CAN) is a bus commonly used by controllers. The traditional view assumes that

controllers operate in secure perimeters, but, as the degree of interconnectivity with the outside world in-

creases, these networks may become open to intruders and CAN has no protection against Dolev-Yao ad-

versaries. For this purpose one can implement security on higher layers. Here we design and implement a

broadcast authentication protocol based on the well known paradigm of using one-way chains and time syn-

chronization. In this way we can beneﬁt from the use of symmetric primitives without the need of secret shared

keys. As process control is a time critical operation, different to sensor networks where the life-time of the

node is potentially the main limitation, here the authentication delay is the main optimization criteria. Several

trade-offs are studied for this purpose in order to alleviate shortcomings on computational speed, memory,

bandwidth and to assure a uniform bus-load. As for the experimental setup, we used S12 microcontrollers

from Freescale to implement the proposed solution. To speed up cryptographic operations we also make use

of the XGATE co-processor available on S12X.

1 INTRODUCTION AND

RELATED WORK

Controller Area Network or simply CAN is a commu-

nication bus initially developed by BOSCH to be used

by controller units in vehicular systems (BOSCH,

1991). The initial speciﬁcations are now superseded

by the newer standard (ISO, 2003) while its area of

application also extended outside vehicles to automa-

tion applications in general. Although high perfor-

mance buses were developed in the last decade, such

as FlexRay, because of its efﬁciency and reduced cost

CAN is still the most commonly used communication

bus in automotives today.

Traditionally, in control systems in general and in

automotives in particular, reliability was a main con-

cern but only with respect to natural phenomenons

(electromagnetic disturbances, thermal noise, etc.) or

accidents of various causes but not in front of Dolev-

Yao adversaries. Thus CAN has very efﬁcient mech-

anisms to deal with errors and to recover afterwards.

In fact, the probability of an undetected error on CAN

is extremely low, informally one undetected error oc-

curs at about one thousand years for each vehicle that

operates eight hours a day with an error each 0.7s. For

the interested reader, an in-depth study of the perfor-

mance of CAN error detection mechanism was done

in (Charzinski, 1994).

However, in the last decade, industrial control sys-

tems and automotives become opened to malicious

adversaries as well, and a signiﬁcant part of the se-

curity community focused on this kind of issues. A

recent comprehensive book for security and in partic-

ular cryptographic security in automotives is (Lemke

et al., 2006) but a high amount of papers were pub-

lished since then.

In this context, of malicious adversaries that can

manipulate messages over the network, CAN does not

have intrinsic support for any kind of security. In-

deed, such kind of security is not needed if one sees

CAN as operating in a secure perimeter. But, it is

very likely that soon CAN-like networks will operate

in environments that are opened for intruders. Re-

cent research showed current automobiles to be unex-

pectedly vulnerable to external adversaries (Koscher

et al., 2010) and it is likely that many other environ-

ments in which CAN operates are not completely iso-

lated from the outside world. Security in front of

such adversaries can be achieved by implementing

this at the application level. In fact such improve-

ments happened in the past, for example when deter-

ministic delays were needed on the CAN bus with the

188

Groza B. and Murvay P..

HIGHER LAYER AUTHENTICATION FOR BROADCAST IN CONTROLLER AREA NETWORKS.

DOI: 10.5220/0003522201880197

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2011), pages 188-197

ISBN: 978-989-8425-71-3

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

development of Time Triggered CAN (ISO, 2004).

Still, to best of our knowledge there is no implemen-

tation available to assure authenticity in CAN net-

works. Thus, the main intention of this paper is to

develop a higher layer implementation and to study

several trade-offs to increase its efﬁciency. We an-

alyze this both at a theoretical level by introducing

the corresponding formalism and by designing an ef-

ﬁcient protocol and at a practical level by following

an efﬁcient implementation. This is done on S12X

microcontrollers from Freescale, a family of micro-

controllers frequently found in the automotive indus-

try, with the use of the XGATE co-processor available

on S12X derivatives to speed up cryptographic func-

tions.

As for the cryptographic mechanism that can be

employed for this purpose, public-key cryptography

is not the solution because of both the computational

and communication overhead. As messages are short

in CAN networks, usually ﬁtting in the 64 bits of

data carried by one CAN frame, using a public-key

primitive such as the RSA will require thousands of

bits and causes a signiﬁcant overhead. Elliptic curves

will signiﬁcantly reduce the size of the messages, but

still the computational overhead is too much to assure

small authentication delays. While the computational

overhead can be alleviated by dedicated circuits, such

as ASICs and FPGAs, this will largely increase the

cost of components, an issue that is largely avoided

by manufacturers.

In contrast, symmetric primitives were efﬁciently

employed for authentication in constrained environ-

ments such as sensor networks (Perrig et al., 2001b),

(Liu and Ning, 2003), (Liu and Ning, 2004). Due

to the broadcast nature of CAN, protocols similar to

the well known TESLA protocol (Perrig et al., 2000),

(Perrig et al., 2001a) can be used in this context as

well. There is an extensive bibliography related to

the TESLA protocol. Its history can be traced back

to Lamport’s scheme which uses one-way chains to

authenticate users over an insecure network (Lam-

port, 1981). The work of Bergadano et al. (Bergadano

et al., 2002) proposes several variants of one-way

chain based protocols, with or without time synchro-

nization. Previous work which inspired this family of

protocols is the Guy Fawkes protocol from (Anderson

et al., 1998). The context which is more related to our

setting here is that of the application of such protocols

in sensor networks. In particular, several trade-offs

for sensor networks were studied in (Liu and Ning,

2003), (Liu and Ning, 2004) and several variants of

the protocols are presented by Perrig as well in (Per-

rig et al., 2000), (Perrig et al., 2001a) .

In the case of the industrial controllers, some of

the constraints are similar. For example, computa-

tional power is also low and, although high speed mi-

crocontrollers are also available on the market, low

speed microcontrollers are preferred to reduce costs.

But while low computational power gives some sim-

ilarities, other constraints are different. For exam-

ple, energy consumption is a relevant issue in sen-

sor networks, but usually for control units inside a car

this is not a main concern since they do not strongly

rely on small batteries. On the other side, a differ-

ent constraint here, that is not so prevalent in sensor

networks, is the size of the message which is limited

to 64 bits on a CAN frame. Indeed, larger messages

can be split in smaller messages but the overhead in-

ﬂicted by the structure of the CAN frame is around

50%. This becomes prevalent in the case of one-way

chain based protocols, where hash-functions are used

to compute the chain elements and thus to send an el-

ement of the chain will require at least two exchanged

messages (assuming the simplest hash function out-

puts 128 bits). To this, one will need to add the mes-

sage authentication code as well, which again requires

at least two exchanged messages, etc. Thus, at least

four CAN frames are needed to transmit just the se-

curity elements of one frame with useful information.

Still, the most critical part, in automotivecommunica-

tion and control systems in general, where this proto-

col is mostly used, are the authentication delays, i.e.,

how fast a packet can be deemed as authentic. For

this purpose, the most relevant constraint to which we

want to give a positive answer is the authentication

delay. In particular we must assure that a node, if the

bus is not taken by a higher priority message, is able to

transmit the message and the message can be checked

for authenticity as soon as possible. This condition

is initially limited by the computational power, but as

checking for authenticity can happen only as soon as

the disclosure delay expires and the next element of

the chain is committed, this also depends on the struc-

ture of the chain which is determined by the amount

of memory, and also on the bandwidth. Using too

large chains means too much time in the initialization

stage and large amounts of memory, while too short

chains means either high authentication delays or too

frequent re-initializations, etc. Depicting an optimum

in this context is not straight forward and we study

this in detail in what follows. In particular, we used in

our scheme several levels of one way chains. While

three levels of one-way chains were reported to be

close to optimal in sensor networks, due to memory

constraints and to reduce initialization in some situ-

ations we used more levels. This is because of both

the time horizon of the protocol and of the duration of

the disclosure interval. In sensor networks the disclo-

HIGHER LAYER AUTHENTICATION FOR BROADCAST IN CONTROLLER AREA NETWORKS

189

sure interval was in the order of tens or hundreds of

milliseconds, while here, to increase communication

speed we want to reduce this as much as possible. Of

course, we are ﬁnally limited by the bus speed and

by the synchronization error, which in fault-tolerant

CAN will not allow us to drop the disclosure delay un-

der several milliseconds. Practical examples are given

in the experimental results section.

The paper is organized as follows. Section 2 gives

an overview of the protocol, starting from several de-

tails of the CAN protocol to the examination of the

inﬂuence of chain lengths, structure and timings on

performance. In section 3 we present experimental re-

sults concerning the implementation of the proposed

protocol on S12X microcontrollers. This includes ex-

perimental results for the implementation of crypto-

graphic primitives on the XGATE co-processor. Sec-

tion 4 holds the conclusions of our paper.

2 THE PROTOCOL

From an upper view the design paradigm is the fol-

lowing. Memory, computational speed and band-

width gives bounds on the length of the chains that

can be used and the number of levels. This, alongwith

the synchronization error, further bounds the authen-

tication delay, as messages cannot be authenticated

faster than the disclosure delays. Further, to improve

on the delays, we allocate equidistant timings in order

to avoid a non-uniform load on the CAN bus. Indeed,

since initialization packets must have the highest pri-

ority, if timings are non-uniform, there will be periods

when more chains need to be initialized and thus the

bus will be heavily loaded by initialization packets.

Before getting to the description of the protocol we

enumerate brieﬂy in what follows some relevant as-

pects of the CAN bus.

2.1 Short Description of the CAN

Protocol

We are not interested here in typical aspects of the

protocol such as error detection, synchronization,etc.,

so we will not mention them. CAN bus has a broad-

cast nature. Nodes are connected by a two wire bus

topology, as shown in ﬁgure 1, and access to the bus

is gained with priority based on a message identiﬁer

which forms the ﬁrst part of a frame. This identiﬁer

has 29 bits in extended frames and 11 bits in standard

frames. The structure of the CAN frame consists in

the arbitration ﬁeld (the identiﬁer), 6 bit control ﬁeld,

0-64 bits of data, 15 bit CRC and a 2 bit acknowledge-

ment. Additionally 1 bit marks the start of frame and

7 bits mark its end. This structure is suggested in ﬁg-

ure 2. Few words on arbitration are in order. The way

of arbitrating is by judging the winner based on the

state of a particular bit, namely recessive bits (value

1) are overwritten by dominant bits (value 0). So, if

the case, all nodes can start to write a message at the

same moment on the bus, but, whenever a node writes

a recessive bit and reads a dominant one it means that

it lost the arbitration and will stop, otherwise it can

continue. After each 6 consecutive bits of identical

values a stufﬁng bit of different value is added. The

body of a message can have at most 8 bytes and is fol-

lowed by a 15 bit CRC. In the worst case a frame can

have 154 bits out of which only 64 bits are of actual

useful information. Thus, the overhead is high from

the basic design of the protocol, in the worst case ex-

ceeding 50%. But this is needed to achieve reliabil-

ity as mentioned before. Two kinds of CAN nodes

are commonly available on the market: fault tolerant

low-speed nodes which operate at 128kBps and high-

speed nodes that work up to 1MBps.

Figure 1: Generic CAN Bus topology.

Figure 2: Structure of a CAN data frame.

2.2 Overview of the Protocol

The generic structure of the key chains is depicted in

ﬁgure 3. We use time synchronization and multiple

levels of one-way chains in order to authenticate the

broadcast from a particular node. Packets arriving on

the communication bus are depicted as well, the dot-

ted lines from an element of the chain to the packet

denotes that the element was used as a key, and for

the re-initialization packets in particular one element

of the key chain was also used as a message. The pic-

ture denotes the case of more than one sender, e.g.,

i, j

is packet sent by principal i to initialize a chain

from level j. In the next sections we will use the fol-

lowing notations:

SECRYPT 2011 - International Conference on Security and Cryptography

190

• L - number of chain levels,

• λ

,i = 1..L - length of the chain on level i,

• δ

,i = 1..L - disclosure delay on level i,

• B - bus speed, normalized to packets per second

(where one packet can carry one key),

• M - available memory (measured in elements of

the key chain that can be stored),

• S - computational speed (number of elements of

the key chain that can be computed per second),

• T - time horizon of the protocol (one may view

this as the disclosure delay of level 0),

• t - denotes actual time and is a positive integer, a

subscript indicates particular details.

Based on these notations in the next section we

discuss the optimal allocation of the broadcast param-

eters.

In principle we need two distinct protocols: an ini-

tialization protocol and a broadcast protocol. The role

of the initialization protocol is to allow each unit to

commit its initialization values and to achieve time

synchronization with other participants. This part of

the protocol can rely on more expensive operations

required by public-key cryptography. In this stage

we consider that each principal will authenticate it-

self by using a public key certiﬁcate that is signed

by a trusted authority. Initial authentication based on

public-key infrastructure is important to assure com-

posability. This ensures that different components,

from potentially different manufacturers, can be as-

sembled in one system and is a common demand of

the market today. For example, in a different context

(that of communication alone), the latest state-of-the-

art protocol, FlexRay, has communication segments

that are preallocated such that different components

from different providers can be bind into a system.

Thus we require that each node must store the public

key of a trusted authority. Although public key certiﬁ-

cates are larger and will require more than one frame

(which can carry at most 64 bits) in general it should

not be a problem to transport them over CAN if this

does not happen too often and just in the initialization

stage.

The initialization protocol must also ensure time

synchronization. This is done with respect to a cen-

tral node, which will play the role of a communica-

tion master. As usual, synchronization between two

nodes is loose and it requires a handshake and count-

ing the round trip time until it is below a tolerance

margin. This is usually achieved in two protocol steps

as follows: A → B : N

;B → A : Sig

). Here

denotes a nonce generated by principal A and t

denotes the current time at principal B when send-

ing its response. However, in our scenario a digi-

tal signature costs tens, or hundreds of milliseconds,

which will result in a high tolerance margin that will

further require an even larger disclosure delay. Be-

cause of this, instead of a digital signature we will

use a message authentication code which is several

orders of magnitudes faster. In particular, in our ex-

periments, the round-trip-time was less than 2 mil-

liseconds. Afterwards, the round trip time ε

be-

comes the synchronization error. If the nonce was

sent by A at time t

and now A’s clock points to t

then A knows that the time on B side is in the interval

+ t

− t

, t

+ t

− t

+ ε

]. Further, the initializa-

tion values for the chains can be shared between each

node and the central node who can broadcast them to

all communication participants. We will not insist on

details of the initialization protocol which is done in

the initial phase with no constraints.

2.3 Optimal Allocation of Key Chain

Lengths and Levels

For brevity we consider a homogeneous network with

nodes that have equal computationalabilities, thus the

same computational delays and lengths for the chains

can be handled by all of them. Otherwise, the proto-

col can be scaled according to the computational abil-

ities of each client, but we want to keep the model as

simple as possible.

To formalize the optimal allocation of chain

lengths and levels, different to previous work, we use

a tolerance relation to deﬁne the lengths of the chains

and the disclosure delays at each level. The tolerance

relation is formed by vectors which are deﬁned as ini-

tialization values for each communication participant.

Deﬁnition 1. We say that a set of pairs < λ

,δ

forms tolerance relation with respect to memory,

computational speed, bandwidth and time, denoted as

< Λ, ∆ >

M,S,B,T

if the following constraints hold:

∑

i=0,L

= λ

+ λ

+ ... + λ

≤ M (1)

∑

i=1,L

∏

j=0,i

= λ

·λ

+...+λ

·λ

·...·λ

≤ S·T (2)

∑

i=0,L

∏

j=0,i

= λ

+ λ

·λ

+ ... + λ

·λ

·... ·λ

≤ B· T

(3)

Relation (1) givesthe memory bound, i.e., the sum

of the lengths of the chains cannot exceed the total

memory. Relation (2) and (3) are bounds on compu-

tational time and bandwidth, i.e., the total number of

HIGHER LAYER AUTHENTICATION FOR BROADCAST IN CONTROLLER AREA NETWORKS

191

Figure 3: Basic structure of the one-way chains.

elements of the one-way chain cannot require more

computational time than available over protocol life-

time T and cannot exceed the available bandwidth for

transmission. Value λ

is missing from relation (2)

as the ﬁrst key chain is computed in the initialization

stage, while λ

is present in relation (3) as the ﬁrst

key chain will be disclosed as well on the bus. In-

deed, relations (2) and (3) can be further reﬁned for

the disclosure delays on all up to the last level since

the re-initialization of each chain should be done in

the disclosure delay of the previous level. Thus, we

can write (2) as ∀k > 1,

∑

i=k,L

∏

j=k−1,i

=≤ S · δ

and the same holds for bandwidth. We introduced this

deﬁnition to keep our presentation formal, but it is ob-

vious that deﬁning good tolerance relations is a matter

of good engineering.

The general relation between chain lengths and

disclosure delays will now be the following:

= δ

i−1

/λ

,i > 0 (4)

Intuitively, this also means that ∀i,λ

denotes the

number of one-way functions computations that can

be performed in time δ

i−1

to generate a new chain.

Thus λ

can also be deﬁned as a function of δ

i−1

. One

can use this to create sub-intervals by using the previ-

ous relation.

Remark 1. Given a tolerance relation < Λ, ∆ >

M,S,B,T

with respect to time, space and bandwidth the disclo-

sure delay and the computational overhead have an

inverse variation. Thus: the minimal disclosure delay

is achieved if chains are of equal size, i.e., λ

= M/L,

while the minimal computational and communication

overhead is achieved if upper level chains are smaller,

i.e., λ

< λ

< ... < λ

This is intuitively since the product of two val-

ues whose sum is ﬁxed is maximal if the two values

are equal and minimal if one of the values is 1. For

example, assume x + y = z then ∀k ≥ 1,z/2 · z/2 >

(z/2 − k) · (z/2 + k) = z

/4 − k

. Now, to achieve

the minimum delay, the product of the chain lengths

· λ

· ... · λ

must be maximal. If we split this prod-

uct exactly into the half left and half right terms, as-

suming an even number of terms which is wlog, then

the maximum product is achieved if: the left and right

are maximal and they are equal, and so on. To achieve

minimal bandwidth and computational requirements

we need λ

· λ

+ ... + λ

· λ

· ... · λ

to be minimal.

This can be written as λ

· (λ

+ ... + λ

· ... · λ

) and

as right term cannot be equal to 1 the left term must

be 1 in order to minimize the product and so on. Thus,

the optimum choice of lengths with respect to delays,

is to have all chains of equal size. For the purpose of

generality, as well as for the fact that in practice small

variations between chain lengths may occur when the

amount of available memory is not directly divisible

with the number of levels, we will keep the following

exposition for the case when chains are of arbitrary

sizes.

2.4 Optimal Allocation of Timings

By optimal allocation of the key disclosure time we

want to achieve minimal delays for sending messages

and authenticating them. Of course, the authentica-

tion delay is bounded by the disclosure delay, i.e.,

packets cannot be authenticated sooner than the dis-

closure delay from the last level. This bound was al-

ready ﬁxed by the tolerance relation. However, the

straight forward mechanism suggested in ﬁgure 3, in

which chains are re-initialized successively, causes

more overhead at the disclosure time of keys from

upper layer chains (since at this time all chains from

lower levels need to be re-initialized as well). To

overcome this, we deﬁne a procedure which we call

equidistant timing by which all packets are disclosed

at periods of time separated by equal delays. More,

different to the use in sensor networks where upper

layer chains are used only to authenticate keycommit-

ments from the lower levels, we use chains from up-

SECRYPT 2011 - International Conference on Security and Cryptography

192

per levels to authenticate information packets as well.

Thus, we will normalize the disclosure time to:

norm

· λ

... · λ

(5)

In the forthcoming scheme, keys on all levels are

released at δ

norm

intervals. Of course, if we use rela-

tion (4), δ

norm

is equal to δ

but we prefer to use this

notation to avoid confusion with a generic scheme in

which this may not happen, i.e., not all keys are re-

leased at δ

norm

but only the keys from the chain on

level L. In what follows we need to establish three

things:

• which is the disclosure time for a particular key k

and its converse which follows,

• given a particular time t which key must be dis-

closed, or which is the last key that was disclosed

upon t,

• given a particular packet, containing authentica-

tion information, what condition must be met on

the receiver’s side to deem this packet as on-time.

To determine all these, the easiest way to decide

is by writing the time with respect to the vectors of

the tolerance relation which is established by the next

deﬁnition.

Deﬁnition 2. Given a discrete time value t we denote

by t

<Λ,∆>

=< t

L−1

...t

> the discrete time decom-

position of t with respect to the lengths of the chain

and normalized time as a basis, i.e., the writing of the

time value as:

t = δ

norm

∑

i=L..1

∏

j=i..1

) + t

(6)

= t

· λ

· ... · λ

· δ

norm

+ ... +t

· λ

· δ

norm

+ t

2.4.1 Sender’s Perspective.

For the moment we consider the case of a single

sender. Let t

start

denote the time at which the broad-

cast was started and assume that it is started by the

communication master which also gives time syn-

chronization. Thus t

start

is the exact time at which

the broadcast started (no drifts for the sender).

Deﬁnition 3. Let τ ∈ Λ

i, j

denote that τ is a vector

of j − i + 1 positive integers such that each element

on position i is less or equal to λ

. Given a tolerance

relation < Λ,∆ >

M,S,B,T

, an indexed key K

is a key

entailed by a vector τ ∈ Λ

1..L

. An indexed key chain

<Λ,∆>

is a collection of indexed keys, derivedas fol-

lows: having a ﬁxed fresh seed K

master

, a key deriva-

tion process K D and a one-way function F , then:

∀i ∈ [1,L],τ

∈ [1,λ

],τ

left

∈ Λ

i+1,L

,τ

right

∈ Λ

1,i−1

left

|0|τ

right

= K D (K

master

,τ

left

,τ

right

left

|τ

right

= F (K

left

|τ

−1|τ

right

) (7)

Deﬁnition 4. Let D T (K

) denote the disclosure time

of the indexed key K

. Given a broadcast started at

start

the disclosure time of this key is:

D T (K

) = t

start

+ δ

norm

∑

i=L..1

(τ

∏

j=i..1

) (8)

Deﬁnition 3 allows the generation of chains with

the structure from ﬁgure 3 while deﬁnition 4 allows

keys to be released at equal time intervals δ

norm

Remark 2. The key released by the sender at time

current

given a broadcast started at t

start

is K

<Λ,∆>

where t = t

current

− t

start

. By t

<Λ,∆>

we denote all

elements from t except the last term, i.e., t

. This

means that

• the key is from level L−l, where l is the ﬁrst non-

zero index from right to left, i.e., the maximum

value such that ∀i ≤ l,t

= 0,

• the position of the key on the key chain from level

l is t

• the number of chains previously released at this

level is j is t

l+1

· λ

l−1

+ t

l+2

· λ

l−1

· λ

l−2

+ ... +t

∏

i=l..L

2.4.2 Reinitialization Packets and Efﬁciency

To avoid a non-uniform bus load, as discussed pre-

viously, re-initialization packets will be dropped

equidistantly in the δ

norm

intervals. Otherwise,

packets carrying data must be delayed until all re-

initialization packets are sent. This is because re-

initialization packets must have priority on the bus,

otherwise the protocol will succumb an will require

passing through the initialization stage again which is

even more expensive. Thus we can also use as an ef-

ﬁciency criteria the maximum delay until a new CAN

frame can be send. For the basic scheme the maxi-

mum delay ﬂuctuates with the number of initializa-

tion packets. This delay can be easily established for

the basic scheme. Let z

(x) denote the number of con-

secutive zeros in vector x starting from position 1. At

discrete time value t, given t

<Λ,∆>

the delay until the

next packet can be sent is:

delay = max[0, z((t − t

start

)

<Λ,∆>

)] (9)

Indeed, the number of consecutive zeros at the end

of the time value denotes how many chains need to be

initialized at that particular time. This value becomes

constant for the equidistant scheme and data packets

HIGHER LAYER AUTHENTICATION FOR BROADCAST IN CONTROLLER AREA NETWORKS

193

are delayed by at most one packet.

To complete the view on efﬁciency, we should

also deﬁne the overhead induced by the authentication

mechanism. The overhead has two distinct compo-

nents, the authentication overhead which is the over-

head inﬂicted by the authentication keys that are re-

leased on the bus, and the re-initialization overhead

which is the overhead inﬂicted by the re-initialization

material. Indeed, to this one may want to add the over-

head induced by the message authentication codes,

MACs, associated to each data packet that is send over

the bus. We will not take this into account because

this is application dependent, not protocol dependent,

indeed in some applications the size of the data pack-

ets can be small, and thus adding a MAC to each data

packet will greatly increase the overhead. In other ap-

plications it may be the reverse, and data packets can

be large and the MAC will not signiﬁcantly increase

the overhead. Based on these we can also deﬁne the

total overhead inﬂicted by the protocol.

Remark 3. Given a tolerance relation < Λ, ∆ >

M,S,B,T

the authentication and re-initialization overheads and

the bus load induced by the protocol is:

auth

= (λ

+ λ

· λ

+ ... + λ

· λ

· ... · λ

) · B

−1

(10)

reinit

= (λ

· λ

+ ... + λ

· λ

· ... · λ

) · B

−1

(11)

total

= OH

auth

+ OH

reinit

(12)

One may note that if the authentication delay

is bigger the overhead also becomes lower since

fewer elements of the chain are sent. Also, the re-

initialization overhead increases with the number of

levels. We give concrete examples for these in the

experimental results.

Figure 4 shows the inﬂuence of chain length on

bus overhead and disclosure delays. Plots are given

for three and four levels of key chains. We note

that the delays drop rapidly by increasing the num-

ber of levels, but in the same manner the overhead

increases (at 100% the bus is locked and communica-

tion halted). Figure 5 shows the variation of memory

requirements, which is the same as the initialization

time, and of the number of re-initialization packets

with the number of chain levels. All plots are taken

for a time range of 24 hours, in ﬁgure 5 the delay is

ﬁxed to 5 ms.

2.4.3 Receiver’s Perspective

We consider the case of a sender S with synchroniza-

tion error ε

and a receiver R with synchronization

100

150

200

250

0.2

0.4

0.6

0.8

1.0

Bus OH H4 levelsL

Delay

H4 levelsL

Delay H3 levelsL

Bus OH H3 levelsL

Figure 4: Delay and overhead variation with chain length.

1000

2000

3000

4000

5000

6000

7000

Memory and

Initialization Time

Re-initialization packets

Hper secondL

Figure 5: Memory, initialization time and re-initialization

packets variation with number of levels.

error ε

. Now we deﬁne the security condition that

must be met by all packets that contain authentica-

tion information, i.e., MAC codes, produced with an

indexed key K

Deﬁnition 5. Given synchronization errors ε

and ε

for sender and receiver, an authentication packet in-

dexed by τ must discarded unless:

rec

) ≤ D T (τ) − ε

− ε

(13)

Here T

rec

) denotes the time at which packet P

was received. Here we assume that the time on the

receiver side is common to that on the sender’s side,

since this is after the synchronization. Thus T

rec

)

is the minimum time value on the sender’s side, while

the synchronization errors on the right side ensure a

safe margin for the maximum time value.

2.4.4 Protocol Description

We can now summarize previous notions in one deﬁ-

nition for the entire protocol.

Deﬁnition 6. Given tolerance relation < Λ,

∆ >

M,S,B,T

, an indexed key chain K

<Λ,∆>

and the two

roles sender and receiver denoted by S , R each with

synchronization errors ε

, ε

with respect to a com-

mon clock, protocol Broadcast[S ,R ,< Λ,∆ >

M,S,B,T

SECRYPT 2011 - International Conference on Security and Cryptography

194

<Λ,∆>

] is formed by the following two rules for the

two roles:

1. S sends K

at D T (K

) and the message M and

its corresponding MAC(K

,M) in any empty time-

slot with the condition that MAC(K

,M) is re-

leased no latter than D T (K

) + ξ,

2. R discards all MAC(K

,M) received later than

D T (K

) + ε

+ ε

and deems authentic all other

messages for which MAC(K

,M) can be veriﬁed

with an authentic key. A key K

left

|τ

right

is au-

thentic only if K

left

|τ

right

= F (K

left

|τ

−1|τ

right

) and

left

|τ

−1|τ

right

is a previously received/computed

authentic key.

Here ξ denotes a tolerance margin until the sender

can send a MAC with a particular key. Indeed, send-

ing MACs too close to the disclosure time may be use-

less because the receiver may have to discard them if

the security condition cannot be met. Thus ξ must

be ﬁxed as initial parameter for the protocol and

it must hold that ε

+ ε

<< ξ. In time interval

[D T (K

),D T (K

)+ξ] the sender can safely disclose

any kind of data packet, but not MACs.

Broadcast[S , R ,< Λ,∆ >

M,S,B,T

<Λ,∆>

] is a se-

cure broadcast authentication protocol. The security

of this family of protocols is well established, the

informal argument is that the adversary cannot con-

struct MAC(K

,M), until K

is released. As function

F is one-way he cannot derive K

from F (K

) and

by the time K

is released any MAC with K

that is

further received will be discarded. Formal proofs for

such protocols can be found in (Perrig et al., 2001a),

(Bergadano et al., 2002).

2.5 The Case of Multiple Senders

The case of k senders can now be easily derived from

the previous formalism. To preserve the equidistant

time schedule we use the nominal disclosure time

norm

and divide it by the number of senders k. Let

us deﬁne the next sender delay as:

norm

(14)

Deﬁnition 7. Let D T (K

) denote the disclosure time

of an indexed key by the by the k

sender. Given a

broadcast started at t

start

we have:

D T (K

,k) = D T (K

) + k· δ

(15)

The security conditions which has to be veriﬁed

by receivers must also add the k· δ

term to the dis-

closure time of the k-th sender.

3 APPLICATION SETTING AND

EXPERIMENTAL RESULTS

As stated, for the implementation of the previously

described protocol, we used a Freescale 16-bit au-

tomotive grade microcontroller (MC9S12XDT512)

from the S12X family on a SofTec Microsystems ZK-

S12-B development board. One special feature of this

family is the presence of an incorporated co-processor

called XGATE which can be used to increase the mi-

crocontroller’s data throughput (Freescale, 2004). We

made use of this module to increase the efﬁciency of

our implementation by assigning it the task of com-

puting the underlying cryptographic functions.

The S12X microcontrollers used in our exper-

iments have 512Kbytes of FLASH memory and

20Kbytes of RAM. Both FLASH and RAM memo-

ries are banked as a consequence of the 16 bits wide

address bus which is not sufﬁcient to access all mem-

ory locations. Thus, a total of 8Kbytes of RAM space

can be used for continuous allocation while the rest

of the RAM can be accessed in 4Kbyte windows. The

amount of RAM memory that can be used for storing

key chains is relevant as it determines the maximum

number of chain levels and their lengths.

The maximum bus frequency that can be set us-

ing the PLL module is, according to the data-sheet,

40MHz. We conﬁgured the PLL for frequencies be-

yond this speciﬁed value and were able to go up to

speeds of 80MHz. After assessing that the behaviour

of the microcontroller at this overclocked frequency

is normal we used it in our tests and compared the

results with the ones obtained for 40MHz.

The on-chip CAN module implements version

2.0A/B of the CAN protocol and supports a pro-

grammable bit-rate up to 1 MBps. A limitation for

the maximum achievable CAN speed comes from the

on board low speed fault tolerant transceiver which

can only run at speeds up to 125Kbaud.

3.1 XGATE Module

The XGATE module has a built in RISC core with in-

structions for data transfers, bit manipulations and ba-

sic arithmetic operations. The RISC core can access

the internal memories and peripherals of the micro-

controller without blocking them from the main S12X

CPU. The S12X CPU always has priority when the

two CPUs access the same resource at the same time.

To assure data consistency, the access priority can be

controlled by using the hardware semaphores avail-

able on the microcontroller.

Interrupts can be routed to the XGATE module in

order to decrease the interrupt load of the main S12X

HIGHER LAYER AUTHENTICATION FOR BROADCAST IN CONTROLLER AREA NETWORKS

195

CPU. Additionally, up to 8 software triggered chan-

nels can be used by the S12X CPU to request software

execution on XGATE.

In order to obtain the maximum XGATE CPU

speed, the code can be executed from RAM. Because

RAM is a volatile memory, XGATE code is being

stored into the FLASH memory and copied into RAM

after each reset. Having a better RAM access speed

and a speed-optimized instruction set, a typical func-

tion can run up to 4.5 times faster on XGATE than

on the S12X CPU (Mitchell, 2004). Because it was

designed for quick execution of small code requested

by interrupts, the ﬂash memory available for storing

XGATE code is limited. For controllers in the S12XD

family this limit is 30 Kbytes.

3.2 Implementation Details

To decrease the communication overhead that could

be introduced by computing cryptographic primitives

we assigned this task to the XGATE module. In or-

der to evaluate the computational performance of the

microcontroller we measured the execution speed of

three hash functions: MD5, SHA1 and SHA-256.

Measurements were done on S12X and XGATE for

different input lengths using both the maximum spec-

iﬁed frequency and the overclocked frequency. The

measurements presented in tables 1, 2 and 3 show

that on average the hash functions were performed

approximately 2.12 times faster on XGATE than on

S12X. The overclocking also increases the speed with

a factor of 2.

Table 1: Performance of S12X and XGATE in computing

MD5.

Length

(bytes)

Execution time

@ 40MHz @ 80MHz

S12X XGATE S12X XGATE

0 732µs 312.5µs 371µs 156.2µs

1 736µs 314.5µs 373µs 157.4µs

3 737µs 314.5µs 373µs 157.2µs

14 738µs 316.0µs 374µs 158µs

26 739µs 317.5µs 374.5µs 158.9µs

62 1414µs 605µs 717µs 303µs

80 1374µs 592µs 697µs 296.5µs

We chose MD5 for building the one-way chains

which are needed by the protocol. Due to the small

disclosure delay we consider that using MD5 is safe

for our scenario. Each chain element will thus be a

128 bit value which is used to perform an HMAC over

the message that has be sent at a certain point in time.

All cryptographic computations are done on the

XGATE module following a software request. For

passing data between the two processing units, a com-

Table 2: Performance of S12X and XGATE in computing

SHA1.

Length

(bytes)

Execution time

@ 40MHz @ 80MHz

S12X XGATE S12X XGATE

0 2.285ms 1.000ms 1.144ms 500µs

1 2.290ms 1.002ms 1.146ms 501µs

3 2.290ms 1.002ms 1.146ms 502µs

14 2.290ms 1.004ms 1.148ms 502µs

26 2.295ms 1.004ms 1.148ms 503µs

62 4.510ms 1.976ms 2.255ms 988µs

80 4.470ms 1.962ms 2.235ms 982µs

Table 3: Performance of S12X and XGATE in computing

SHA-256.

Length

(bytes)

Execution time

@ 40MHz @ 80MHz

S12X XGATE S12X XGATE

0 5.51ms 3.155ms 2.755ms 1.578ms

1 5.52ms 3.155ms 2.760ms 1.580ms

3 5.52ms 3.155ms 2.760ms 1.580ms

14 5.50ms 3.150ms 2.755ms 1.578ms

26 5.49ms 3.145ms 2.750ms 1.578ms

62 10.86ms 6.24ms 5.44ms 3.125ms

80 10.80ms 6.22ms 5.40ms 3.115ms

mon memory area is used. Each time a hash needs to

be computed, the S12X writes the input data in the

common memory area and makes a software request

to the XGATE module. While the hash is computed

on the XGATE side, the main CPU is free to execute

other tasks such as, receiving messages or sending

messages that have been already built. The XGATE

module can signal the end of the function execution

by issuing an interrupt to the S12X CPU.

After protocol implementation, the total RAM

memory left for storing key chains can hold 1216 ele-

ments (16 bytes each). Having this upper limit for M,

L and λ have to be determined for best performances

based on the bus speed and the desired disclosure de-

lay. If we consider packets of 16 bytes in size, the

measured bus speed for sending packets is 578 pack-

ets/second (one packet each 1.730ms).

For example, if we decide to use three levels to

assure authentication over a period of one day with

a speed of 578 packets/second, we would have 233

elements on each level and the key disclosure time

δ would be 6.8ms. The bus overhead for this situa-

tion is 25,2% and the time needed to initialize the key

chains is approximately 700ms. Increasing the num-

ber of levels to 5 leads to chains of 26 elements so

less memory is necessary and the time needed for ini-

tialization is reduced to 131ms. The cost of these im-

provements is a bus overhead of 26.9%. The bus load

grows exponentially with the increase in the number

SECRYPT 2011 - International Conference on Security and Cryptography

196

of levels used while the disclosure delay depends on

the transmission speed and the total communication

duration. The duration of the communication also af-

fects the number of elements on each level which is

upper bounded to M/L (1216/L in our setting).

To further improve performance, using small scale

variants of hash functions, as proposed in (Macchetti

and Rivard, 2005) can be an interesting alternative.

However, as collisions on these functions were al-

ready reported in (Steurer, 2006), a more in depth

analysis is needed before using them in practice and

we leave this as potential future work.

4 CONCLUSIONS

A protocol for assuring broadcast authenticity on the

CAN bus was provided. We studied different trade-

offs in order to depict the optimal choice of param-

eters. In particular we concluded that the main lim-

itation is the bus speed (limited to 128kBps in fault-

tolerant CAN), followed by memory and last by com-

putational power. This is also due to the performance

of the XGATE co-processor which is about two times

faster than the regular S12 processor. In some cases,

to reduce memory consumption and to shorten the ini-

tialization time, chains with more than three levels

were also efﬁcient. The theoretical estimations are en-

tailed by experimental results on the S12X processor,

a commonly used automotive grade microcontroller.

As future work we plan to extend this paper with ex-

perimental results on other microcontrollers and to

use a real-world communication scenario for an au-

tomotive network. By this research we hope that we

give a ﬁrst analysis on the feasibility of such a solu-

tion.

ACKNOWLEDGEMENTS

This work was supported by CNCSIS-UEFISCDI

project number PNII-IDEI 940/2008 and by the

strategic grant POSDRU 107/1.5/S/77265, inside

POSDRU Romania 2007-2013co-ﬁnanced by the Eu-

ropean Social Fund - Investing in People.

REFERENCES

Anderson, R., Bergadano, F., Crispo, B., Lee, J.-H., Man-

ifavas, C., and Needham, R. (1998). A new family

of authentication protocols. SIGOPS Oper. Syst. Rev.,

32:9–20.

Bergadano, F., Cavagnino, D., and Crispo, B. (2002). Indi-

vidual authentication in multiparty communications.

Computers & Security, 21(8):719 – 735.

BOSCH (1991). CAN Speciﬁcation Version 2.0. Robert

BOSCH GmbH.

Charzinski, J. (1994). Performance of the error detection

mechanisms in can. In Proceedings of the 1st Interna-

tional CAN Conference, pages 20–29.

Freescale (2004). MC9S12XDP512 Data Sheet, Rev. 2.21,

October 2009. Freescale.

ISO (2003). ISO 11898-1. Road vehicles - Controller area

network (CAN) - Part 1: Controller area network data

link layer and medium access control. International

Organization for Standardization.

ISO (2004). ISO 11898-4. Road vehicles - Controller area

network (CAN) - Part 4: Time triggered communica-

tion. International Organization for Standardization.

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

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

Shacham, H., and Savage, S. (2010). Experimental

security analysis of a modern automobile. In Security

and Privacy (SP), 2010 IEEE Symposium on, pages

447 –462.

Lamport, L. (1981). Password authentication with insecure

communication. Commun. ACM, 24:770–772.

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

rity in Cars Securing Current and Future Automotive

IT Applications. Springer Verlag.

Liu, D. and Ning, P. (2003). Efﬁcient distribution of key

chain commitments for broadcast authentication in

distributed sensor networks. In Proc. of the 10th An-

nual Network and Distributed System Security Sympo-

sium, pages 263–276.

Liu, D. and Ning, P. (2004). Multilevel µtesla: Broadcast

authentication for distributed sensor networks. ACM

Trans. Embed. Comput. Syst., 3:800–836.

Macchetti, M. and Rivard, P. (2005). Small-scale variants

of the secure hash standard. In ECRYPT workshop on

RFID and lightweight cryptography.

Mitchell, R. (2004). Tutorial: Introducing the XGATE Mod-

ule to Consumer and Industrial Application Develop-

ers, March 2006. Freescale.

Perrig, A., Canetti, R., Song, D., and Tygar, J. D. (2001a).

Efﬁcient and secure source authentication for multi-

cast. In Network and Distributed System Security Sym-

posium, NDSS ’01, pages 35–46.

Perrig, A., Canetti, R., Song, D., and Tygar, J. D. (2001b).

Spins: Security protocols for sensor networks. In

Seventh Annual ACM International Conference on

Mobile Computing and Networks (MobiCom 2001),

pages 189–199.

Perrig, A., Canetti, R., Tygar, J., and Song, D. X.

(2000). Efﬁcient authentication and signing of multi-

cast streams over lossy channels. In IEEE Symposium

on Security and Privacy, pages 56–73.

Steurer, M. E. (2006). Multicollision attacks on iterated

hash functions. Technical report.

HIGHER LAYER AUTHENTICATION FOR BROADCAST IN CONTROLLER AREA NETWORKS

197