scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

Performance analysis of broadcast authentication protocols on CAN-FD and FlexRay

TL;DR: This work addresses the performance for various authentication protocols that were recently proposed for the two most prominent vehicular buses: FlexRay and CAN-FD by using a CANoe based simulation for these protocols over state-of-the-art automotive buses and suggests that sharing symmetric keys between groups of nodes is the most realistic proposal.
Abstract: In the light of the numerous reported attacks, designing cryptographic protocols for in-vehicle embedded networks was a constant preoccupation in the past few years. While several research proposals appeared, a concrete performance analysis of such protocols over a realistic network configuration is still absent from the literature. In this work we address the performance for various authentication protocols that were recently proposed for the two most prominent vehicular buses: FlexRay and CAN-FD. While a real-world vehicular network is still out of reach for our work, we achieve a first step in this direction by using a CANoe based simulation for these protocols over state-of-the-art automotive buses. This allows us to draw a more realistic perspective on the efficiency of existing proposals for bus authentication. Our results suggest that sharing symmetric keys between groups of nodes is the most realistic proposal as it creates a balance between bandwidth efficiency and security level.

Summary (2 min read)

1. INTRODUCTION

  • Contemporary vehicles are the result of an evolutionary process that augmented mere mechanical devices with complex electronics and intricate software counterparts.
  • There are little doubts that in terms of attacks and defenses vehicular networks will evolve in a similar manner to computer networks.
  • In this work the authors take a first step in this direction by using the industry standard CANoe tool in order to simulate a realistic state-of-the-art network based on FlexRay and CAN-FD.

1.1 State-of-the-art in-vehicle buses: FlexRay and CAN-FD

  • The reasons for choosing these buses are clear: CAN is the most common bus inside cars and FlexRay was designed as its successor.
  • The authors give next a brief description of these two communication layers.
  • The bit-length of the fields are displayed below, the only exception being the data field for which the length is represented in bytes.
  • FlexRay accomplishes the use of both static and dynamic frames by employing a predefined communication cycle which defines specific segments for static and dynamic data.
  • CAN-FD (CAN with Flexible Data Rate) [16] is a protocol designed by Robert Bosch GmbH to extend the standard CAN protocol [15].

2. PROPOSED PROTOCOLS, A SYNTHETIC COMPARISON

  • This section contains an overview of recently proposed protocols for assuring authentication in automotive networks.
  • A synthetic performance comparison of the presented protocols follows, the authors then take this comparison to the experimental level on their experimental network topology with the help of the CANoe simulation.

2.1 Brief overview of recent proposals

  • The authors now enumerate some of the recent proposals, subsequently, they are revisited from a key allocation perspective which is decisive for the performance evaluation that follows.
  • This does not only require nodes to be present on the bus but also for a message to accumulate a sufficient number of votes which introduces additional delays.
  • Implementing this protocol on the CAN bus was considered in [4].
  • The authors of MaCAN [6] suggest that nodes can be grouped under the same key if they share the same trust level which will lead to a reasonable number of keys, but no practical insights are given on how to decide the trust level.
  • The proposal is more demanding from a computational point of view, but it offers a higher security level in case when adversaries are in minority (a likely scenario for in-vehicle networks).

2.2 Revisiting protocols from a keying perspective

  • While in the previous subsection the authors encountered several proposals, the crux of the problem (and the difference between the previous schemes) comes from the way in which the keys are distributed between the nodes.
  • The authors now revisit the previous proposals and classify them based on the keying procedure they employ.
  • ID-oriented keying is a variation of this in which each frame carries a single authentication tag, but the key to compute this tag is unique for each of the IDs.
  • This procedure is also employed in MaCAN [6].

3.1 Network topology

  • The network topology discussed below stays at the core of their CANoe based simulation.
  • Figure 6 depicts the experimental network topology consisting of 30 ECUs.
  • All nodes are interconnected using the same bus type, thus, separate simulations were built for each bus type (FlexRay and CAN-FD) on the same topology.
  • Protocols relying on group keying require special attention as nodes need to be further grouped.
  • Since there are not many hints on how this decision should be taken (in the absence of manufacturer specifications), the allocation scheme that the authors opted for was to obtain a balanced number of frames transmited by each group (this can be seen at least as a secondary, more practical criteria).

3.2 Comparative results

  • The comparative evaluation of the protocols can account for two distinct characteristics: the bandwidth (which depends on the number and size of the authentication tags) and the computational load on each ECU (which depends on the number of tags that each sender/receiver has to compute/verify each second).
  • TESLA-like keying requires for each sender (ECU on the network) a new frame containing a 32, 64 or 128 bit authentication tag that is periodically broadcast.
  • Tables 4, 5 and 6 summarize the performance data for the 4 authentication paradigms in terms of authentication payload (Table 4), computational load (Table 5) and recorded busload (Table 6), the latter being measured by the CANoe simulation tool, separately for the FlexRay and CAN-FD experimental networks.
  • The computational load varies from a little more than 1.000 tags/second up to almost 10.000 tags/second but these loads should be easily handled by hardware implementation on modern ECUs.
  • The authors can observe that, for the FlexRay network, the busload changes only when additional frames are introduced, the addition of data bytes to the existing frames has little effect.

