1
00:00:00,000 --> 00:00:14,524
preroll music
2
00:00:14,524 --> 00:00:18,570
Camille Gay: Hello, everyone. My name is Camille. I am
a researcher at Toyota Motor Corporation,
3
00:00:18,570 --> 00:00:21,910
and this is a presentation about RAMN, a
platform that we developed to make
4
00:00:21,910 --> 00:00:27,651
education and research in the automotive
systems more accessible. The automotive
5
00:00:27,651 --> 00:00:31,920
industry can be inaccessible to many
people because automotive projects involve
6
00:00:31,920 --> 00:00:37,551
prohibitive costs and be tied to NDAs that
everybody is going to sign. What we want
7
00:00:37,551 --> 00:00:41,530
to propose with this project is an
inexpensive test bed to study and research
8
00:00:41,530 --> 00:00:45,649
automotive systems, which is both open
source and developed with open source
9
00:00:45,649 --> 00:00:50,100
tools so that at least anyone can get
access to a good alternative for education
10
00:00:50,100 --> 00:00:55,160
and research. The main focus of this test
bed is security, but you will see that the
11
00:00:55,160 --> 00:00:59,540
usage of the test bed is not limited to
security, and I will keep the security
12
00:00:59,540 --> 00:01:06,390
talk mostly for the end of the
presentation. I will start by giving a
13
00:01:06,390 --> 00:01:10,860
short introduction about automotive
systems. Then I will present the design
14
00:01:10,860 --> 00:01:15,180
details of the test bed besides
demonstrations and concrete details about
15
00:01:15,180 --> 00:01:20,909
its hardware and software. As an example
of how the test bed can be used, I will
16
00:01:20,909 --> 00:01:25,010
spend some time experimenting with cruise
control and by that I mean I will go
17
00:01:25,010 --> 00:01:28,770
through the whole development process,
starting from evaluating the differential
18
00:01:28,770 --> 00:01:33,670
equations of a simple mechanical model. I
will experiment with various control
19
00:01:33,670 --> 00:01:38,600
strategies, implement them in C and make
measurements in a driving simulator using
20
00:01:38,600 --> 00:01:46,000
only data from the CAN bus. And I will do
all that using only open source tools.
21
00:01:46,000 --> 00:01:49,409
This is to demonstrate how the test bed
can be used, but also to have a concrete
22
00:01:49,409 --> 00:01:53,780
project that I can use as a reference to
explain after what concretely would have
23
00:01:53,780 --> 00:01:58,290
been different if we were experimenting
with a real electronic control unit. I
24
00:01:58,290 --> 00:02:02,770
will also explain how we can get close to
automotive hardware and software without
25
00:02:02,770 --> 00:02:07,110
signing NDAs. So the second part of the
talk is mainly here to give you more
26
00:02:07,110 --> 00:02:11,129
information about the automotive industry
in case you are not familiar with it.
27
00:02:11,129 --> 00:02:15,860
Before I start, let me just clarify that
this is not an advertisement. We are not
28
00:02:15,860 --> 00:02:20,340
selling anything we present here and do
not profit financially from it. We're
29
00:02:20,340 --> 00:02:23,700
simply showing design files whithout
permising licenses and without
30
00:02:23,700 --> 00:02:29,870
royalties. OK, so first, let me give you a
very quick introduction about automotive
31
00:02:29,870 --> 00:02:34,849
systems. You can see your car as a
collection of systems divided in four
32
00:02:34,849 --> 00:02:38,230
different domains, the powertrain domain,
which includes the engine and the
33
00:02:38,230 --> 00:02:41,739
transmission. The chassis domain, which
includes the steering column and
34
00:02:41,739 --> 00:02:45,710
suspensions. The body domain, which
includes the lights, the doors and
35
00:02:45,710 --> 00:02:50,109
heating, and the infotainment domain,
which includes navigation and
36
00:02:50,109 --> 00:02:56,669
connectivity. Many of the different
systems that can be found in the car are
37
00:02:56,669 --> 00:03:01,640
controlled by electronic control units or
ECUs for short. There are many kinds of
38
00:03:01,640 --> 00:03:05,706
ECUs in the car. Sometimes hundreds of
them. And usually it's a lot hard to
39
00:03:05,706 --> 00:03:09,579
understand. They have a limited number of
inputs, generally data from sensors and
40
00:03:09,579 --> 00:03:15,930
actuators. And they have a limited number
of outputs generally to control actuators.
41
00:03:15,930 --> 00:03:21,079
So, for example, an airbag ECU may use an
accelerometer as its input and an airbag
42
00:03:21,079 --> 00:03:25,089
trigger as its output. The role of the ECU
would be to use data from the
43
00:03:25,089 --> 00:03:32,150
accelerometer to detect a shock and output
a signal as actuator to detonate an airbag
44
00:03:32,150 --> 00:03:38,930
when the shock is detected. It is very
common for ECUs to read data from other
45
00:03:38,930 --> 00:03:44,309
ECUs. Most of the time ECUs will need to
share data with other ECUs on the same
46
00:03:44,309 --> 00:03:48,799
domain. In the case of [unclear],
for example the transmission control unit
47
00:03:48,799 --> 00:03:53,610
gets input from the engine ECU to
determine the correct gear. If the data is
48
00:03:53,610 --> 00:03:58,599
critical that connection may even be
redundant. ECUs may also need to
49
00:03:58,599 --> 00:04:02,849
communicate with ECUs on a different
domain. For example the brake system,
50
00:04:02,849 --> 00:04:06,900
usually in the chassis domain, willl need to
communicate its data to store them, usually
51
00:04:06,900 --> 00:04:11,379
in the body domain. Most of the time the
technology that is used for communication
52
00:04:11,379 --> 00:04:16,720
is CAN. And CAN technology uses a bus
topology, which means a CAN message will
53
00:04:16,720 --> 00:04:21,310
be received by all ECUs on the same CAN
bus, there is no authentication or
54
00:04:21,310 --> 00:04:26,030
encryption at the link layer. So any
message can be sent by any ECU. And
55
00:04:26,030 --> 00:04:32,280
security features need to be implemented
at higher layers. A standard CAN frame
56
00:04:32,280 --> 00:04:38,330
consist mainly of an arbitration ID of 11
bits and a payload of 8 bytes. CAN-FD is a
57
00:04:38,330 --> 00:04:46,714
recent evolution of CAN where the payload
size may be extended up to 64 bytes. For
58
00:04:46,714 --> 00:04:51,210
an ECU network manufacturers will assign a
meaning to each arbitration ID and each
59
00:04:51,210 --> 00:04:54,960
bit in the payload, so the file that
determines the traffic on the CAN bus is
60
00:04:54,960 --> 00:05:01,020
often referred to as a DBC file. For
example, assuming a lamp controller and
61
00:05:01,020 --> 00:05:06,750
two lamps on the CAN bus. The manufacturer
may decide that ID 123 is used by the lamp
62
00:05:06,750 --> 00:05:12,180
controller to communicate the command of
both lamps, that ID 124 is used by the
63
00:05:12,180 --> 00:05:17,680
left lamp to give feedback about the
status and that ID 125 is used by the
64
00:05:17,680 --> 00:05:23,050
right lamp to give feedback about its
status. Each of those messages will be
65
00:05:23,050 --> 00:05:27,830
broadcasted periodically by the assigned
ECU on the CAN bus and will serve as a
66
00:05:27,830 --> 00:05:36,050
basis for most data exchange between ECUs.
So that's it for the introduction, there
67
00:05:36,050 --> 00:05:40,240
are many reasons why people would be
interested in automotive systems and ECU
68
00:05:40,240 --> 00:05:44,430
networks. The opportunity that gets by far
most attention from the media is
69
00:05:44,430 --> 00:05:49,550
vulnerability research. But there are also
other reasons. For example, owners: They
70
00:05:49,550 --> 00:05:53,789
want to check their car's compliance with
regulations such as emissions regulations
71
00:05:53,789 --> 00:06:01,090
and privacy regulations. For example,
GDPR. Other owners may want to exercise
72
00:06:01,090 --> 00:06:04,939
their rights to repair as they are
guaranteed by the country they live in.
73
00:06:04,939 --> 00:06:09,110
And finally, some owners may want to
experiment and innovative DIY features or
74
00:06:09,110 --> 00:06:14,740
simply satisfy their curiosity and educate
others. And while those may be valid
75
00:06:14,740 --> 00:06:18,629
reasons to experiment with the car,
manufacturers are typically against people
76
00:06:18,629 --> 00:06:22,349
tinkering with a car because they may be
worried about their intellectual property
77
00:06:22,349 --> 00:06:27,300
being stolen, about vulnerabilities being
exploited or people hurting themselves and
78
00:06:27,300 --> 00:06:33,090
others while tinkering. And what probably
suffers the most from this delicate
79
00:06:33,090 --> 00:06:37,340
situation is education and research in
automotive security, because people can
80
00:06:37,340 --> 00:06:41,900
not easily get access to safe equipment or
access the information that they would
81
00:06:41,900 --> 00:06:46,890
need. In the long term, this may mean that
manufacturers will have less security
82
00:06:46,890 --> 00:06:50,410
technologies to choose from to secure
their cars and that less talents would be
83
00:06:50,410 --> 00:06:55,439
available to develop and evaluate them. As
the development, of course, involves many
84
00:06:55,439 --> 00:06:59,302
people from many companies, so it is
important to make sure that everyone
85
00:06:59,302 --> 00:07:05,550
involved is competent in automotive
security. And some people are pushing for
86
00:07:05,550 --> 00:07:10,599
more open sourcing cars and who knows,
maybe one day the car will be 100%
87
00:07:10,599 --> 00:07:17,000
open source, but if it happens, it is
going to take a long time. And
88
00:07:17,000 --> 00:07:20,260
manufacturers themselves do not have
access to a hundred percent of the source
89
00:07:20,260 --> 00:07:25,479
code of the cars they make because ECUs
contain intellectual property from other
90
00:07:25,479 --> 00:07:29,749
companies. So this is mostly a political
topic. So there is not much we can
91
00:07:29,749 --> 00:07:34,790
contribute to as researchers. However what
we can contribute technically right now is
92
00:07:34,790 --> 00:07:38,970
to try the other way around and use what
is publicly available to make it
93
00:07:38,970 --> 00:07:46,659
accessible, to learn and research
automotive systems. And this is what we
94
00:07:46,659 --> 00:07:51,670
try to do with RAMN, which is the topic of
this presentation. The objective is to
95
00:07:51,670 --> 00:07:56,370
provide a platform for research that is:
Open, and by that we mean it should be
96
00:07:56,370 --> 00:08:01,350
easy to modify the source code, and
reprogram the ECUs; Accessible, and by
97
00:08:01,350 --> 00:08:06,400
that we mean inexpensive, small and
requiring no prior skills in automotive
98
00:08:06,400 --> 00:08:11,769
systems; Safe - with no risk of accidents or
legal repercussions; and motivating,
99
00:08:11,769 --> 00:08:15,479
something that you can interact with so
that you get the same kind of experience
100
00:08:15,479 --> 00:08:20,219
as you do when you experiment with a real
car. So already some solutions are
101
00:08:20,219 --> 00:08:23,710
available if you want to experiment with
an ECU network. Besides, of course, a real
102
00:08:23,710 --> 00:08:29,439
car, the first one is making your own test
bed from real ECUs so we can see many
103
00:08:29,439 --> 00:08:33,470
hackers sharing the test bed at security
conferences. And usually if you see
104
00:08:33,470 --> 00:08:37,389
something like this, you stop and you
immediately get interested. So it is a
105
00:08:37,389 --> 00:08:41,690
nice way to motivate people to learn.
Unfortunately, those are not easy to
106
00:08:41,690 --> 00:08:45,290
reprogram because manufacturers do not
share information about the ECUs and they
107
00:08:45,290 --> 00:08:52,850
require a lot of skills to build. So it's
not accessible to everyone. Another option
108
00:08:52,850 --> 00:08:57,690
is to use development boards such as
Arduino, and that is what you can see
109
00:08:57,690 --> 00:09:02,250
mostly on academic papers. They have the
advantage of being reproducible and you
110
00:09:02,250 --> 00:09:06,680
can modify the source code as you want. So
they can be used in many cases for
111
00:09:06,680 --> 00:09:12,000
research. But they lack many safety
features offered on an actual ECU hardware
112
00:09:12,000 --> 00:09:18,870
and software. Even if you are able to
simulate a CAN bus, you don't get the same
113
00:09:18,870 --> 00:09:23,520
level of interaction as you do with a real
car. So it's not something that motivates
114
00:09:23,520 --> 00:09:31,240
people and makes them want to learn more.
And the third option is to use a
115
00:09:31,240 --> 00:09:35,340
professional test bed such as Pasta -
another work from our team. This is a good
116
00:09:35,340 --> 00:09:38,680
option because you get access to the
source code and you can reprogram the ECUs
117
00:09:38,680 --> 00:09:42,670
and the CAN bus network is already
simulating a full car. So the groundwork
118
00:09:42,670 --> 00:09:47,300
is already done. So major drawback are
that it is very expensive. So it is not
119
00:09:47,300 --> 00:09:52,459
accessible to everyone. So there are some
options to study and research automotive
120
00:09:52,459 --> 00:09:56,600
systems, but none of them seem to be both
accessible and motivating at the same
121
00:09:56,600 --> 00:10:00,540
time. So many people don't even think of
running automotive systems because it
122
00:10:00,540 --> 00:10:04,960
never occurred to them that they could
like it. And in comparison with other
123
00:10:04,960 --> 00:10:08,660
industries, you have so many ways to get
started, if you want to learn about Linux,
124
00:10:08,660 --> 00:10:12,180
you can start with a Raspberry Pi. If you
want to learn about electronics you can
125
00:10:12,180 --> 00:10:17,190
start with an Arduino and so on. So we
wanted something that would give a similar
126
00:10:17,190 --> 00:10:26,860
experience, but for automotive systems. So
we noticed that most of the test beds that
127
00:10:26,860 --> 00:10:31,850
people are using to experiment with ECUs
are made of 4 ECUs. So the ECUs are often
128
00:10:31,850 --> 00:10:38,860
communicating with each other using a CAN
bus. So we tried to fit all that in a PCB
129
00:10:38,860 --> 00:10:43,730
the size of a credit card. And we named
that PCB RAMN. It features four ECUs
130
00:10:43,730 --> 00:10:50,370
connected over a common CAN bus or CAN-FD
bus, which is accessible from outside by a
131
00:10:50,370 --> 00:10:58,106
terminal block. One of the ECUs is also
connected to USB, which is also the power
132
00:10:58,106 --> 00:11:02,389
supply. PIN-sockets can be used to
connect sensors, actuators and additional
133
00:11:02,389 --> 00:11:07,170
hardware and the board features many
probes to easily access important electric
134
00:11:07,170 --> 00:11:16,950
signals. The 4 ECUs simulate a CAN network
with messages identical to Pasta. The name
135
00:11:16,950 --> 00:11:21,430
RAMN is obviously a reference to Pasta as
this is a cheap alternative, mostly aimed
136
00:11:21,430 --> 00:11:26,880
at students. In real cars CAN messages
typically have different payload sizes,
137
00:11:26,880 --> 00:11:30,570
but by default we operate with maximum
payload size, to demonstrate heavy
138
00:11:30,570 --> 00:11:35,740
traffic, so the basic format is like this:
Arbitration ID, 2 bytes for the data,
139
00:11:35,740 --> 00:11:40,320
2 bytes for a counter and 4 bytes of
additional data, random data used as a
140
00:11:40,320 --> 00:11:47,220
placeholder for additional data such as
checksum or MAC. You can easily modify the
141
00:11:47,220 --> 00:11:51,350
CAN bus's arbitration ID end format. And
here we are assuming a full by-wire
142
00:11:51,350 --> 00:11:55,510
vehicle, which means all physical
functions of a car are accessible to the
143
00:11:55,510 --> 00:12:02,290
CAN bus, which is usually not the case on
current cars. The block diagram of RAMN
144
00:12:02,290 --> 00:12:06,480
looks like this. And as I explained
earlier, all ECUs are periodically
145
00:12:06,480 --> 00:12:10,770
exchanging messages on the CAN bus. If you
connect a CAN adapter and have a look at
146
00:12:10,770 --> 00:12:22,740
the traffic, it will typically look like
this. So the board itself is enough to
147
00:12:22,740 --> 00:12:27,279
simulate an ECU network, but it does not
look very motivating. What we wanted on
148
00:12:27,279 --> 00:12:33,570
top of this was some sensors and actuators
to make it more interactive. So we created
149
00:12:33,570 --> 00:12:37,960
4 expansion boards for sensors and
actuators. To simulate the infotainment
150
00:12:37,960 --> 00:12:43,209
domain, we simply use a screen. For the
body domain, we use an engine key and some
151
00:12:43,209 --> 00:12:52,290
LEDs. For the chassis domain we mainly use
a slide switch to simulate a side brake
152
00:12:52,290 --> 00:12:57,170
and a rotating potentiometer to simulate
the steering wheel. And for the power
153
00:12:57,170 --> 00:13:00,810
train domain we use slide potentiometers
for the brake and accelerator and a
154
00:13:00,810 --> 00:13:09,046
joystick for the shift lever. The EC
connected to USB implements a standard CAN
155
00:13:09,046 --> 00:13:14,019
or CAN-FD interface, either of a standard
serial port using Slcan or over a native
156
00:13:14,019 --> 00:13:17,991
interface on Linux thanks to the
counterlight firmware projects. If you
157
00:13:17,991 --> 00:13:22,120
connect the board to a USB port on the
computer, it should be recognized as a USB
158
00:13:22,120 --> 00:13:26,160
to CAN adapter. So it is not necessary to
own an external CAN adapter to get
159
00:13:26,160 --> 00:13:33,060
started. This is a demo of what it looks
like to use RAMN. Just connect it over
160
00:13:33,060 --> 00:13:39,199
USB, if you use Linux, you can get it to be
recognized as a standard CAN network
161
00:13:39,199 --> 00:13:44,540
interface. So it will show up in ifconfig.
Then you can use various tools available
162
00:13:44,540 --> 00:13:48,379
on Linux to observe the traffic, for
example CAN sniffer. Here you can see the
163
00:13:48,379 --> 00:13:58,520
traffic explained earlier, the CAN IDs on
the left and the payload on the right. So
164
00:13:58,520 --> 00:14:02,970
with this, we can simulate a ECU network
with sensors and actuators, which is
165
00:14:02,970 --> 00:14:06,639
enough for basic interactions. But it
still doesn't feel like you are actually
166
00:14:06,639 --> 00:14:11,699
experimenting with a car. Ideally the ECUs
should be performing realistic ECU
167
00:14:11,699 --> 00:14:16,990
functions, not just lighting up LEDs based
on some switches and potentiometers. And
168
00:14:16,990 --> 00:14:20,320
for this we thought of a connection in a
closed loop with an open source driving
169
00:14:20,320 --> 00:14:28,149
simulator which is an affordable and safe solution.
To feel like you are driving the ECU network.
170
00:14:28,149 --> 00:14:32,839
Fortunately, there is a great open source
driving simulator for autonomous driving
171
00:14:32,839 --> 00:14:36,810
research. It is called CARLA. It features
a Python API. So it is very easy to
172
00:14:36,810 --> 00:14:42,080
interact with it and it also comes with an
example self-driving algorithm. So you can
173
00:14:42,080 --> 00:14:48,670
immediately start experimenting with your
virtual self-driving car. So we wrote some
174
00:14:48,670 --> 00:14:53,770
scripts so that most sensors values for
example speed and altitude would be
175
00:14:53,770 --> 00:14:58,570
simulated on the computer running CARLA.
Then broadcasted on the CAN bus. On the
176
00:14:58,570 --> 00:15:02,540
other side we made it so that all controls
of CARLA such as throttle, steering and
177
00:15:02,540 --> 00:15:07,829
brakes will be decided by the ECU network.
And this is what you could refer to as
178
00:15:07,829 --> 00:15:12,379
HILs or Hardware-In-The-Loop simulation in
the automotive industry, RAMN is not as
179
00:15:12,379 --> 00:15:30,208
advanced as professional tools, but at
least it is accessible. So to achieve
180
00:15:30,208 --> 00:15:33,949
manual control, it is not complicated with
CARLA. On the manual control example
181
00:15:33,949 --> 00:15:38,330
provided with the API there is a while
true game loop that with events of the
182
00:15:38,330 --> 00:15:44,730
keyboard, applies controls, then updates
the physics simulation. So CARLA does not
183
00:15:44,730 --> 00:15:48,829
simulate the CAN bus by default so we
created a Python class to easily interact
184
00:15:48,829 --> 00:15:52,839
with the CAN bus using the CAN message
specifications of RAMN. To integrate it
185
00:15:52,839 --> 00:15:56,709
with CARLA we just need to replace
keyboard controls with actuator control
186
00:15:56,709 --> 00:16:02,390
data read from the CAN bus. To close the
loop we broadcast sensor data using CAN
187
00:16:02,390 --> 00:16:08,450
messages based on data retrieved from the
Python API of the physics simulator. And
188
00:16:08,450 --> 00:16:14,970
with this we are able to control the car
manually, the potentiometers on the board.
189
00:16:14,970 --> 00:16:19,319
Here I gently press accelerator, release
the handbrake, and I can control the car
190
00:16:19,319 --> 00:16:39,539
using the steering wheel
on the expansion board.
191
00:16:39,539 --> 00:17:03,500
Video stops
192
00:17:03,500 --> 00:17:05,250
So manual control is nice, but
193
00:17:05,250 --> 00:17:09,520
automatic control is better because
ultimately we want to focus on working on
194
00:17:09,520 --> 00:17:14,000
the CAN bus. So on the original CARLA
project, there was also an example script
195
00:17:14,000 --> 00:17:18,900
for automatic control. Again there is a
while true loop where the code basically
196
00:17:18,900 --> 00:17:22,790
simulates the physics, lets the self-
driving AI make a decision, then applies
197
00:17:22,790 --> 00:17:30,680
the controls to the physics simulation. To
integrate RAMN in this certain algorithm,
198
00:17:30,680 --> 00:17:34,200
again, we need to replace the apply
control part with the controls from the
199
00:17:34,200 --> 00:17:38,980
ECU network. We also need to send CAN
messages with sensor data retrieved from
200
00:17:38,980 --> 00:17:44,070
the Python API of the physics simulation.
That is identical to having manual
201
00:17:44,070 --> 00:17:50,420
control. What we need to do more is also
send a message to broadcast the status of
202
00:17:50,420 --> 00:17:57,180
the AI to the ECU Network, so that the ECU
network knows what controls the AI
203
00:17:57,180 --> 00:18:05,860
algorithm is requesting. So periodically
the AI would broadcast its status by
204
00:18:05,860 --> 00:18:10,180
sending messages over USB, which are
converted into CAN messages by the ECU
205
00:18:10,180 --> 00:18:15,950
input to USB. All ECUs on the network will
receive those messages and will decide the
206
00:18:15,950 --> 00:18:22,410
actual controls of the car based on their
own algorithm. For example, the power
207
00:18:22,410 --> 00:18:26,800
train ECU may decide to apply brakes
depending on the highest value between the
208
00:18:26,800 --> 00:18:33,260
AI brakes and the brake potentiometer. All
ECUs will receive the CAN message and
209
00:18:33,260 --> 00:18:38,521
apply the control, some ECUs may filter
that message if they do not need it. Some
210
00:18:38,521 --> 00:18:44,190
ECUs like the body ECU may process it and
take action. For example, if the brakes
211
00:18:44,190 --> 00:18:49,790
are engaged, the body ECU will light up
the stop lamp on the expansion board.
212
00:18:49,790 --> 00:18:55,240
Finally, the ECU connected to USB will
forward the brake controls to the
213
00:18:55,240 --> 00:19:02,350
simulator that will apply the brakes in
the physics simulation. So this is what it
214
00:19:02,350 --> 00:19:06,870
actually looks like, all I need to do
again is release the handbrake and the car
215
00:19:06,870 --> 00:19:12,670
will drive itself. The car is controlled
by the ECU network, so when the car stops
216
00:19:12,670 --> 00:19:15,760
in the simulation, it is because the
controls were applied by the power train
217
00:19:15,760 --> 00:19:21,450
ECU. You can see that the stop lamp lights
up because the body ECU also received and
218
00:19:21,450 --> 00:19:31,440
processed the break CAN message. Since the
ECU is in charge of the controls, I can
219
00:19:31,440 --> 00:19:45,040
force the car to stop any time by forcing
brakes on the power train ECU potentiometer.
220
00:19:45,040 --> 00:19:47,930
So if you connect an external
CAN adapter to the CAN bus,
221
00:19:47,930 --> 00:19:52,620
you'll be able to send and receive
messages. So using RAMN you can experiment
222
00:19:52,620 --> 00:20:03,150
with the CAN bus of the self-driving
virtual car. When you want to reprogram an
223
00:20:03,150 --> 00:20:07,290
ECU in the real world, you have two
options. Either you interact with the
224
00:20:07,290 --> 00:20:10,750
hardware bootloader of the ECUs
microcontroller, which depends on the
225
00:20:10,750 --> 00:20:14,480
microcontrollers model and manufacturer,
or you interact with diagnostics and
226
00:20:14,480 --> 00:20:19,460
calibration software, which depends on the
car model and manufacturer. Diagnostic and
227
00:20:19,460 --> 00:20:24,330
calibration are often done on the CAN bus,
but other options may be available.
228
00:20:24,330 --> 00:20:30,290
Protocols are defined by standard
documents. You often hear about UDS and
229
00:20:30,290 --> 00:20:34,920
OBD-II which both rely on the same
transport layer ISO-TP. But there are also
230
00:20:34,920 --> 00:20:43,050
other protocols, such as Keyword Protocol
2000 or XCP. All those protocols can often
231
00:20:43,050 --> 00:20:49,520
also be implemented over other layers. For
the hardware bootloaders it depends on the
232
00:20:49,520 --> 00:20:54,120
microcontroller manufacturer. For example
for an STM 32 microcontroller you can
233
00:20:54,120 --> 00:20:58,770
reprogram the firmware by interacting over
CAN according to the application note
234
00:20:58,770 --> 00:21:04,770
3154, over USB according to the
application note 3156. Or using other
235
00:21:04,770 --> 00:21:11,600
protocols defined in other application
notes. In the case of RAMN, we use the
236
00:21:11,600 --> 00:21:16,160
hardware bootloader to reprogram the ECUs
and you can also use a UDS protocol over
237
00:21:16,160 --> 00:21:24,240
CAN. And in the future we may consider
adding XCP and KWD 2000. How to reprogram
238
00:21:24,240 --> 00:21:28,240
an ECU using calibration and diagnostic
software is a topic that is already
239
00:21:28,240 --> 00:21:32,570
heavily discussed at automotive security
talks, I will not spend time on this
240
00:21:32,570 --> 00:21:37,550
topic. You can find the definition of the
standards online. Usually you need to pay
241
00:21:37,550 --> 00:21:43,570
for them. But you can also find summaries
for free on some websites. For example,
242
00:21:43,570 --> 00:21:51,720
Wikipedia. What is more interesting to
discuss here is the hardware bootloader.
243
00:21:51,720 --> 00:21:54,950
The various ways to force a microcontroller
into bootloader mode are
244
00:21:54,950 --> 00:22:01,650
described in the application note 2606.
The format of CAN messages we need to send
245
00:22:01,650 --> 00:22:06,650
to interact with the bootloader is defined
in the application note 3154. And it's not
246
00:22:06,650 --> 00:22:11,770
complicated. The format is simply common
byte plus argument. All that within the
247
00:22:11,770 --> 00:22:18,850
same CAN message payload. So we wrote some
script to make it easier to interact with
248
00:22:18,850 --> 00:22:27,900
the bootloader. So here I am showing the
script that we use to interact with the
249
00:22:27,900 --> 00:22:32,260
bootloader. First thing I do is retrieve
all information from the bootloader,
250
00:22:32,260 --> 00:22:38,030
including the version, the supported
commands and the Chip ID. I then use a
251
00:22:38,030 --> 00:22:44,410
read memory command to dump all known
sections of memories. This includes the
252
00:22:44,410 --> 00:22:48,890
ECU firmware. So it can be a good start to
start experimenting with reverse
253
00:22:48,890 --> 00:23:03,580
engineering. We can also activate memory
without protection and see what happens
254
00:23:03,580 --> 00:23:18,900
when you try to dump the memory again. And
in this case is not allowing memory dumps
255
00:23:18,900 --> 00:23:22,120
anymore. You can remove the memory
protection, which will wipe out the
256
00:23:22,120 --> 00:23:46,900
memory, and after you do that, you can use
the bootloader to reprogram the ECUs. For
257
00:23:46,900 --> 00:23:50,730
the hardware we also designed additional
expansion boards with various features.
258
00:23:50,730 --> 00:23:56,070
First one is an expansion to connect a
JTAG debugger. Second one is about to add
259
00:23:56,070 --> 00:24:02,000
extra QuadSPI Memories, which is why you
see packages such as EEPROM, FRAM, NAND,
260
00:24:02,000 --> 00:24:09,530
SRAM and so on. The third one is a board
to add a trusted platform module. And the
261
00:24:09,530 --> 00:24:22,650
last one is an interface to easily connect
a chip whisperer. All those expansions are
262
00:24:22,650 --> 00:24:26,980
compatible with each other, so you can
stack them and create a very advanced ECU
263
00:24:26,980 --> 00:24:33,870
network with all ECUs between a TPM and
one gigabit of memory. And it looks better
264
00:24:33,870 --> 00:24:40,560
when the expansions are stacked on top of
each other. Since we would like to use
265
00:24:40,560 --> 00:24:45,190
RAMN for education, we try to vary the
type of electrical signals using the
266
00:24:45,190 --> 00:25:04,540
expansions. And we added many external
probes to easily connect external tools. You
267
00:25:04,540 --> 00:25:08,550
can use one of the many excellent probes
to connect an oscilloscope and have a look
268
00:25:08,550 --> 00:25:18,070
at analog signals. For example, here's the
brake potentiometer. Or connect a logic
269
00:25:18,070 --> 00:25:23,700
analyzer and have a look at digital
signals, for example, to analyze SPI
270
00:25:23,700 --> 00:25:34,220
communication between the ECU and the
screen. For the hardware design we kept it
271
00:25:34,220 --> 00:25:38,770
simple using only two layers and keeping
all components on the same side. We
272
00:25:38,770 --> 00:25:41,760
designed the hardware with flash
tolerances which should be easy to produce
273
00:25:41,760 --> 00:25:47,540
with most PCB fabrication services. We use
components with large size. So if you have
274
00:25:47,540 --> 00:26:00,270
some skills in soldering, you should be
able to solder one yourself. We designed
275
00:26:00,270 --> 00:26:04,570
the hardware using KiCAD, which is an open
source tool for designing hardware. You
276
00:26:04,570 --> 00:26:13,360
can easily modify the schematics, layout
and even generate nice 3D views. So
277
00:26:13,360 --> 00:26:18,550
firmware is designed using STM32CubeIDE,
it is accessible to beginners, and you can
278
00:26:18,550 --> 00:26:23,300
easily reconfigure peripherals and clocks
from the graphical interface. You will
279
00:26:23,300 --> 00:26:27,950
even get some statistics, such as the
estimated power consumption. But of
280
00:26:27,950 --> 00:26:31,500
course, you do not need to use the
graphical interface and libraries if you
281
00:26:31,500 --> 00:26:38,091
would rather program everything yourself
by interacting directly with registers. We
282
00:26:38,091 --> 00:26:42,900
use free RTOS as a Real-Time operating
system. The basic software of ECUs has
283
00:26:42,900 --> 00:26:46,970
several tasks running in parallel, one for
receiving CAN messages, one for sending
284
00:26:46,970 --> 00:26:52,540
CAN messages and several periodic tasks to
take care of the ECU control loops. Those
285
00:26:52,540 --> 00:26:57,950
tasks receive data from different
interrupt services within, using queues and
286
00:26:57,950 --> 00:27:03,740
DMA memory overwrites. The tasks can also
exchange data between each other using
287
00:27:03,740 --> 00:27:11,620
queues or memory overwrites. Again, to
keep the project accessible to beginners,
288
00:27:11,620 --> 00:27:15,240
we did the OS configuration using the
graphical interface where you can see all
289
00:27:15,240 --> 00:27:19,620
tasks and their configuration, for example
the priority. You can add or remove
290
00:27:19,620 --> 00:27:23,610
interrupts. And you can also configure the
various queues in memory. There is still a
291
00:27:23,610 --> 00:27:31,260
lot of memory left even though the memory
controller is less performant. So you can
292
00:27:31,260 --> 00:27:41,050
easily add your own application on top of
this. That's all for the hardware and
293
00:27:41,050 --> 00:27:45,150
software section, you can find more
details on GitHub. I would like to move to
294
00:27:45,150 --> 00:27:50,110
the next section and show you a usage
example. There are usually two budgets for
295
00:27:50,110 --> 00:27:54,190
people working in automotive security
Either they are automotive engineers who
296
00:27:54,190 --> 00:27:58,640
learn about security or they are security
engineers who wrote about automotive
297
00:27:58,640 --> 00:28:03,050
systems. Since this is a security
conference and I assume most people do not
298
00:28:03,050 --> 00:28:07,310
need me to explain how the platform can be
used to study and research basic security
299
00:28:07,310 --> 00:28:15,150
topics, I will focus on the automotive
side. So diagnostics and calibration topic
300
00:28:15,150 --> 00:28:25,070
is already covered by many security
talks. I will not spend time on this. So
301
00:28:25,070 --> 00:28:29,890
I will spend time on something
that is not often mentioned at security
302
00:28:29,890 --> 00:28:37,000
conferences: Control algorithms and safety
critical hardware and software. And for
303
00:28:37,000 --> 00:28:39,960
this, I would like to demonstrate the
design of a PID controller for cruise
304
00:28:39,960 --> 00:28:43,790
control as an example. I will show you how
being knowledgeable in control systems may
305
00:28:43,790 --> 00:28:49,490
be relevant to security engineers, and how
many of the activities that are done by
306
00:28:49,490 --> 00:28:54,860
engineers in the automotive industry can
also be simulated using open source tools,
307
00:28:54,860 --> 00:29:01,380
including RAMN. Once we have an
implementation in C that works, I would
308
00:29:01,380 --> 00:29:04,920
then use it as a reference to talk about
safety critical systems and the
309
00:29:04,920 --> 00:29:14,221
differences with real ECU hardware and
software. So let's get started. Cruise
310
00:29:14,221 --> 00:29:17,890
control is very simple: When a human is
controlling the throttle with the
311
00:29:17,890 --> 00:29:24,820
accelerator pedal depending on the skill
the car may have an uneven speed. What we
312
00:29:24,820 --> 00:29:28,820
want is an ECU that optimizes the control
of the throttle so that we can maintain a
313
00:29:28,820 --> 00:29:37,310
steady speed. An automatic car can be very
easy to model. If you press the
314
00:29:37,310 --> 00:29:41,350
accelerator pedal, which opens the
throttle, you will get speed out of your
315
00:29:41,350 --> 00:29:45,590
car. But the relationship between speed
and throttle is not as simple as a
316
00:29:45,590 --> 00:29:50,480
multiplication. No, we have to follow the
laws of dynamics. In this case that's the
317
00:29:50,480 --> 00:29:56,760
sum of forces on the car is equal to its
mass times its acceleration. We can
318
00:29:56,760 --> 00:30:00,640
consider that there is a force pushing the
car that is proportional to the throttle,
319
00:30:00,640 --> 00:30:06,140
and that there is an opposing force
proportional to the speed due to friction.
320
00:30:06,140 --> 00:30:12,110
When we solve this diversal equation, what we
expect to see is that the speed follows an
321
00:30:12,110 --> 00:30:17,990
exponential curve. And a simple way to
control the speed that may come to your
322
00:30:17,990 --> 00:30:22,240
mind is open loop control. You make some
measurements on the flat road of the
323
00:30:22,240 --> 00:30:26,860
relationship between throttle and maximum
speed, and you keep in a lookup table.
324
00:30:26,860 --> 00:30:31,380
When the user asks the ECU to reach a
certain speed, the ECU can use the lookup
325
00:30:31,380 --> 00:30:38,250
table to find what throttle controls
should be applied based on past
326
00:30:38,250 --> 00:30:43,330
measurements. And this may work in some
situations, but according to the laws of
327
00:30:43,330 --> 00:30:51,170
dynamics, as soon as we reach an upward
slope, the car will lose speed because of
328
00:30:51,170 --> 00:30:56,420
gravity. So at least that is what we
expect, but we should verify that on the
329
00:30:56,420 --> 00:31:02,230
CAN bus. This is something we can use RAMN
for. Here again, using an external CAN
330
00:31:02,230 --> 00:31:07,980
adapter connected to a second PC. On that
PC I simply receive data from the physical
331
00:31:07,980 --> 00:31:13,140
CAN bus. For the rest of the section I
will only be modifying the firmware on the
332
00:31:13,140 --> 00:31:25,560
power train ECU. I will not change the
simulator, I will not even reboot it.
333
00:31:25,560 --> 00:31:30,610
So in the simulator, I drove around the city
to try to find a nice place to experiment.
334
00:31:30,610 --> 00:31:40,280
More precisely, I looked for a place with
flat road followed by an upward slope.
335
00:31:40,280 --> 00:31:44,070
Then I programmed the power train ECU to a
apply a constant throttle, which is only
336
00:31:44,070 --> 00:31:49,220
one line of code. And after reprogramming
the ECU I let the car drive straight and I
337
00:31:49,220 --> 00:32:08,220
recorded data from the CAN bus. I used an
open source tool for CAN bus analysis
338
00:32:08,220 --> 00:32:14,040
called Bus Master. Bus Master allows you
to load DBC files or to input manually the
339
00:32:14,040 --> 00:32:18,770
format of your CAN frames. Here I simply
told Bus Master what were the CAN
340
00:32:18,770 --> 00:32:24,010
arbitration IDs of the throttle control
message and the speed sensor message. And
341
00:32:24,010 --> 00:32:30,110
what was the format of the payload. Once I
do that, I can plot the evolution of the
342
00:32:30,110 --> 00:32:36,190
throttle and speed over time. And the
results we get are exactly what we
343
00:32:36,190 --> 00:32:40,810
expected from our differential equations.
The speed of the vehicle is following an
344
00:32:40,810 --> 00:32:44,380
exponential curve and as soon as we reach
the upward slope, we start loosing speed
345
00:32:44,380 --> 00:32:49,220
because the throttle is constant. There
are some noise and non-linearities at low
346
00:32:49,220 --> 00:32:54,270
speed but overall it seems our model of
the car is correct. We are approaching the
347
00:32:54,270 --> 00:33:01,320
problem correctly. What we can see here is
that it takes about 40 seconds for one
348
00:33:01,320 --> 00:33:06,400
test-drive. And 40 seconds is already too
long. So before testing the ECU in the
349
00:33:06,400 --> 00:33:09,890
driving simulator, we want to use the
software that can simulate differential
350
00:33:09,890 --> 00:33:13,790
equations so that we can see the impact of
the cruise control algorithm directly,
351
00:33:13,790 --> 00:33:18,960
without having to wait for 40 seconds.
Most of the time this is done using a
352
00:33:18,960 --> 00:33:25,330
professional tool such as Matlab and
Simulink. But here we will use open source
353
00:33:25,330 --> 00:33:30,460
tool Scilab. It has a graphical interface
where we can connect inputs and outputs
354
00:33:30,460 --> 00:33:37,230
from a block diagram. Differential
equations are a bit hard to deal with
355
00:33:37,230 --> 00:33:41,120
because the relationship between inputs
and outputs is complicated. What you
356
00:33:41,120 --> 00:33:45,640
typically do in control theory is use a
Laplace transform, which will change the
357
00:33:45,640 --> 00:33:50,590
variable called t to a complex number
called s. This may be complicated with a
358
00:33:50,590 --> 00:33:53,980
contradictory background, but you just
need to know that a differentiation is
359
00:33:53,980 --> 00:33:58,680
equivalent to a multiplication by s and
that integration is equivalent to division
360
00:33:58,680 --> 00:34:05,300
by s. In our system it is easier to model
the Laplace transform because we now have
361
00:34:05,300 --> 00:34:09,730
a simple relationship between throttle and
speed. Speed equals transfer function of
362
00:34:09,730 --> 00:34:18,199
car times throttle. And based on the
measurements from the CAN bus, we can
363
00:34:18,199 --> 00:34:25,760
evaluate the transfer function of the car
to be equal to approximately 1 / (1 + 4s).
364
00:34:25,760 --> 00:34:30,299
We can simulate the car in Scilab by
using a block function which has the exact
365
00:34:30,299 --> 00:34:36,960
same transfer function. Using Scilab, we
can now test various scenarios and get the
366
00:34:36,960 --> 00:34:41,389
results immediately. Here I am testing the
scenario in which we start from zero
367
00:34:41,389 --> 00:34:46,760
speed, apply a constant throttle and after
20 seconds, we add a new force - gravity -
368
00:34:46,760 --> 00:34:52,950
which corresponds to the slope. And this
is what we call here the disturbance. And
369
00:34:52,950 --> 00:34:57,490
with Scilab simulation we can verify we
get waveforms similar to our measurements
370
00:34:57,490 --> 00:35:01,519
on the CAN bus. With a constant throttle,
the speed follows an exponential curve
371
00:35:01,519 --> 00:35:07,990
that is close to maximum speed after
around 14 seconds. And as soon as there is
372
00:35:07,990 --> 00:35:11,840
a disturbance: the gravity here, showing
green, we can check that the car looses
373
00:35:11,840 --> 00:35:18,390
speed because there is no reaction from
the throttle. So to fix that the solution
374
00:35:18,390 --> 00:35:24,740
is obvious: The ECUs need to have
feedback. We need the ECU to make use of
375
00:35:24,740 --> 00:35:29,670
the speed sensor data that it can find on
the CAN bus so that it can adapt the
376
00:35:29,670 --> 00:35:35,480
throttle to the actual speed of the
vehicle. So first solution that may come
377
00:35:35,480 --> 00:35:40,160
to mind to software engineers is Bang-Bang
Control. Bang-Bang Control is quite
378
00:35:40,160 --> 00:35:45,460
simple. You measure the speed and if it is
above a certain threshold, you stop
379
00:35:45,460 --> 00:35:49,730
applying the throttle. If it goes below a
certain threshold, you apply the throttle
380
00:35:49,730 --> 00:35:58,619
again. This is extremely easy to implement
in C on the ECU. And once we reprogram the
381
00:35:58,619 --> 00:36:03,009
ECU on RAMN, we can make measurements on
the CAN bus and verify that this time we
382
00:36:03,009 --> 00:36:09,049
are not loosing speed anymore when we
reach a slope. But as you can see, there
383
00:36:09,049 --> 00:36:13,799
are some oscillations. And as you can
imagine, the oscillations are not
384
00:36:13,799 --> 00:36:18,430
something very nice for passengers.
Apparently people driving like this is the
385
00:36:18,430 --> 00:36:22,890
reason cruise control was invented. I do
not know if that story is true, but I can
386
00:36:22,890 --> 00:36:27,710
believe it. So Bang-Bang Control made a
good start, but it is not good enough for
387
00:36:27,710 --> 00:36:35,660
cruise control. And the most famous
algorithm used in control theory is the
388
00:36:35,660 --> 00:36:40,280
PID controller. You can find a lot of
resources online. The PID controller is
389
00:36:40,280 --> 00:36:44,829
one of the control mechanism used in
software of the self-driving AI of CARLA.
390
00:36:44,829 --> 00:36:48,960
In the PID controller you measure the
difference between the target speed and
391
00:36:48,960 --> 00:36:54,849
the current speed. You call that different
error and you can control the throttle
392
00:36:54,849 --> 00:36:59,799
using the sum of 3 control blocks. The
error multiplied by Kₚ. The integral of
393
00:36:59,799 --> 00:37:05,740
the error multiplied by Kᵢ and the
derivative of the error multiplied by Kd.
394
00:37:05,740 --> 00:37:17,099
Kₚ, Kᵢ and Kd are constant called gains.
And you need to have a very fine tuning of
395
00:37:17,099 --> 00:37:22,140
those gains to achieve optimal control.
Here I can simulate the PID controller
396
00:37:22,140 --> 00:37:27,289
using Scilab with different blocks.
Remember that the division by s is an
397
00:37:27,289 --> 00:37:32,869
integration, and the multiplication by s
is a derivation. Thanks to the simulation
398
00:37:32,869 --> 00:37:37,549
I am able to try many values without
having to actually drive the car. And when
399
00:37:37,549 --> 00:37:47,750
we are able to find correct values for the
PID controller, we get this. The ECU is
400
00:37:47,750 --> 00:37:51,240
able to reach a target quite quickly
without oscillations and without
401
00:37:51,240 --> 00:37:57,559
overshooting the maximum speed. And when
there is a disturbance so gravity, it will
402
00:37:57,559 --> 00:38:02,000
dynamically adapt the controls of the
throttle so that the target speed is
403
00:38:02,000 --> 00:38:07,829
maintained. So this is good, because this
is what we want for cruise control. But is
404
00:38:07,829 --> 00:38:13,039
a gain of only one control block is
correct, the speed of the vehicle may look
405
00:38:13,039 --> 00:38:16,539
like something totally different,
potentially dangerous. And this is why the
406
00:38:16,539 --> 00:38:21,190
integrity of calibration data is important
not only from a safety point of view, but
407
00:38:21,190 --> 00:38:25,230
also from a security point of view.
Because an attacker should not be able to
408
00:38:25,230 --> 00:38:37,110
make an ECU have a dangerous behavior with
only one small change. The last thing I
409
00:38:37,110 --> 00:38:41,119
need to explain is how to implement these
algorithms in C, and this is not obvious
410
00:38:41,119 --> 00:38:45,470
because we're dealing with integration and
derivations, which are not possible for
411
00:38:45,470 --> 00:38:51,190
digital functions. So there are many ways
to implement this in a digital PID
412
00:38:51,190 --> 00:38:58,109
controller in C. I will just explain two
approaches. The first approach is to stay
413
00:38:58,109 --> 00:39:02,320
in the time domain and approximate the
derivation by the difference between two
414
00:39:02,320 --> 00:39:07,400
successive errors divided by the sampling
time. And we can approximate the integral
415
00:39:07,400 --> 00:39:14,930
operation with a Riemann sum which is a
running sum of errors so far multiplied by
416
00:39:14,930 --> 00:39:20,940
the sampling time. This may look a bit
intimidating, but when you look at it
417
00:39:20,940 --> 00:39:25,190
closely, you can see it is just a
combination of constants and values that
418
00:39:25,190 --> 00:39:33,400
can be computed from current and past
sensor values from the CAN bus. The actual
419
00:39:33,400 --> 00:39:39,380
implementation in C looks like this. We
need to define 2 variables. One to store
420
00:39:39,380 --> 00:39:45,630
the running sum of errors and one to store
the error of the previous control loop
421
00:39:45,630 --> 00:39:51,280
execution. In the control loop, we define
constant gains for each stage. We compute
422
00:39:51,280 --> 00:40:00,119
the current error. We add the error to the
sum of all errors. We compute the
423
00:40:00,119 --> 00:40:05,450
difference between current errors and
previous error. We then add all those
424
00:40:05,450 --> 00:40:10,420
values with the respective gain to the
output variable and then we clamp that
425
00:40:10,420 --> 00:40:16,730
output in case it goes out of bound. We
then apply the throttle control and save
426
00:40:16,730 --> 00:40:24,780
the current error in the previous error
variable for use in the next iteration.
427
00:40:24,780 --> 00:40:30,849
The second approach is to use a Laplace
transform of the PID controller. We first
428
00:40:30,849 --> 00:40:34,930
need to convert it to a Z transform, the
equivalent of Laplace transform but for
429
00:40:34,930 --> 00:40:38,970
digital signals. It looks a bit
complicated, but there are many tools to
430
00:40:38,970 --> 00:40:44,369
do the conversion for you. If you want to
do the conversion by hand, one way is to
431
00:40:44,369 --> 00:40:55,059
use the bilinear transformation in which
you replace s by this, to approximate the Z
432
00:40:55,059 --> 00:41:06,529
transform of your ECU. And again, this may
all look a bit intimidating, but you can
433
00:41:06,529 --> 00:41:10,950
actually compute the throttle output by
using the throttle output from 2
434
00:41:10,950 --> 00:41:16,789
iterations ago, the current error, the
previous error and the error before that
435
00:41:16,789 --> 00:41:21,230
which can all be computed from sensor
values on the CAN bus. And while this
436
00:41:21,230 --> 00:41:26,159
control algorithm is equivalent to our
previous implementation, it looks totally
437
00:41:26,159 --> 00:41:32,130
different. And what I would like to stress
here that identical control algorithms may
438
00:41:32,130 --> 00:41:35,960
have very different software
implementations, which may be relevant for
439
00:41:35,960 --> 00:41:47,859
reverse engineers. I only show the first
implementation not waste time, but you can
440
00:41:47,859 --> 00:41:52,589
see now that the ECU in RAMN is able to
make the car maintain a constant speed and
441
00:41:52,589 --> 00:42:05,269
for dynamic control of the throttle. So
that's it for the example. I just wanted
442
00:42:05,269 --> 00:42:08,880
to show that RAMN can be used for
realistic activities of the CAN bus and
443
00:42:08,880 --> 00:42:14,430
that the ECUs are not just doing some
random easy work. The control theory part
444
00:42:14,430 --> 00:42:18,460
may be complicated and if that was going
too fast for you at least I hope it proves
445
00:42:18,460 --> 00:42:22,269
there is a lot of things to discover and
experiment with. And that all that
446
00:42:22,269 --> 00:42:37,420
learning can be done with open source
tools. Now I would like to discuss what
447
00:42:37,420 --> 00:42:41,430
would have been different with real ECUs
because, as you can imagine, actual ECU
448
00:42:41,430 --> 00:42:47,279
software is not as simple as this. I will
also show you what alternatives we have.
449
00:42:47,279 --> 00:42:53,119
Technologies hidden behind NDAs, so that
we can get as close as we can to real
450
00:42:53,119 --> 00:42:59,630
ECUs. We showed in RAMN that this cruise
control ECU worked, but we only tried it
451
00:42:59,630 --> 00:43:06,030
on a single scenario, namely a flat road
followed by an upward slope. But what
452
00:43:06,030 --> 00:43:09,970
about this scenario in which a car in
front is driving slowly? Or what about a
453
00:43:09,970 --> 00:43:14,619
scenario in which we are in a downward
slope? In this case the ECU will not be
454
00:43:14,619 --> 00:43:18,390
able to prevent a car from going too fast
because it does not have access to the
455
00:43:18,390 --> 00:43:24,750
brakes, which could lead to an accident.
And the difficult problem here is not
456
00:43:24,750 --> 00:43:29,110
whether you can think of one more
scenario. The difficult problem is can you
457
00:43:29,110 --> 00:43:34,430
think of them all are you sure? And
thinking of all potential scenarios,
458
00:43:34,430 --> 00:43:38,430
quantifying the risk and implementing
countermeasures is what makes automotive
459
00:43:38,430 --> 00:43:46,970
systems really different. And to prove
that an ECU is reasonably safe, you
460
00:43:46,970 --> 00:43:52,569
actually need to follow ISO 26262
standard, which is a standard for
461
00:43:52,569 --> 00:43:58,740
functional safety. The standard defines
different requirements at many levels. Not
462
00:43:58,740 --> 00:44:03,480
all ECUs are equally critical, so safety
relevant issues are assigned and
463
00:44:03,480 --> 00:44:10,349
automotive safety integrity level or ASIL
for short. And ASIL A is a less critical
464
00:44:10,349 --> 00:44:17,369
level and ASIL D is the most critical
level. So if you were to design a real
465
00:44:17,369 --> 00:44:21,329
cruise control ECU for use in a real car,
you could not just connect some random ECU
466
00:44:21,329 --> 00:44:25,859
to the CAN bus and try it on the highway.
You will need to go through a lot of
467
00:44:25,859 --> 00:44:32,009
analysis, such as HAZOP, HARA, FMEA, STPA
and so on. Usually there are so many
468
00:44:32,009 --> 00:44:36,890
requirements that they cannot be tracked
with only a human and a sheet of paper.
469
00:44:36,890 --> 00:44:46,250
They are managed using dedicated tools
such as Rational Doors. Now let's discuss
470
00:44:46,250 --> 00:44:50,700
how the software would be different. The
main contribution of automotive software
471
00:44:50,700 --> 00:44:55,410
is to realize control algorithms safely.
But without countermeasures, many things
472
00:44:55,410 --> 00:45:01,119
could go wrong. For example there could be
bugs in the ECU application code. And then
473
00:45:01,119 --> 00:45:04,589
without any bug the software will be
robust enough when there are transient
474
00:45:04,589 --> 00:45:11,760
errors in the hardware. There could also
be problems with the toolchains that
475
00:45:11,760 --> 00:45:24,210
compile the firmware and problems with the
libraries and RTOS. And when we have a
476
00:45:24,210 --> 00:45:28,359
close look at the PID controller
implementation which seemed good enough in
477
00:45:28,359 --> 00:45:32,740
our testing, you can see it is actually a
terrible implementation. We are mixing
478
00:45:32,740 --> 00:45:37,680
integers and unsigned integers and floats
without proper checks and type casting. We
479
00:45:37,680 --> 00:45:45,410
are not checking for overflows and also
random software issues. And this is not
480
00:45:45,410 --> 00:45:48,670
acceptable, both for safety and security.
And in this case, the problems were
481
00:45:48,670 --> 00:45:52,070
obvious on purpose, but sometimes it can
be very hard to spot because they stem
482
00:45:52,070 --> 00:45:58,829
from very subtle computing issues. And
those issues may lead to system failures.
483
00:45:58,829 --> 00:46:03,440
So to avoid such scenarios, the automotive
industry usually mandates the use of a
484
00:46:03,440 --> 00:46:07,940
language subset which restricts what
developers can do, but makes sure that
485
00:46:07,940 --> 00:46:15,849
numerical errors are less likely to
happen. So usually in the automotive
486
00:46:15,849 --> 00:46:22,089
industry, the standard that is used is
MISRA-C and it is very similar to CERT-C,
487
00:46:22,089 --> 00:46:30,600
which is popular in the security industry.
Using a language subset is only one of the
488
00:46:30,600 --> 00:46:36,119
requirements that are dictated by ISO
26262. There are many other requirements.
489
00:46:36,119 --> 00:46:40,930
At a high level they try to enforce a low
complexity of the software. For example,
490
00:46:40,930 --> 00:46:45,810
by restricting the size of components,
restricting the copying between software
491
00:46:45,810 --> 00:46:51,150
components and making sure the scheduling
is appropriate. And that there are not too
492
00:46:51,150 --> 00:46:55,329
many interrupts. But we also have more
concrete requirements, such as restricting
493
00:46:55,329 --> 00:46:59,410
functions to 1 entry and 1 exit point,
forbid dynamic memory, avoid global
494
00:46:59,410 --> 00:47:07,670
variables, limit the use of pointers and
so on. The other issues we have to deal
495
00:47:07,670 --> 00:47:11,830
with, which is riddled with bugs is
transient errors. In the harsh
496
00:47:11,830 --> 00:47:16,380
environment, data is not always reliable.
There may be a bit flip occurring outside
497
00:47:16,380 --> 00:47:22,890
of memory, for example, because of noise
and communication lines, but also may be
498
00:47:22,890 --> 00:47:26,589
bit flips occurring inside a microcontrollers
memory. For example, because of cosmic
499
00:47:26,589 --> 00:47:31,950
rays. Those issues do not originate from
software, they originate from hardware,
500
00:47:31,950 --> 00:47:35,670
but they do need to be addressed by
software because remember, in the case of
501
00:47:35,670 --> 00:47:41,309
the example cruise control ECU, just one
bit flip could lead to unwanted behavior of
502
00:47:41,309 --> 00:47:47,400
the ECU and the car. So to address those
issues, automotive controllers need
503
00:47:47,400 --> 00:47:52,003
special countermeasures. For example
having redundant memory or having
504
00:47:52,003 --> 00:48:00,079
redundant CPUs. In ECUs, you will
typically find microcontrollers that have
505
00:48:00,079 --> 00:48:04,290
been designed specially for automotive
use. All those microcontrollers require
506
00:48:04,290 --> 00:48:09,241
you to sign an NDA so you can not just buy
them and start programming them. So that
507
00:48:09,241 --> 00:48:15,920
makes it a bit hard to study an actual ECU
microcontroller and real automotive
508
00:48:15,920 --> 00:48:23,119
software. ISO 26262 is not the only
standard for safety critical systems. ISO
509
00:48:23,119 --> 00:48:29,920
26262 is actually derived from IEC 61508,
so they are both similar in their
510
00:48:29,920 --> 00:48:35,750
concepts. And IEC61508 microcontrollers
they do not require NDAs for most other
511
00:48:35,750 --> 00:48:42,339
activities you may be interested in. And
more completely RAMN can be used with
512
00:48:42,339 --> 00:48:47,420
STM32L4 or STM32L5 microcontrollers. And
for those microcontrollers, you do not
513
00:48:47,420 --> 00:48:52,650
need an NDA to download guidelines on how
to implement safe software. For example,
514
00:48:52,650 --> 00:48:56,240
you can find a list of features that are
required for safety applications, and you
515
00:48:56,240 --> 00:49:00,700
can request more data that you would need
to actually achieve compliance with
516
00:49:00,700 --> 00:49:07,400
IEC 61508, such as the FMEA and FMEDA. But to
obtain those data, you would need to sign an
517
00:49:07,400 --> 00:49:13,329
NDA. No, I personally do not think that
those data are essential for education and
518
00:49:13,329 --> 00:49:19,670
research. So using such microcontrollers
is a good alternative. But again, let me
519
00:49:19,670 --> 00:49:23,299
stress that this is an alternative for
learning and researching, not for actual
520
00:49:23,299 --> 00:49:28,660
use in a car. I don't have time to detail
all the safety features, let me just talk
521
00:49:28,660 --> 00:49:35,220
about memory redundancy, since this one
impacts the code of the application of the
522
00:49:35,220 --> 00:49:42,150
example cruise control ECU. So in the
example, we wrote the gain of each stage
523
00:49:42,150 --> 00:49:47,390
in code memory defining them as constants.
For safer applications, this would not be
524
00:49:47,390 --> 00:49:53,289
here. They belong to another section, the
data flash where ECC protection can be
525
00:49:53,289 --> 00:49:57,920
activated. If possible, calibration data
should be stored twice with checksums and
526
00:49:57,920 --> 00:50:04,299
preferably MACs. If you're not familiar
with ECC memory, it is a kind of memory
527
00:50:04,299 --> 00:50:09,349
that can detect bit flips and sometimes
automatically corrects them. Another
528
00:50:09,349 --> 00:50:13,480
memory is also available for the RAM,
but not at all addresses. So in the
529
00:50:13,480 --> 00:50:17,240
application, we have to ensure that safety
critical variables are placed in a section
530
00:50:17,240 --> 00:50:24,520
of RAM in which bit flips can be detected,
in this case in section SRAM2. For data in
531
00:50:24,520 --> 00:50:30,819
RAM that are actually constants such the
gains you may also want to activate write
532
00:50:30,819 --> 00:50:36,579
protection, a feature that is only
available in SRAM2. Last slide about
533
00:50:36,579 --> 00:50:44,200
software. In the example cruise control,
we are using GCC toolchain in ISO 26262 it
534
00:50:44,200 --> 00:50:48,119
is a requirement to have what is called a
tool confidence lever to ensure that
535
00:50:48,119 --> 00:50:53,190
poor chains will not introduce errors as it
could be the case with some optimizations.
536
00:50:53,190 --> 00:50:57,750
So normally you cannot use GCC. Realtime
operating systems and libraries may also
537
00:50:57,750 --> 00:51:03,099
have problems. That is why they need to be
certified. Both STM32-HAL and FreeRTOS are
538
00:51:03,099 --> 00:51:10,799
compliant with MISRA-C which is nice, but
they are not compliant with ISO 26262.
539
00:51:10,799 --> 00:51:16,410
However, it looks like ST is bringing
Azure RTOS into the ecosystem and that one
540
00:51:16,410 --> 00:51:24,700
is actually precertified ISO 26262. Maybe
in the future it would be an option to
541
00:51:24,700 --> 00:51:30,519
experiment with with an actual ISO 26262
operating system. So now let's talk a bit
542
00:51:30,519 --> 00:51:33,539
about hardware. In case it was not clear
to you, you cannot use commercial
543
00:51:33,539 --> 00:51:37,700
electronics to implement an ECU.
Smartphone vendors will often warn you not
544
00:51:37,700 --> 00:51:42,499
to let a device in your car because a
parked car can reach extreme temperatures
545
00:51:42,499 --> 00:51:47,480
that commercial electronics are not
designed to resist. And if you think that
546
00:51:47,480 --> 00:51:52,270
the life inside the cabin is hard, you
should think about an ECU which has to
547
00:51:52,270 --> 00:51:56,999
stay in the engine compartment and operate
without failures. And you would not think
548
00:51:56,999 --> 00:52:03,560
of putting a smartphone or an Arduino here
and trust your life with it. And extreme
549
00:52:03,560 --> 00:52:06,890
temperatures are just one of the many
environmental factors that make it
550
00:52:06,890 --> 00:52:11,289
difficult for an ECU to stay reliable. The
ECU also need to resist high humidity,
551
00:52:11,289 --> 00:52:17,859
corrosive gases, vibrations, micro cuts,
load dumps, electrostatic discharges,
552
00:52:17,859 --> 00:52:27,029
electromagnetic noise and so on. And when
subjected to such a harsh environment,
553
00:52:27,029 --> 00:52:30,430
many things could go wrong with
electronics. You probably know about
554
00:52:30,430 --> 00:52:35,089
corrosion, but many other physical
phenomena are at risk of happening to the
555
00:52:35,089 --> 00:52:39,079
components. Solder cracs, intermetallic
growth, whiskers, dendrites,
556
00:52:39,079 --> 00:52:44,670
electromigration, etc. For example,
whiskers are metal growing out of
557
00:52:44,670 --> 00:52:48,349
electrical components and dendrites are
metals leaving the plus side towards the
558
00:52:48,349 --> 00:52:53,560
minus side. And many other phenomena may
result in a dangerous failure. So
559
00:52:53,560 --> 00:52:58,059
obviously, ECUs need to be designed to
resist harsh environments and have
560
00:52:58,059 --> 00:53:01,779
countermeasures against all those
potential failures. ECUs need to pass
561
00:53:01,779 --> 00:53:06,190
various tests that simulate harsh
environments. Those tests are usually
562
00:53:06,190 --> 00:53:11,099
defined by manufacturers and the test
specifications are not made public. What
563
00:53:11,099 --> 00:53:14,779
is made public, however, is the test
specifications for individual electronic
564
00:53:14,779 --> 00:53:20,200
components. And those tests are usually
defined by AEC. So the Automotive
565
00:53:20,200 --> 00:53:28,119
Electronic Council, and you can have a
look at them online. For RAMN, we tried to
566
00:53:28,119 --> 00:53:32,049
follow design guidelines similar to those
of real ECUs. But of course, we cannot
567
00:53:32,049 --> 00:53:37,619
follow actual rules as it to be much less
accessible. Completely, we selected
568
00:53:37,619 --> 00:53:41,569
AEC-Q100 grade zero components for
everything except connectors and
569
00:53:41,569 --> 00:53:46,339
microcontrollers, because those may
require NDAs or not be easily accessible.
570
00:53:46,339 --> 00:53:51,270
Depending on the part reference, ECU
microcontrollers may be usable from -40 to
571
00:53:51,270 --> 00:53:56,259
125°C. RAMN tried to stay close to
automotive grade, but it is still not
572
00:53:56,259 --> 00:53:59,859
automotive grade, especially in the
reliability department, so it can not be
573
00:53:59,859 --> 00:54:06,290
used as a real ECU. As a result, we try to
stay close to automotive hardware is to
574
00:54:06,290 --> 00:54:10,460
help researchers evaluate the impact of
manufacturing tolerances and environments
575
00:54:10,460 --> 00:54:16,880
because remember, manufacturers are making
millions of cars that need to operate on a
576
00:54:16,880 --> 00:54:20,609
large temperature range. So if you are
developing, for example, a security
577
00:54:20,609 --> 00:54:25,089
technology that relies on hardware
characteristics such as the clocks of the
578
00:54:25,089 --> 00:54:29,869
ECUs, you will need to prove that the
technology works despite manufacturing
579
00:54:29,869 --> 00:54:35,329
tolerances and harsh environments. And
with RAMN it is easy to have a large
580
00:54:35,329 --> 00:54:40,499
sample of ECU networks and since they are
small they can easily fit in various
581
00:54:40,499 --> 00:54:46,808
testing equipment. And now let's move on
to the last section, security. In the
582
00:54:46,808 --> 00:54:51,700
automotive industry, we just can not apply
the same reasoning as you do in many other
583
00:54:51,700 --> 00:54:56,599
industries. For example, a credit card, if
you detect the temperature is too cold, it
584
00:54:56,599 --> 00:55:01,140
may think that it is a tampering attack
and decides to shut down because it is not
585
00:55:01,140 --> 00:55:05,720
safety critical. On the other hand, the
car needs to start quickly because the
586
00:55:05,720 --> 00:55:12,210
user should not be left out in the cold
and also credit cards have an expiration
587
00:55:12,210 --> 00:55:16,569
date. So they do not need to guarantee
security for more than a few years. But
588
00:55:16,569 --> 00:55:21,549
cars do not have an expiration date. If
they are well maintained they may be used
589
00:55:21,549 --> 00:55:26,970
for several decades and the security
technologies should keep on working. So in
590
00:55:26,970 --> 00:55:30,530
the end, automotive security technologies
have different requirements.
591
00:55:30,530 --> 00:55:34,759
Unfortunately, according to past research,
a security technology is often less
592
00:55:34,759 --> 00:55:39,339
reliable when you extend its operating
temperature range and its lifetime. For
593
00:55:39,339 --> 00:55:45,060
example, at low temperatures, they may be
liable to cold boot attacks. At high
594
00:55:45,060 --> 00:55:50,249
temperatures, it has also been shown that
electronics tend to be less reliable
595
00:55:50,249 --> 00:55:53,820
concerning glitching attacks and in those
papers high-temperature means something
596
00:55:53,820 --> 00:56:01,039
like 60 or 100°C, far from the maximum
temperature required for some ECUs. Also,
597
00:56:01,039 --> 00:56:06,359
it has been shown that the higher age for
electronics usually results in different
598
00:56:06,359 --> 00:56:13,150
security properties. And you may think
that the safety features of automotive
599
00:56:13,150 --> 00:56:17,249
microcontrollers would prevent some
attacks such as glitching attacks, but it
600
00:56:17,249 --> 00:56:22,119
has been shown that ECC memories are also
susceptible to glitching attacks. And that
601
00:56:22,119 --> 00:56:27,550
even ISO 26262 ASIL-D microcontrollers,
which is the highest level of safety may
602
00:56:27,550 --> 00:56:32,039
be susceptible to glitching. So safety
features often help, but there aren't
603
00:56:32,039 --> 00:56:38,839
really enough to ensure security. What is
also different with automotive is that you
604
00:56:38,839 --> 00:56:42,940
need to rethink the strategy in case of
security problems, for example, with
605
00:56:42,940 --> 00:56:48,000
credit cards, it is not uncommon for
authentication to fail randomly. When the
606
00:56:48,000 --> 00:56:54,059
credit card fails to work usually you just
need to try it once more and it will
607
00:56:54,059 --> 00:56:59,589
probably work and everything stays again.
No life is at risk. But the car cannot
608
00:56:59,589 --> 00:57:06,579
have the same strategy. If you add
authentication to the brake CAN message
609
00:57:06,579 --> 00:57:10,740
and you start receiving break request that
fail authentication what should the car
610
00:57:10,740 --> 00:57:18,210
really do. Because it may be a cyber
attacks, which you want to avoid, but you
611
00:57:18,210 --> 00:57:22,799
should not relay out the possibility of a
random malfunction or a false positive for
612
00:57:22,799 --> 00:57:27,289
an intrusion detection system. And by
adding complexity into the system, you
613
00:57:27,289 --> 00:57:33,039
always increase the odds of a problem. And
which one would be worse between breaking
614
00:57:33,039 --> 00:57:40,059
because of a cyber attack or not breaking
because of a malfunction? And there is no
615
00:57:40,059 --> 00:57:43,509
easy way to answer that question. But what
I want to stress here is that many
616
00:57:43,509 --> 00:57:47,450
security countermeasures that people
suggest for cars such as encrypting the
617
00:57:47,450 --> 00:57:51,799
CAN bus, permanently disabling debug ports
or obfuscating the firmware, they may not
618
00:57:51,799 --> 00:57:58,240
necessarily be the best ideas, because if
you suspect a malfunction with an ECU, you
619
00:57:58,240 --> 00:58:02,839
need to investigate the problem seriously
because it may harm people. You cannot
620
00:58:02,839 --> 00:58:09,599
just replace a car as you would with a
credit card or a smartphone.
621
00:58:09,599 --> 00:58:13,779
So technologies that can truly take into
account both automotive requirements and
622
00:58:13,779 --> 00:58:17,390
security requirements are better. And we
should make sure that education and
623
00:58:17,390 --> 00:58:22,369
research in these areas are accessible to
many researchers without NDAs or
624
00:58:22,369 --> 00:58:28,740
prohibitive costs. Now, of course, you can
use RAMN to try out different attacks. The
625
00:58:28,740 --> 00:58:32,859
first obvious one is to inject CAN
messages to alter the behavior of the car.
626
00:58:32,859 --> 00:58:55,759
Here for example the breaks. Another kind
of security that I did not mention in this
627
00:58:55,759 --> 00:58:59,529
presentation is physical security for
sensors and actuators. Here I am
628
00:58:59,529 --> 00:59:02,839
demonstrating what happens when it
overtake the control of the steering wheel
629
00:59:02,839 --> 00:59:08,789
actuator. A human will probably break in
this situation. The self driving algorithm
630
00:59:08,789 --> 00:59:13,109
in CARLA here does not realize it has lost
control of the steering wheel and is still
631
00:59:13,109 --> 00:59:20,349
trying to correct the trajectory when a
better decision would be to stop the car.
632
00:59:20,349 --> 00:59:25,299
So this is the end of the presentation. We
developed an inexpensive, safe and
633
00:59:25,299 --> 00:59:30,249
interactive platform to study and research
automotive systems. The platform is
634
00:59:30,249 --> 00:59:34,650
accessible to beginners. It is not
automotive grade, but is close enough for
635
00:59:34,650 --> 00:59:39,329
research and educational purposes. The
project is open source and with permissive
636
00:59:39,329 --> 00:59:44,436
licenses. If you have questions or ideas,
do not hesitate to contact us, especially
637
00:59:44,436 --> 00:59:49,340
if you are involved with education,
research, training, CTF, etc. And thank
638
00:59:49,340 --> 00:59:57,890
you for watching.
639
00:59:57,890 --> 01:00:02,647
Herald: Camille, thanks for this
comprehensive talk, this was amazing. We
640
01:00:02,647 --> 01:00:05,837
unfortunately don't have much time for
the questions or answers, but there is
641
01:00:05,837 --> 01:00:11,780
one question that popped up, which is
about the hardware and your PCB. How did
642
01:00:11,780 --> 01:00:15,860
you design it? How much does it cost
actually, how can you get hold of that
643
01:00:15,860 --> 01:00:19,854
thing?
Camille: So I designed everything with
644
01:00:19,854 --> 01:00:25,362
KiCAD. And I mean, I think a few years ago
it was very hard to design hardware, but
645
01:00:25,362 --> 01:00:31,859
now you have footprint libraries available
online. It has become very easy. The board
646
01:00:31,859 --> 01:00:37,341
was between 50 to 100€ for a quantity of
one. So microcontrollers are obviously the
647
01:00:37,341 --> 01:00:42,880
expensive parts and the PCB assembling
parts - it is up to the PCB Fabrication
648
01:00:42,880 --> 01:00:49,750
Service. If you have questions just ask me
on GitHub, I would be happy to answer.
649
01:00:49,750 --> 01:00:59,205
rC3 postroll music
650
01:00:59,205 --> 01:01:29,000
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!