4. CONCLUSION

  • The conclusions can be directly drawn from the experimental section.
  • TESLA-like keying, although bringing a minimum increase in the payload and computational load, is not a realistic solution for real-time automotive systems where all the data contained in the frames has to be processed immediately when received and cannot wait for the release of the authentication key (buffering also represents a significant problem).
  • Single authentication key may seem a viable solution, with little payload and busload, but its main drawback is the low level of security it provides.
  • Compromising only one node of the network will compromise the entire network traffic.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Performance analysis of broadcast authentication
protocols on CAN-FD and FlexRay
Paula Vasile
paula.vasile10@gmail.com
Bogdan Groza
bogdan.groza@aut.upt.ro
Stefan Murvay
stefan.murvay@gmail.com
Politehnica University of Timisoara, Faculty of Automatics and Computers
Department for Automatics and Applied Informatics
Bd. V. Parvan nr. 2, Timisoara, Romania
ABSTRACT
In the light of the numerous reported attacks, designing
cryptographic protocols for in-vehicle embedded networks
was a constant preoccupation in the past few years. While
several research proposals appeared, a concrete performance
analysis of such protocols over a realistic network configura-
tion is still absent from the literature. In this work we ad-
dress the performance for various authentication protocols
that were recently proposed for the two most prominent ve-
hicular buses: FlexRay and CAN-FD. While a real-world ve-
hicular network is still out of reach for our work, we achieve
a first step in this direction by using a CANoe based sim-
ulation for these protocols over state-of-the-art automotive
buses. This allows us to draw a more realistic perspective on
the efficiency of existing proposals for bus authentication.
Our results suggest that sharing symmetric keys between
groups of nodes is the most realistic proposal as it creates a
balance between bandwidth efficiency and security level.
Categories and Subject Descriptors
[Security and privacy]: Security in hardware—Embedded
systems security
General Terms
Security
Keywords
broadcast authentication, embedded networks,
CAN-FD, FlexRay
1. INTRODUCTION
Contemporary vehicles are the result of an evolutionary
process that augmented mere mechanical devices with com-
plex electronics and intricate software counterparts. Recent
vehicles have dozens of ECUs (Electronic Control Units)
that implement a plethora of functions dedicated for safety
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear
this notice and the full citation on the first page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee. Request
permissions from Permissions@acm.org.
WESS’15, October 04-09, 2015, Amsterdam, Netherlands
Copyright 2015 ACM ISBN 978-1-4503-3667-3/15/10 ...$15.00
DOI: http://dx.doi.org/10.1145/2818362.2818369 .
critical tasks, e.g., braking and stability control, or mere
informational purposes to make a more pleasurable driving
experience. Of course, behind these miniature computers
called ECUs, a complex network infrastructure needs to be
deployed that connects these ECUs via cables and unavoid-
ably exposes information to the outsiders via various ports,
e.g., OBD (On-Board Diagnostics), or even wireless chan-
nels, e.g., WiFi, Bluetooth, 3G, etc. There are little doubts
that in terms of attacks and defenses vehicular networks will
evolve in a similar manner to computer networks. A solid
proof for this are the countless attacks that were published
in the recent years [9], [2].
The academic research community was quick to react with
various proposals for assuring security on vehicular buses
(these are all surveyed in a forthcoming section). However,
a comprehensive performance analysis of these solutions on
a real-world vehicular network is still missing. The reason
behind this is quite simple, in-vehicle infrastructures are still
subject to many proprietary solutions and architectural de-
tails that are not fully accessible to academic researchers. In
this work we take a first step in this direction by using the in-
dustry standard CANoe tool in order to simulate a realistic
state-of-the-art network based on FlexRay and CAN-FD.
1.1 State-of-the-art in-vehicle buses: FlexRay
and CAN-FD
The reasons for choosing these buses are clear: CAN is the
most common bus inside cars and FlexRay was designed as
its successor. Due to inherent expenses, FlexRay had not
yet entered in all vehicles and a direct successor of CAN
also emerged, i.e., CAN-FD (Controller Area Network with
Flexible Data-rate). We give next a brief description of these
two communication layers.
FlexRay is an automotive communication protocol de-
veloped by the FlexRay Consortium which gathers impor-
tant players in the automotive industry. It was designed as
a faster and more reliable alternative to other automotive
communication protocols existing at that time, e.g., CAN or
LIN. The protocol supports data rates up to 10 Mbit/s and
a data payload length of 254 bytes. The data is transmitted
between ECUs in the form of frames which have the struc-
ture presented in Figure 1. The bit-length of the fields are
displayed below, the only exception being the data field for
which the length is represented in bytes. FlexRay frames can
be either time-triggered (static frames) or event-triggered
(dynamic frames). FlexRay accomplishes the use of both
static and dynamic frames by employing a predefined com-
munication cycle (Figure 1) which defines specific segments

Identifier
Cycle
count
Data field
CRC
5
11
7 6
11
0-254 bytes
8 8 8
FlexRay frame
Payload
length
Header
CRC
Status
bits
CRC CRC
Static
segment
Static
segment
Dynamic
segment
Symbol
window
Static
segment
Symbol
window
Dynamic
segment
Dynamic
segment
N
I
T
N
I
T
Cycle n
Cycle n+1 Cycle n+2
FlexRay communication cycle
Figure 1: FlexRay frame and communication cycle
for static and dynamic data. The communication cycle con-
tains an additional Symbol Window which typically holds
network maintenance data and signals for network start-up.
A Network Idle Time is used at the end of each commu-
nication cycle to maintain synchronization. The space for
static and dynamic data is configured during the network
design step. In our experimental FlexRay network, all the
FlexRay frames were configured as static, so they are being
sent cyclically with variable recurrences.
As a downside, FlexRay is more expensive and complex.
Therefore, it is mainly used in the safety critical applications
of an automobile where strict message transmission timings
are enforced such as the power train domain.
CAN-FD (CAN with Flexible Data Rate) [16] is a proto-
col designed by Robert Bosch GmbH to extend the stan-
dard CAN protocol [15]. It was developed as a result of
the increasing demand for higher bandwidth. Figure 2 illus-
trates the differences between a standard CAN frame and a
CAN-FD frame. The length in bits of each field is indicated
below the frame representation. While the standard CAN
only supports payloads of maximum 8 bytes, CAN-FD can
accommodate up to 64 bytes of data. For achieving data
rates higher than the 1Mbit/s limit in standard CAN, the
CAN-FD specification introduces the possibility to switch
the baudrate of the data field by setting the BRS (Bit Rate
Switch) bit. Speeds of up to 8 MBit/s can be obtained for
the data phase, resulting in an average speed for the en-
tire frame of 2.5 MBit/s [7]. For backward compatibility
CAN-FD allows the transmission of standard CAN frames.
This is controlled by the EDL (Extended Data Length) bit
which should be set to a dominant state for CAN. Recently,
CAN-FD received the ISO status [8] and was subject to small
changes in order to increase its reliability, i.e., the CRC eld
was extended for improved detection of communication er-
rors [12]. These modifications do not affect the results from
this work. In our experimental network, all the CAN-FD
messages are configured to be sent cyclically with a recur-
rence of 5 up to 80 ms.
2. PROPOSED PROTOCOLS, A SYNTHETIC
COMPARISON
This section contains an overview of recently proposed
protocols for assuring authentication in automotive networks.
A synthetic performance comparison of the presented pro-
tocols follows, we then take this comparison to the experi-
mental level on our experimental network topology with the
help of the CANoe simulation.
Idle
S
O
F
Identifier
R
T
R
I
D
E
DLC
r
Data field
CRC
D
E
L
A
C
K
D
E
L
EOF
1 11 1 1 1
4 0-64
15
1 1 1
7
Idle
S
O
F
Identifier
r1
I
D
E
DLC
E
D
L
Data field
CRC
D
E
L
A
C
K
D
E
L
EOF
r0
B
R
S
E
S
I
1 11 1 1 1
4
1 1 1
0-512
21/25
1 1 1
7
CAN frame
CAN-FD frame
Figure 2: CAN frame versus CAN-FD frame
2.1 Brief overview of recent proposals
We now enumerate some of the recent proposals, subse-
quently, they are revisited from a key allocation perspective
which is decisive for the performance evaluation that follows.
1. Voting schemes [17], [18], [19] require nodes to be
present and vote on the authenticity of messages. This
does not only require nodes to be present on the bus
but also for a message to accumulate a sufficient num-
ber of votes which introduces additional delays. More-
over, the receive history of the nodes has to match.
These restrictions seem not to be appropriate for in-
vehicle networks, a reason for which we do not consider
the scheme for our analysis.
2. TESLA [14] is an efficient broadcast protocol employed
in wireless sensor networks [13]. Implementing this
protocol on the CAN bus was considered in [4]. There
is a significant drawback in adopting it for in-vehicle
networks and this is the authentication delay which is
always present in such protocols. The problem is not
only that messages can be authenticated with some de-
lay, e.g., usually 1–10 ms, but the node has to buffer all
messages and authentication tags received in this time
slot for subsequent authentication (this raises mem-
ory concerns). However, insofar TESLA is the only
way for assuring full broadcast authentication without
more expensive public-key cryptographic primitives,
e.g., digital signatures. For this reason, we consider
this protocol as a candidate for our analysis.
3. CANAuth is a scheme that proposes the use of an ID-
oriented key allocation [20]. The drawback behind this
scheme is that the IDs which are broadcast on a CAN
bus are generally too numerous to allow the allocation
of a key for each ID. Moreover, sharing the key with
nodes that are allowed to receive a particular ID (in
order to be able to authenticate the messages) exposes
the security key to nodes that can be potentially ma-
licious (e.g., a corrupted diagnosis tool). However, the
ID-oriented allocation nicely fits the specification of
CAN. Moreover, by adding a single authentication tag
to each of the broadcast message this scheme provides
a baseline for efficiency as it leads to a simple one-tag-
per-message authentication. As proposed in [20] the
protocol was intended for CAN+, a variation of CAN
that currently does not exist in practice. But the pro-
tocol can be ported as is on any other layer, e.g., CAN
or CAN-FD.
4. MaCAN is proposed in [6]. The protocol has the merit

of being a realistic proposal, it employs shared keys
between nodes and CBC-MAC based authentication
tags. There are not enough details on how to share
the keys between the nodes, except for the fact that
these should be shared in a pair-wise manner (this is
not suitable for higher number of nodes). The authors
of MaCAN [6] suggest that nodes can be grouped un-
der the same key if they share the same trust level
which will lead to a reasonable number of keys, but no
practical insights are given on how to decide the trust
level.
5. LiBrA-CAN [5] proposes a more demanding key allo-
cation procedure which mixes keys between groups of
nodes (rather then sharing keys pair-wisely). The pro-
posal is more demanding from a computational point
of view, but it offers a higher security level in case
when adversaries are in minority (a likely scenario for
in-vehicle networks).
6. CaCAN [10] introduces a centralized view over the au-
thentication process. In this protocol a central node
verifies the authentication tag of each frame and if
authentication fails, the frame is discarded with er-
ror flags. This procedure has the merit of requiring a
single monitor node with higher computational power.
However, an adversary that removes this node from
the bus can take full control of the bus since there
is no way for the other nodes to decide if a frame is
authentic or not.
7. Other symmetric key schemes were discussed in [22],
[21], [1], [11] but the way in which keys and tags are
allocated seems to fit in one of the previous paradigms
and thus we do not consider them as separate cases for
our simulation.
2.2 Revisiting protocols from a keying perspec-
tive
While in the previous subsection we encountered several
proposals, the crux of the problem (and the difference be-
tween the previous schemes) comes from the way in which
the keys are distributed between the nodes. It is clear that
only symmetric key primitives can be used, due to restric-
tions on computational power and bandwidth, and thus the
number of authentication tags (which determines the bus-
load) comes from the way in which keys are allocated. We
now revisit the previous proposals and classify them based
on the keying procedure they employ. Mutatis mutandis,
all of the previous schemes fit in one of the following four
paradigms:
1. Single authentication key is the simplest keying pro-
cedure in which all frames are authenticated with a
single key. In this case, all senders and receivers must
be in possession of the authentication key and if one
of them is corrupted all security is lost. Since each
frame carries a single tag, this protocol provides a base-
line for the bus-load (from this perspective both CA-
NAuth [20] and CaCAN [10] fit into this paradigm).
ID-oriented keying is a variation of this in which each
frame carries a single authentication tag, but the key
to compute this tag is unique for each of the IDs. This
procedure is explored in CANAuth [20]. As already
noted in previous work, usually there are too many
IDs to have a unique key for each of them, but this
requirement can be relaxed by having a unique key
for each group of frames that is selected based on a
predefined mask. From the bus-load perspective this
protocol has identical requirements to the previous (a
single tag again) and thus it matches the baseline for
the bus-load when a single authentication key is used.
2. Pairwise keying is the rather natural way in which
unique authentication keys are shared by each dis-
tinct pair of nodes. This procedure is also employed
in MaCAN [6]. However, in case of n nodes this leads
to
n(n1)
2
keys and n 1 authentication tags. For
higher number of nodes, the overhead is unlikely to be
handled by the available bandwidth and computation
power available in automotive networks. For this rea-
son, in related work, e.g., [6], it was already suggested
that nodes that share the same trust level can use the
same secret key for authentication. In some sense, this
opens door for the next procedure.
3. Group keying is an improvement over pairwise key
sharing that allocates keys over groups of nodes. The
main ideea is to build groups that have an intermediate
size between 2 (which corresponds to pairwise keying)
and n (which corresponds to having a single authen-
tication key in case of n nodes). The security level is
higher if malicious nodes are in minority, the proce-
dure is explored in LiBrA-CAN [5]. Worst than in the
previous case, the number of keys and tags grows ex-
ponentially, but again if more nodes are grouped under
the same key (as in the case of pair-wise keying) then
the number of keys stays low.
4. TESLA-like keying requires authentication keys to be
broadcast in a periodic manner, i.e., at fixed time in-
tervals. This means that besides the regular frames
that are sent over the network a frame containing the
key is released at fixed intervals. However, the prob-
lem of the protocol is not necessarily in the additional
overhead but in buffering the received frames until the
authentication key is received and in the intrinsic au-
thentication delay.
For the case of shared keys, i.e., all protocols except TESLA,
in order to draw a synthetic comparison we need to fix the
following parameters for a setup with n receivers in groups
of size g:
the total number of keys:
K =
n
g
!
,
the total number of keys stored on a single node which
is also the number of tags computed by the node when
sending a message to all of the other nodes:
K
send
=
n 1
g 1
!
,

the total number of tags intended for a single receiver
which is also the computational load on the receiver
side:
K
recv
=
n 2
g 2
!
,
the fraction of tags intended for a single node out of
the total number of tags:
F
recv
=
n 2
g 2
!
n 1
g 1
!
1
=
K
node
recv
K
node
send
,
the size of the tag for a security level of ` bits:
S = `
n 2
g 2
!
1
n 1
k 1
!
= ` · F
1
recv
,
the fraction of uncorrupted tags for a single receiver in
case of m corrupted nodes:
F
corr
recv
=
n2m
g2
n1
g1
,
the security level in case of m corrupted nodes which
is the fraction of uncorrupted security bits for a single
receiver:
`
corr
= S · F
corr
recv
.
In this formalism, the case when the size of the subgroup is
g = n corresponds to the case of a single authentication key
while g = 2 corresponds to the case of pair-wise key sharing.
In terms of bandwidth, the ID-oriented keying and TESLA-
like keying overlaps with the case of a single authentication
key. We can now draw a synthetic comparison.
In Figures 3 and 4 we depict the size of the tag as well
as the remaining uncompromised bits in case of 1 corrupted
node with n = 8. It is easy to note that when a single
key is used, i.e., n = 8, g = 8, the size of the resulting au-
thentication tag is kept at a minimum, i.e., 128 bits for a
security level of 128 bits. In the same case however, if a sin-
gle node is corrupted the number of uncorrupted bits drops
to 0; since all nodes share the same key. Sharing the keys
pair-wisely leads to no security loss in case of 1 corrupted
node, as each two nodes share a distinct key, however for a
security level of 128 bits the tag quickly grows to 896 bits
(the plot is truncated at 250 bits since tags larger than this
are clearly not suited for real-time communication on an em-
bedded network). Finally, having groups of size 3 or 4 gives
a nice trade-off between these values.
Figure 5 compares the number of keys on each node, tags
computed by each node and tags verified by each node. For
the extreme case of group size 2 and 8 these values are the
lowest but with the aforementioned disadvantage that either
the tag is too large, i.e., g = 2, or security is lost when one
node is compromised, i.e., g = 8.
8
8e4sdffd
88888888
8888888
8888888
8888888
8888888
8888888 tag size (bits)
g=7
g=6
g=2
g=3
g=5
888888816
888888832
888888 64
888888 128
888888 192
Figure 3: Tag size for a security level of 8 up to 192
bits with n=8 and g=2,3...8
8
16
32
64
128
192
uncorrupted bits
(
)
g=8
g=7
g=6
g=5
g=4
g=3
g=2
Figure 4: Uncorrupted bits in case of 1 corrupted
node for a security level of 8 up to 192 bits with n=8
and g=2,3...8
group
size
0
20
40
60
80
no.
.
2
3
4
5
6
7
8
no. keys
keys per node
keys for node
Figure 5: Comparison on the number of keys, num-
ber of computed tags and number of verified tags
with n=8 and g=2,3...8
3. EXPERIMENTAL EVALUATION
We begin by discussing the topology of the network and
some issues regarding the protocol, then we proceed to the
experimental results.
3.1 Network topology
The network topology discussed below stays at the core of
our CANoe based simulation. The networks were designed
to comply with real-world in-vehicle networks used by the
automotive industry, in order to obtain experimental results

Network
(FlexRay/CAN-
FD)
ECU_15ECU_14
ECU_30ECU_29
ECU_3ECU_2
ECU_18
ECU_16
ECU_17
ECU_1
ECU_13
ECU_28
Figure 6: Network topology
that are as close as possible to the real-world behaviour.
Figure 6 depicts the experimental network topology con-
sisting of 30 ECUs. All nodes are interconnected using the
same bus type, thus, separate simulations were built for each
bus type (FlexRay and CAN-FD) on the same topology.
The number of ECUs was chosen to represent the maximum
number of ECUs specified by the High Speed ISO 11898
Standard for a CAN network having a maximum signalling
rate of 1Mbps and a bus length of 40 m [3]. By relying on
the same topology for both FlexRay and CAN-FD, we want
to give a crisp image on the difference in performance for
each bus type under the same authentication protocol. This
of course complements the image over the protocols perfor-
mance that can be individually drawn for each bus type.
Network
(FlexRay/
CAN-FD)
ECU_10ECU_8ECU_5
ECU_14ECU_11 ECU_12
ECU_13ECU_9ECU_7
ECU_22ECU_16
ECU_20ECU_4
ECU_25
ECU_23
ECU_24
ECU_3
ECU_21
ECU_26ECU_1
ECU_29ECU_27
Group 1
(2137,5 frames/second)
ECU_15ECU_6
ECU_19ECU_17 ECU_18
ECU_2
ECU_30
ECU_28
Group 2
(2178,125 frames/second)
Group 3
(2125 frames/second)
Group 4
(2131,25 frames/second)
Group 5
(2162,5 frames/second)
Figure 7: Grouping of ECUs into clusters
Protocols relying on group keying require special attention
as nodes need to be further grouped. The 30 ECUs forming
the network presented in Figure 6 are organized in 5 clusters.
Each group should gather nodes that share the same trust
level as they will be in possession of the same key. Since
there are not many hints on how this decision should be
taken (in the absence of manufacturer specifications), the
allocation scheme that we opted for was to obtain a balanced
number of frames transmited by each group (this can be seen
at least as a secondary, more practical criteria). The bus-
load based grouping is depicted in Table 1. Thus, each of
the 5 clusters generates approximately the same load on the
bus. Figure 7 shows the way in which we now group the
ECUs on our network.
Group ECU Frames/
second/
ECU
Frames/ second/ Group
1 ECU 29 600
ECU 27 500
ECU 30 425
ECU 26 200
ECU 1 412.5 2137.5
2 ECU 10 625
ECU 11 325
ECU 12 425
ECU 5 200
ECU 8 403.125
ECU 14 200 2178.125
3 ECU 15 406.25
ECU 17 225
ECU 18 362.5
ECU 6 425
ECU 19 206.25
ECU 2 500 2125
4 ECU 7 206.25
ECU 16 350
ECU 22 106.25
ECU 13 350
ECU
9 400
ECU 28 750 2162.5
5 ECU 20 206.25
ECU 21 325
ECU 4 200
ECU 23 425
ECU 24 362.5
ECU 25 212.5
ECU 3 400 2131.25
Table 1: Busloads for each group of ECUs
3.2 Comparative results
The comparative evaluation of the protocols can account
for two distinct characteristics: the bandwidth (which de-
pends on the number and size of the authentication tags)
and the computational load on each ECU (which depends
on the number of tags that each sender/receiver has to com-
pute/verify each second). Our bus simulation is of course
focused on the first aspect. The computational load is not
to be neglected, however since hardware implementations
are available for cryptographic primitives, e.g., AES, and
message authentication primitives, e.g., CBC-MAC, can be
straight-forwardly derived, the concerns on computational
power are little. As a rough baseline, a hardware implemen-
tation will allow for an authentication tag to be computed in
several micro-seconds, while even a software implementation
on a high-grade ECU, e.g., Infineon TriCore, will cost in the
order of a dozen micro-seconds, allowing each node to pro-
cess tens of thousands of authentication tags each second.
This quantity however, cannot be handled by the available
bandwidth if each node is assumed to send the maximum
number of tags it can compute. If needed, computational
concerns can be subject of future work for us, for the mo-
ment the maximum computational load seems to stay below
10.000 tags/second as will be further shown.

Citations
More filters
Journal ArticleDOI
TL;DR: A three-layer framework (sensing, communication and control) through which automotive security threats can be better understood is proposed, which provides the state-of-the-art review on attacks and threats relevant to the communication layer and presents countermeasures.

152 citations

Proceedings ArticleDOI
01 Sep 2017
TL;DR: The most promising CAN message authentication solutions are identified and a comprehensive overview of them are provided and it is found that none of them meet all the requirements, and that backward compatibility and acceptable overhead are the biggest obstacles.
Abstract: Vehicles have evolved from mostly mechanical machines into devices controlled by an internal computer network consisting of more than 100 interconnected Electronic Control Units (ECUs). Moreover, modern vehicles communicate with external devices to enable new features, but these new communication facilities also expose safety-critical functions to security threats. As the most prevalent automotive bus, the Controller Area Network (CAN) bus is a prime target for attacks. Even though the computer security community has proposed several message authentication solutions to alleviate those threats, such solutions have not yet been widely adopted by the automotive industry. We have identified the most promising CAN message authentication solutions and provide a comprehensive overview of them. In order to investigate the lack of adoption of such solutions, we, together with industry experts, have identified five general requirements they must fulfill in order to be considered viable in industry. Based on those requirements, we analyze and evaluate the identified authentication solutions. We find that none of them meet all the requirements, and that backward compatibility and acceptable overhead are the biggest obstacles.

31 citations


Cites background or methods from "Performance analysis of broadcast a..."

  • ...[6] for the discussion of acceptable overhead....

    [...]

  • ...[6] shows that the overhead of MaCAN is...

    [...]

  • ...While researchers have proposed several solutions for securing in-vehicle networks, few, if any, have been adopted in practice [5], [6]....

    [...]

  • ...[6] assume that a single key is used with CaCAN, and under that assumption...

    [...]

  • ...[6] suggest that for solutions with pairwise keying, such as...

    [...]

Proceedings ArticleDOI
01 Dec 2019
TL;DR: This work uses implicit certificates to derive authenticated message-based group keys for ECUs that can be used for authentication and encryption as proposed in already existing works and implements the proposed lightweight scheme on constrained devices that are connected over CAN, proving that the solution is applicable for the automotive domain.
Abstract: In the last years, researchers have exposed vulnerabilities on modern road vehicles that may have severe safety implications. Specifically, the most popular in-vehicle communication protocol CAN is prone to spoofing attacks. As a consequence, various security frameworks have been published, in order to both authenticate and encrypt data on vehicular buses. However, key management has often been neglected. Cryptographic keys are frequently hard coded, their authenticity is not verified and key updates are not possible at all. Contemporary ECUs are usually resource-constrained devices without the necessary hardware support to securely store cryptographic keys. This is why lightweight techniques for regular key updates are required. In this work, we use implicit certificates to derive authenticated message-based group keys for ECUs. These keys can subsequently be used for authentication and encryption as proposed in already existing works. In case a key gets corrupted, our approach enables fast key updates. We implement the proposed lightweight scheme on constrained devices that are connected over CAN, hence proving that our solution is applicable for the automotive domain. Our measurements show that a key update takes roughly 27ms after initialization.

16 citations


Cites background or methods from "Performance analysis of broadcast a..."

  • ...We consider our scheme as a preceding step to the numerous frameworks [3], [8]– [10], [18] that have been presented in recent years, in order to authenticate and encrypt in-vehicle traffic....

    [...]

  • ...[10] evaluate four different keying paradigms for automotive broadcast authentication protocols....

    [...]

  • ...As stated in [10], this key strategy is the most...

    [...]

Proceedings ArticleDOI
09 May 2016
TL;DR: A complete migration of CAN authentication protocol towards FlexRay shows the availability of the protocol over different technologies and believes that migration era is near enough to change mindset in order to supply industry with complete and mature security proposals with FlexRay.
Abstract: In-vehicle network security is becoming a major concern for the automotive industry. Although there is significant research done in this area, there is still a significant gap between research and what is actually applied in practice. Controller area network (CAN) gains the most concern of community but little attention is given to FlexRay. Many signs indicate the approaching end of CAN usage and starting with other promising technologies. FlexRay is considered one of the main players in the near future. We believe that migration era is near enough to change our mindset in order to supply industry with complete and mature security proposals with FlexRay. This changing mindset is important to fix the lagging issue appeared in CAN between research and industry. Then, we provide a complete migration of CAN authentication protocol towards FlexRay shows the availability of the protocol over different technologies.

14 citations


Cites background from "Performance analysis of broadcast a..."

  • ...A comparison between these security protocols and others is proposed in [17]....

    [...]

  • ...[17] shows that key grouping is the most powerful candidate; where the fatal problem introduced by the single key is not presented....

    [...]

Proceedings ArticleDOI
05 May 2019
TL;DR: This work demonstrates that the optional dualchannel mode can be used to provide authentication for FlexRay in a backward compatible manner and proposes a number of techniques for managing cryptographic keys, i.e. associate these keys with FlexRay time slots and use hash chains to derive new keys at low cost at runtime.
Abstract: Recently, researchers have demonstrated how the lack of security features in road vehicles may allow adversaries to take over partial or even full control. Specifically, in-vehicle communication protocols are prone to attacks, because no security mechanisms have been developed for them. For a long time, they have been optimized only towards safety, in order to guarantee a high degree of reliability, robustness and real-time behavior. In this work, we focus on FlexRay, an automotive communication protocol whose core properties are strong determinism and high fault-tolerance for safety-critical applications. We propose to leverage the distinct safety-tailored features of FlexRay for security purposes, such as authentication. In particular, we demonstrate that the optional dualchannel mode can be used to provide authentication for FlexRay in a backward compatible manner. Additionally, we suggest different ways of transmitting the relevant message authentication codes over FlexRay. Finally, we propose a number of techniques for managing cryptographic keys, i.e. we associate these keys with FlexRay time slots and we use hash chains to derive new keys at low cost at runtime. In this way, we offer multiple security solutions for the FlexRay protocol, while trying to keep the overhead low.

12 citations


Cites background from "Performance analysis of broadcast a..."

  • ...[19] compared different key distribution schemes for ECUs....

    [...]

References
More filters
Journal Article
TL;DR: This chapter identifies the vulnerabilities associated with the operational paradigms currently employed by Wireless Sensor Networks and a framework for implementing security in WSNs, which identifies the security measures necessary to mitigate the identified vulnerabilities.
Abstract: This chapter identifies the vulnerabilities associated with the operational paradigms currently employed by Wireless Sensor Networks. A survey of current WSN security research is presented. The security issues of Mobile Ad-Hoc Networks and infrastructure supported wireless networks are briefly compared and contrasted to the security concerns of Wireless Sensor Networks. A framework for implementing security in WSNs, which identifies the security measures necessary to mitigate the identified vulnerabilities is defined.

2,939 citations


"Performance analysis of broadcast a..." refers methods in this paper

  • ...TESLA [14] is an efficient broadcast protocol employed in wireless sensor networks [13]....

    [...]

Proceedings ArticleDOI
16 Jul 2001
TL;DR: A suite of security building blocks optimized for resource-constrained environments and wireless communication, and shows that they are practical even on minimal hardware: the performance of the protocol suite easily matches the data rate of the network.
Abstract: As sensor networks edge closer towards wide-spread deployment, security issues become a central concern. So far, much research has focused on making sensor networks feasible and useful, and has not concentrated on security.We present a suite of security building blocks optimized for resource-constrained environments and wireless communication. SPINS has two secure building blocks: SNEP and mTESLA SNEP provides the following important baseline security primitives: Data confidentiality, two-party data authentication, and data freshness. A particularly hard problem is to provide efficient broadcast authentication, which is an important mechanism for sensor networks. mTESLA is a new protocol which provides authenticated broadcast for severely resource-constrained environments. We implemented the above protocols, and show that they are practical even on minimal hardware: the performance of the protocol suite easily matches the data rate of our network. Additionally, we demonstrate that the suite can be used for building higher level protocols.

2,703 citations

17 Aug 2003
TL;DR: The provided compressed bitstreams were uncompressed using provided software and the resulting sequences were compared to the original ones in terms of PSNR and it seems that last frames from some cameras give significantly worse PSNR than the rest of frames.
Abstract: The provided compressed bitstreams were uncompressed using provided software and the resulting sequences were compared to the original ones in terms of PSNR. Additionally, the sequence Ballroom was compressed using the provided software. Resulting bitstreams were processed as the ones provided by Sejong/ETRI to verify the whole chain of coding and decoding. The results obtained at Poznań University of Technology are included in the accompanying Excel file. They are the same as the ones provided by Sejong/ETRI, except for sequences Race1 and Flamenco2 results. The results for them are slightly worse than the ones presented by Sejong/ETRI. The difference is less than 0.05 dB. It seems that last frames from some cameras give significantly worse PSNR (about 10dB less than the rest of frames). The cause of this difference is unknown.

2,092 citations

Proceedings ArticleDOI
16 May 2010
TL;DR: It is demonstrated that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems and present composite attacks that leverage individual weaknesses.
Abstract: Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks. While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure. We demonstrate that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. Over a range of experiments, both in the lab and in road tests, we demonstrate the ability to adversarially control a wide range of automotive functions and completely ignore driver input\dash including disabling the brakes, selectively braking individual wheels on demand, stopping the engine, and so on. We find that it is possible to bypass rudimentary network security protections within the car, such as maliciously bridging between our car's two internal subnets. We also present composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car's telematics unit and that will completely erase any evidence of its presence after a crash. Looking forward, we discuss the complex challenges in addressing these vulnerabilities while considering the existing automotive ecosystem.

1,463 citations

Proceedings Article
08 Aug 2011
TL;DR: This work discovers that remote exploitation is feasible via a broad range of attack vectors (including mechanics tools, CD players, Bluetooth and cellular radio), and further, that wireless communications channels allow long distance vehicle control, location tracking, in-cabin audio exfiltration and theft.
Abstract: Modern automobiles are pervasively computerized, and hence potentially vulnerable to attack. However, while previous research has shown that the internal networks within some modern cars are insecure, the associated threat model--requiring prior physical access--has justifiably been viewed as unrealistic. Thus, it remains an open question if automobiles can also be susceptible to remote compromise. Our work seeks to put this question to rest by systematically analyzing the external attack surface of a modern automobile. We discover that remote exploitation is feasible via a broad range of attack vectors (including mechanics tools, CD players, Bluetooth and cellular radio), and further, that wireless communications channels allow long distance vehicle control, location tracking, in-cabin audio exfiltration and theft. Finally, we discuss the structural characteristics of the automotive ecosystem that give rise to such problems and highlight the practical challenges in mitigating them.

1,370 citations


"Performance analysis of broadcast a..." refers background in this paper

  • ...A solid proof for this are the countless attacks that were published in the recent years [9], [2]....

    [...]

Frequently Asked Questions (1)
Q1. What have the authors contributed in "Performance analysis of broadcast authentication protocols on can-fd and flexray" ?

In the light of the numerous reported attacks, designing cryptographic protocols for in-vehicle embedded networks was a constant preoccupation in the past few years. In this work the authors address the performance for various authentication protocols that were recently proposed for the two most prominent vehicular buses: FlexRay and CAN-FD. While a real-world vehicular network is still out of reach for their work, the authors achieve a first step in this direction by using a CANoe based simulation for these protocols over state-of-the-art automotive buses. Their results suggest that sharing symmetric keys between groups of nodes is the most realistic proposal as it creates a balance between bandwidth efficiency and security level.