0:00:00.000,0:00:14.524
preroll music
0:00:14.524,0:00:18.570
Camille Gay: Hello, everyone. My name is Camille. I am[br]a researcher at Toyota Motor Corporation,
0:00:18.570,0:00:21.910
and this is a presentation about RAMN, a[br]platform that we developed to make
0:00:21.910,0:00:27.651
education and research in the automotive[br]systems more accessible. The automotive
0:00:27.651,0:00:31.920
industry can be inaccessible to many[br]people because automotive projects involve
0:00:31.920,0:00:37.551
prohibitive costs and be tied to NDAs that[br]everybody is going to sign. What we want
0:00:37.551,0:00:41.530
to propose with this project is an[br]inexpensive test bed to study and research
0:00:41.530,0:00:45.649
automotive systems, which is both open[br]source and developed with open source
0:00:45.649,0:00:50.100
tools so that at least anyone can get[br]access to a good alternative for education
0:00:50.100,0:00:55.160
and research. The main focus of this test[br]bed is security, but you will see that the
0:00:55.160,0:00:59.540
usage of the test bed is not limited to[br]security, and I will keep the security
0:00:59.540,0:01:06.390
talk mostly for the end of the[br]presentation. I will start by giving a
0:01:06.390,0:01:10.860
short introduction about automotive[br]systems. Then I will present the design
0:01:10.860,0:01:15.180
details of the test bed besides[br]demonstrations and concrete details about
0:01:15.180,0:01:20.909
its hardware and software. As an example[br]of how the test bed can be used, I will
0:01:20.909,0:01:25.010
spend some time experimenting with cruise[br]control and by that I mean I will go
0:01:25.010,0:01:28.770
through the whole development process,[br]starting from evaluating the differential
0:01:28.770,0:01:33.670
equations of a simple mechanical model. I[br]will experiment with various control
0:01:33.670,0:01:38.600
strategies, implement them in C and make[br]measurements in a driving simulator using
0:01:38.600,0:01:46.000
only data from the CAN bus. And I will do[br]all that using only open source tools.
0:01:46.000,0:01:49.409
This is to demonstrate how the test bed[br]can be used, but also to have a concrete
0:01:49.409,0:01:53.780
project that I can use as a reference to[br]explain after what concretely would have
0:01:53.780,0:01:58.290
been different if we were experimenting[br]with a real electronic control unit. I
0:01:58.290,0:02:02.770
will also explain how we can get close to[br]automotive hardware and software without
0:02:02.770,0:02:07.110
signing NDAs. So the second part of the[br]talk is mainly here to give you more
0:02:07.110,0:02:11.129
information about the automotive industry[br]in case you are not familiar with it.
0:02:11.129,0:02:15.860
Before I start, let me just clarify that[br]this is not an advertisement. We are not
0:02:15.860,0:02:20.340
selling anything we present here and do[br]not profit financially from it. We're
0:02:20.340,0:02:23.700
simply showing design files whithout[br]permising licenses and without
0:02:23.700,0:02:29.870
royalties. OK, so first, let me give you a[br]very quick introduction about automotive
0:02:29.870,0:02:34.849
systems. You can see your car as a[br]collection of systems divided in four
0:02:34.849,0:02:38.230
different domains, the powertrain domain,[br]which includes the engine and the
0:02:38.230,0:02:41.739
transmission. The chassis domain, which[br]includes the steering column and
0:02:41.739,0:02:45.710
suspensions. The body domain, which[br]includes the lights, the doors and
0:02:45.710,0:02:50.109
heating, and the infotainment domain,[br]which includes navigation and
0:02:50.109,0:02:56.669
connectivity. Many of the different[br]systems that can be found in the car are
0:02:56.669,0:03:01.640
controlled by electronic control units or[br]ECUs for short. There are many kinds of
0:03:01.640,0:03:05.706
ECUs in the car. Sometimes hundreds of[br]them. And usually it's a lot hard to
0:03:05.706,0:03:09.579
understand. They have a limited number of[br]inputs, generally data from sensors and
0:03:09.579,0:03:15.930
actuators. And they have a limited number[br]of outputs generally to control actuators.
0:03:15.930,0:03:21.079
So, for example, an airbag ECU may use an[br]accelerometer as its input and an airbag
0:03:21.079,0:03:25.089
trigger as its output. The role of the ECU[br]would be to use data from the
0:03:25.089,0:03:32.150
accelerometer to detect a shock and output[br]a signal as actuator to detonate an airbag
0:03:32.150,0:03:38.930
when the shock is detected. It is very[br]common for ECUs to read data from other
0:03:38.930,0:03:44.309
ECUs. Most of the time ECUs will need to[br]share data with other ECUs on the same
0:03:44.309,0:03:48.799
domain. In the case of [unclear],[br]for example the transmission control unit
0:03:48.799,0:03:53.610
gets input from the engine ECU to[br]determine the correct gear. If the data is
0:03:53.610,0:03:58.599
critical that connection may even be[br]redundant. ECUs may also need to
0:03:58.599,0:04:02.849
communicate with ECUs on a different[br]domain. For example the brake system,
0:04:02.849,0:04:06.900
usually in the chassis domain, willl need to[br]communicate its data to store them, usually
0:04:06.900,0:04:11.379
in the body domain. Most of the time the[br]technology that is used for communication
0:04:11.379,0:04:16.720
is CAN. And CAN technology uses a bus[br]topology, which means a CAN message will
0:04:16.720,0:04:21.310
be received by all ECUs on the same CAN[br]bus, there is no authentication or
0:04:21.310,0:04:26.030
encryption at the link layer. So any[br]message can be sent by any ECU. And
0:04:26.030,0:04:32.280
security features need to be implemented[br]at higher layers. A standard CAN frame
0:04:32.280,0:04:38.330
consist mainly of an arbitration ID of 11[br]bits and a payload of 8 bytes. CAN-FD is a
0:04:38.330,0:04:46.714
recent evolution of CAN where the payload[br]size may be extended up to 64 bytes. For
0:04:46.714,0:04:51.210
an ECU network manufacturers will assign a[br]meaning to each arbitration ID and each
0:04:51.210,0:04:54.960
bit in the payload, so the file that[br]determines the traffic on the CAN bus is
0:04:54.960,0:05:01.020
often referred to as a DBC file. For[br]example, assuming a lamp controller and
0:05:01.020,0:05:06.750
two lamps on the CAN bus. The manufacturer[br]may decide that ID 123 is used by the lamp
0:05:06.750,0:05:12.180
controller to communicate the command of[br]both lamps, that ID 124 is used by the
0:05:12.180,0:05:17.680
left lamp to give feedback about the[br]status and that ID 125 is used by the
0:05:17.680,0:05:23.050
right lamp to give feedback about its[br]status. Each of those messages will be
0:05:23.050,0:05:27.830
broadcasted periodically by the assigned[br]ECU on the CAN bus and will serve as a
0:05:27.830,0:05:36.050
basis for most data exchange between ECUs.[br]So that's it for the introduction, there
0:05:36.050,0:05:40.240
are many reasons why people would be[br]interested in automotive systems and ECU
0:05:40.240,0:05:44.430
networks. The opportunity that gets by far[br]most attention from the media is
0:05:44.430,0:05:49.550
vulnerability research. But there are also[br]other reasons. For example, owners: They
0:05:49.550,0:05:53.789
want to check their car's compliance with[br]regulations such as emissions regulations
0:05:53.789,0:06:01.090
and privacy regulations. For example,[br]GDPR. Other owners may want to exercise
0:06:01.090,0:06:04.939
their rights to repair as they are[br]guaranteed by the country they live in.
0:06:04.939,0:06:09.110
And finally, some owners may want to[br]experiment and innovative DIY features or
0:06:09.110,0:06:14.740
simply satisfy their curiosity and educate[br]others. And while those may be valid
0:06:14.740,0:06:18.629
reasons to experiment with the car,[br]manufacturers are typically against people
0:06:18.629,0:06:22.349
tinkering with a car because they may be[br]worried about their intellectual property
0:06:22.349,0:06:27.300
being stolen, about vulnerabilities being[br]exploited or people hurting themselves and
0:06:27.300,0:06:33.090
others while tinkering. And what probably[br]suffers the most from this delicate
0:06:33.090,0:06:37.340
situation is education and research in[br]automotive security, because people can
0:06:37.340,0:06:41.900
not easily get access to safe equipment or[br]access the information that they would
0:06:41.900,0:06:46.890
need. In the long term, this may mean that[br]manufacturers will have less security
0:06:46.890,0:06:50.410
technologies to choose from to secure[br]their cars and that less talents would be
0:06:50.410,0:06:55.439
available to develop and evaluate them. As[br]the development, of course, involves many
0:06:55.439,0:06:59.302
people from many companies, so it is[br]important to make sure that everyone
0:06:59.302,0:07:05.550
involved is competent in automotive[br]security. And some people are pushing for
0:07:05.550,0:07:10.599
more open sourcing cars and who knows,[br]maybe one day the car will be 100%
0:07:10.599,0:07:17.000
open source, but if it happens, it is[br]going to take a long time. And
0:07:17.000,0:07:20.260
manufacturers themselves do not have[br]access to a hundred percent of the source
0:07:20.260,0:07:25.479
code of the cars they make because ECUs[br]contain intellectual property from other
0:07:25.479,0:07:29.749
companies. So this is mostly a political[br]topic. So there is not much we can
0:07:29.749,0:07:34.790
contribute to as researchers. However what[br]we can contribute technically right now is
0:07:34.790,0:07:38.970
to try the other way around and use what[br]is publicly available to make it
0:07:38.970,0:07:46.659
accessible, to learn and research[br]automotive systems. And this is what we
0:07:46.659,0:07:51.670
try to do with RAMN, which is the topic of[br]this presentation. The objective is to
0:07:51.670,0:07:56.370
provide a platform for research that is:[br]Open, and by that we mean it should be
0:07:56.370,0:08:01.350
easy to modify the source code, and[br]reprogram the ECUs; Accessible, and by
0:08:01.350,0:08:06.400
that we mean inexpensive, small and[br]requiring no prior skills in automotive
0:08:06.400,0:08:11.769
systems; Safe - with no risk of accidents or[br]legal repercussions; and motivating,
0:08:11.769,0:08:15.479
something that you can interact with so[br]that you get the same kind of experience
0:08:15.479,0:08:20.219
as you do when you experiment with a real[br]car. So already some solutions are
0:08:20.219,0:08:23.710
available if you want to experiment with[br]an ECU network. Besides, of course, a real
0:08:23.710,0:08:29.439
car, the first one is making your own test[br]bed from real ECUs so we can see many
0:08:29.439,0:08:33.470
hackers sharing the test bed at security[br]conferences. And usually if you see
0:08:33.470,0:08:37.389
something like this, you stop and you[br]immediately get interested. So it is a
0:08:37.389,0:08:41.690
nice way to motivate people to learn.[br]Unfortunately, those are not easy to
0:08:41.690,0:08:45.290
reprogram because manufacturers do not[br]share information about the ECUs and they
0:08:45.290,0:08:52.850
require a lot of skills to build. So it's[br]not accessible to everyone. Another option
0:08:52.850,0:08:57.690
is to use development boards such as[br]Arduino, and that is what you can see
0:08:57.690,0:09:02.250
mostly on academic papers. They have the[br]advantage of being reproducible and you
0:09:02.250,0:09:06.680
can modify the source code as you want. So[br]they can be used in many cases for
0:09:06.680,0:09:12.000
research. But they lack many safety[br]features offered on an actual ECU hardware
0:09:12.000,0:09:18.870
and software. Even if you are able to[br]simulate a CAN bus, you don't get the same
0:09:18.870,0:09:23.520
level of interaction as you do with a real[br]car. So it's not something that motivates
0:09:23.520,0:09:31.240
people and makes them want to learn more.[br]And the third option is to use a
0:09:31.240,0:09:35.340
professional test bed such as Pasta -[br]another work from our team. This is a good
0:09:35.340,0:09:38.680
option because you get access to the[br]source code and you can reprogram the ECUs
0:09:38.680,0:09:42.670
and the CAN bus network is already[br]simulating a full car. So the groundwork
0:09:42.670,0:09:47.300
is already done. So major drawback are[br]that it is very expensive. So it is not
0:09:47.300,0:09:52.459
accessible to everyone. So there are some[br]options to study and research automotive
0:09:52.459,0:09:56.600
systems, but none of them seem to be both[br]accessible and motivating at the same
0:09:56.600,0:10:00.540
time. So many people don't even think of[br]running automotive systems because it
0:10:00.540,0:10:04.960
never occurred to them that they could[br]like it. And in comparison with other
0:10:04.960,0:10:08.660
industries, you have so many ways to get[br]started, if you want to learn about Linux,
0:10:08.660,0:10:12.180
you can start with a Raspberry Pi. If you[br]want to learn about electronics you can
0:10:12.180,0:10:17.190
start with an Arduino and so on. So we[br]wanted something that would give a similar
0:10:17.190,0:10:26.860
experience, but for automotive systems. So[br]we noticed that most of the test beds that
0:10:26.860,0:10:31.850
people are using to experiment with ECUs[br]are made of 4 ECUs. So the ECUs are often
0:10:31.850,0:10:38.860
communicating with each other using a CAN[br]bus. So we tried to fit all that in a PCB
0:10:38.860,0:10:43.730
the size of a credit card. And we named[br]that PCB RAMN. It features four ECUs
0:10:43.730,0:10:50.370
connected over a common CAN bus or CAN-FD[br]bus, which is accessible from outside by a
0:10:50.370,0:10:58.106
terminal block. One of the ECUs is also[br]connected to USB, which is also the power
0:10:58.106,0:11:02.389
supply. PIN-sockets can be used to[br]connect sensors, actuators and additional
0:11:02.389,0:11:07.170
hardware and the board features many[br]probes to easily access important electric
0:11:07.170,0:11:16.950
signals. The 4 ECUs simulate a CAN network[br]with messages identical to Pasta. The name
0:11:16.950,0:11:21.430
RAMN is obviously a reference to Pasta as[br]this is a cheap alternative, mostly aimed
0:11:21.430,0:11:26.880
at students. In real cars CAN messages[br]typically have different payload sizes,
0:11:26.880,0:11:30.570
but by default we operate with maximum[br]payload size, to demonstrate heavy
0:11:30.570,0:11:35.740
traffic, so the basic format is like this:[br]Arbitration ID, 2 bytes for the data,
0:11:35.740,0:11:40.320
2 bytes for a counter and 4 bytes of[br]additional data, random data used as a
0:11:40.320,0:11:47.220
placeholder for additional data such as[br]checksum or MAC. You can easily modify the
0:11:47.220,0:11:51.350
CAN bus's arbitration ID end format. And[br]here we are assuming a full by-wire
0:11:51.350,0:11:55.510
vehicle, which means all physical[br]functions of a car are accessible to the
0:11:55.510,0:12:02.290
CAN bus, which is usually not the case on[br]current cars. The block diagram of RAMN
0:12:02.290,0:12:06.480
looks like this. And as I explained[br]earlier, all ECUs are periodically
0:12:06.480,0:12:10.770
exchanging messages on the CAN bus. If you[br]connect a CAN adapter and have a look at
0:12:10.770,0:12:22.740
the traffic, it will typically look like[br]this. So the board itself is enough to
0:12:22.740,0:12:27.279
simulate an ECU network, but it does not[br]look very motivating. What we wanted on
0:12:27.279,0:12:33.570
top of this was some sensors and actuators[br]to make it more interactive. So we created
0:12:33.570,0:12:37.960
4 expansion boards for sensors and[br]actuators. To simulate the infotainment
0:12:37.960,0:12:43.209
domain, we simply use a screen. For the[br]body domain, we use an engine key and some
0:12:43.209,0:12:52.290
LEDs. For the chassis domain we mainly use[br]a slide switch to simulate a side brake
0:12:52.290,0:12:57.170
and a rotating potentiometer to simulate[br]the steering wheel. And for the power
0:12:57.170,0:13:00.810
train domain we use slide potentiometers[br]for the brake and accelerator and a
0:13:00.810,0:13:09.046
joystick for the shift lever. The EC[br]connected to USB implements a standard CAN
0:13:09.046,0:13:14.019
or CAN-FD interface, either of a standard[br]serial port using Slcan or over a native
0:13:14.019,0:13:17.991
interface on Linux thanks to the[br]counterlight firmware projects. If you
0:13:17.991,0:13:22.120
connect the board to a USB port on the[br]computer, it should be recognized as a USB
0:13:22.120,0:13:26.160
to CAN adapter. So it is not necessary to[br]own an external CAN adapter to get
0:13:26.160,0:13:33.060
started. This is a demo of what it looks[br]like to use RAMN. Just connect it over
0:13:33.060,0:13:39.199
USB, if you use Linux, you can get it to be[br]recognized as a standard CAN network
0:13:39.199,0:13:44.540
interface. So it will show up in ifconfig.[br]Then you can use various tools available
0:13:44.540,0:13:48.379
on Linux to observe the traffic, for[br]example CAN sniffer. Here you can see the
0:13:48.379,0:13:58.520
traffic explained earlier, the CAN IDs on[br]the left and the payload on the right. So
0:13:58.520,0:14:02.970
with this, we can simulate a ECU network[br]with sensors and actuators, which is
0:14:02.970,0:14:06.639
enough for basic interactions. But it[br]still doesn't feel like you are actually
0:14:06.639,0:14:11.699
experimenting with a car. Ideally the ECUs[br]should be performing realistic ECU
0:14:11.699,0:14:16.990
functions, not just lighting up LEDs based[br]on some switches and potentiometers. And
0:14:16.990,0:14:20.320
for this we thought of a connection in a[br]closed loop with an open source driving
0:14:20.320,0:14:28.149
simulator which is an affordable and safe solution. [br]To feel like you are driving the ECU network.
0:14:28.149,0:14:32.839
Fortunately, there is a great open source[br]driving simulator for autonomous driving
0:14:32.839,0:14:36.810
research. It is called CARLA. It features[br]a Python API. So it is very easy to
0:14:36.810,0:14:42.080
interact with it and it also comes with an[br]example self-driving algorithm. So you can
0:14:42.080,0:14:48.670
immediately start experimenting with your[br]virtual self-driving car. So we wrote some
0:14:48.670,0:14:53.770
scripts so that most sensors values for[br]example speed and altitude would be
0:14:53.770,0:14:58.570
simulated on the computer running CARLA.[br]Then broadcasted on the CAN bus. On the
0:14:58.570,0:15:02.540
other side we made it so that all controls[br]of CARLA such as throttle, steering and
0:15:02.540,0:15:07.829
brakes will be decided by the ECU network.[br]And this is what you could refer to as
0:15:07.829,0:15:12.379
HILs or Hardware-In-The-Loop simulation in[br]the automotive industry, RAMN is not as
0:15:12.379,0:15:30.208
advanced as professional tools, but at[br]least it is accessible. So to achieve
0:15:30.208,0:15:33.949
manual control, it is not complicated with[br]CARLA. On the manual control example
0:15:33.949,0:15:38.330
provided with the API there is a while[br]true game loop that with events of the
0:15:38.330,0:15:44.730
keyboard, applies controls, then updates[br]the physics simulation. So CARLA does not
0:15:44.730,0:15:48.829
simulate the CAN bus by default so we[br]created a Python class to easily interact
0:15:48.829,0:15:52.839
with the CAN bus using the CAN message[br]specifications of RAMN. To integrate it
0:15:52.839,0:15:56.709
with CARLA we just need to replace[br]keyboard controls with actuator control
0:15:56.709,0:16:02.390
data read from the CAN bus. To close the[br]loop we broadcast sensor data using CAN
0:16:02.390,0:16:08.450
messages based on data retrieved from the[br]Python API of the physics simulator. And
0:16:08.450,0:16:14.970
with this we are able to control the car[br]manually, the potentiometers on the board.
0:16:14.970,0:16:19.319
Here I gently press accelerator, release[br]the handbrake, and I can control the car
0:16:19.319,0:16:39.539
using the steering wheel [br]on the expansion board.
0:16:39.539,0:17:03.500
Video stops
0:17:03.500,0:17:05.250
So manual control is nice, but
0:17:05.250,0:17:09.520
automatic control is better because[br]ultimately we want to focus on working on
0:17:09.520,0:17:14.000
the CAN bus. So on the original CARLA[br]project, there was also an example script
0:17:14.000,0:17:18.900
for automatic control. Again there is a[br]while true loop where the code basically
0:17:18.900,0:17:22.790
simulates the physics, lets the self-[br]driving AI make a decision, then applies
0:17:22.790,0:17:30.680
the controls to the physics simulation. To[br]integrate RAMN in this certain algorithm,
0:17:30.680,0:17:34.200
again, we need to replace the apply[br]control part with the controls from the
0:17:34.200,0:17:38.980
ECU network. We also need to send CAN[br]messages with sensor data retrieved from
0:17:38.980,0:17:44.070
the Python API of the physics simulation.[br]That is identical to having manual
0:17:44.070,0:17:50.420
control. What we need to do more is also[br]send a message to broadcast the status of
0:17:50.420,0:17:57.180
the AI to the ECU Network, so that the ECU[br]network knows what controls the AI
0:17:57.180,0:18:05.860
algorithm is requesting. So periodically[br]the AI would broadcast its status by
0:18:05.860,0:18:10.180
sending messages over USB, which are[br]converted into CAN messages by the ECU
0:18:10.180,0:18:15.950
input to USB. All ECUs on the network will[br]receive those messages and will decide the
0:18:15.950,0:18:22.410
actual controls of the car based on their[br]own algorithm. For example, the power
0:18:22.410,0:18:26.800
train ECU may decide to apply brakes[br]depending on the highest value between the
0:18:26.800,0:18:33.260
AI brakes and the brake potentiometer. All[br]ECUs will receive the CAN message and
0:18:33.260,0:18:38.521
apply the control, some ECUs may filter[br]that message if they do not need it. Some
0:18:38.521,0:18:44.190
ECUs like the body ECU may process it and[br]take action. For example, if the brakes
0:18:44.190,0:18:49.790
are engaged, the body ECU will light up[br]the stop lamp on the expansion board.
0:18:49.790,0:18:55.240
Finally, the ECU connected to USB will[br]forward the brake controls to the
0:18:55.240,0:19:02.350
simulator that will apply the brakes in[br]the physics simulation. So this is what it
0:19:02.350,0:19:06.870
actually looks like, all I need to do[br]again is release the handbrake and the car
0:19:06.870,0:19:12.670
will drive itself. The car is controlled[br]by the ECU network, so when the car stops
0:19:12.670,0:19:15.760
in the simulation, it is because the[br]controls were applied by the power train
0:19:15.760,0:19:21.450
ECU. You can see that the stop lamp lights[br]up because the body ECU also received and
0:19:21.450,0:19:31.440
processed the break CAN message. Since the[br]ECU is in charge of the controls, I can
0:19:31.440,0:19:45.040
force the car to stop any time by forcing[br]brakes on the power train ECU potentiometer.
0:19:45.040,0:19:47.930
So if you connect an external [br]CAN adapter to the CAN bus,
0:19:47.930,0:19:52.620
you'll be able to send and receive[br]messages. So using RAMN you can experiment
0:19:52.620,0:20:03.150
with the CAN bus of the self-driving[br]virtual car. When you want to reprogram an
0:20:03.150,0:20:07.290
ECU in the real world, you have two[br]options. Either you interact with the
0:20:07.290,0:20:10.750
hardware bootloader of the ECUs[br]microcontroller, which depends on the
0:20:10.750,0:20:14.480
microcontrollers model and manufacturer,[br]or you interact with diagnostics and
0:20:14.480,0:20:19.460
calibration software, which depends on the[br]car model and manufacturer. Diagnostic and
0:20:19.460,0:20:24.330
calibration are often done on the CAN bus,[br]but other options may be available.
0:20:24.330,0:20:30.290
Protocols are defined by standard[br]documents. You often hear about UDS and
0:20:30.290,0:20:34.920
OBD-II which both rely on the same[br]transport layer ISO-TP. But there are also
0:20:34.920,0:20:43.050
other protocols, such as Keyword Protocol[br]2000 or XCP. All those protocols can often
0:20:43.050,0:20:49.520
also be implemented over other layers. For[br]the hardware bootloaders it depends on the
0:20:49.520,0:20:54.120
microcontroller manufacturer. For example[br]for an STM 32 microcontroller you can
0:20:54.120,0:20:58.770
reprogram the firmware by interacting over[br]CAN according to the application note
0:20:58.770,0:21:04.770
3154, over USB according to the[br]application note 3156. Or using other
0:21:04.770,0:21:11.600
protocols defined in other application[br]notes. In the case of RAMN, we use the
0:21:11.600,0:21:16.160
hardware bootloader to reprogram the ECUs[br]and you can also use a UDS protocol over
0:21:16.160,0:21:24.240
CAN. And in the future we may consider[br]adding XCP and KWD 2000. How to reprogram
0:21:24.240,0:21:28.240
an ECU using calibration and diagnostic[br]software is a topic that is already
0:21:28.240,0:21:32.570
heavily discussed at automotive security[br]talks, I will not spend time on this
0:21:32.570,0:21:37.550
topic. You can find the definition of the[br]standards online. Usually you need to pay
0:21:37.550,0:21:43.570
for them. But you can also find summaries[br]for free on some websites. For example,
0:21:43.570,0:21:51.720
Wikipedia. What is more interesting to[br]discuss here is the hardware bootloader.
0:21:51.720,0:21:54.950
The various ways to force a microcontroller [br]into bootloader mode are
0:21:54.950,0:22:01.650
described in the application note 2606.[br]The format of CAN messages we need to send
0:22:01.650,0:22:06.650
to interact with the bootloader is defined[br]in the application note 3154. And it's not
0:22:06.650,0:22:11.770
complicated. The format is simply common[br]byte plus argument. All that within the
0:22:11.770,0:22:18.850
same CAN message payload. So we wrote some[br]script to make it easier to interact with
0:22:18.850,0:22:27.900
the bootloader. So here I am showing the[br]script that we use to interact with the
0:22:27.900,0:22:32.260
bootloader. First thing I do is retrieve[br]all information from the bootloader,
0:22:32.260,0:22:38.030
including the version, the supported[br]commands and the Chip ID. I then use a
0:22:38.030,0:22:44.410
read memory command to dump all known[br]sections of memories. This includes the
0:22:44.410,0:22:48.890
ECU firmware. So it can be a good start to[br]start experimenting with reverse
0:22:48.890,0:23:03.580
engineering. We can also activate memory[br]without protection and see what happens
0:23:03.580,0:23:18.900
when you try to dump the memory again. And[br]in this case is not allowing memory dumps
0:23:18.900,0:23:22.120
anymore. You can remove the memory[br]protection, which will wipe out the
0:23:22.120,0:23:46.900
memory, and after you do that, you can use[br]the bootloader to reprogram the ECUs. For
0:23:46.900,0:23:50.730
the hardware we also designed additional[br]expansion boards with various features.
0:23:50.730,0:23:56.070
First one is an expansion to connect a[br]JTAG debugger. Second one is about to add
0:23:56.070,0:24:02.000
extra QuadSPI Memories, which is why you[br]see packages such as EEPROM, FRAM, NAND,
0:24:02.000,0:24:09.530
SRAM and so on. The third one is a board[br]to add a trusted platform module. And the
0:24:09.530,0:24:22.650
last one is an interface to easily connect[br]a chip whisperer. All those expansions are
0:24:22.650,0:24:26.980
compatible with each other, so you can[br]stack them and create a very advanced ECU
0:24:26.980,0:24:33.870
network with all ECUs between a TPM and[br]one gigabit of memory. And it looks better
0:24:33.870,0:24:40.560
when the expansions are stacked on top of[br]each other. Since we would like to use
0:24:40.560,0:24:45.190
RAMN for education, we try to vary the[br]type of electrical signals using the
0:24:45.190,0:25:04.540
expansions. And we added many external[br]probes to easily connect external tools. You
0:25:04.540,0:25:08.550
can use one of the many excellent probes[br]to connect an oscilloscope and have a look
0:25:08.550,0:25:18.070
at analog signals. For example, here's the[br]brake potentiometer. Or connect a logic
0:25:18.070,0:25:23.700
analyzer and have a look at digital[br]signals, for example, to analyze SPI
0:25:23.700,0:25:34.220
communication between the ECU and the[br]screen. For the hardware design we kept it
0:25:34.220,0:25:38.770
simple using only two layers and keeping[br]all components on the same side. We
0:25:38.770,0:25:41.760
designed the hardware with flash[br]tolerances which should be easy to produce
0:25:41.760,0:25:47.540
with most PCB fabrication services. We use[br]components with large size. So if you have
0:25:47.540,0:26:00.270
some skills in soldering, you should be[br]able to solder one yourself. We designed
0:26:00.270,0:26:04.570
the hardware using KiCAD, which is an open[br]source tool for designing hardware. You
0:26:04.570,0:26:13.360
can easily modify the schematics, layout[br]and even generate nice 3D views. So
0:26:13.360,0:26:18.550
firmware is designed using STM32CubeIDE,[br]it is accessible to beginners, and you can
0:26:18.550,0:26:23.300
easily reconfigure peripherals and clocks[br]from the graphical interface. You will
0:26:23.300,0:26:27.950
even get some statistics, such as the[br]estimated power consumption. But of
0:26:27.950,0:26:31.500
course, you do not need to use the[br]graphical interface and libraries if you
0:26:31.500,0:26:38.091
would rather program everything yourself[br]by interacting directly with registers. We
0:26:38.091,0:26:42.900
use free RTOS as a Real-Time operating[br]system. The basic software of ECUs has
0:26:42.900,0:26:46.970
several tasks running in parallel, one for[br]receiving CAN messages, one for sending
0:26:46.970,0:26:52.540
CAN messages and several periodic tasks to[br]take care of the ECU control loops. Those
0:26:52.540,0:26:57.950
tasks receive data from different[br]interrupt services within, using queues and
0:26:57.950,0:27:03.740
DMA memory overwrites. The tasks can also[br]exchange data between each other using
0:27:03.740,0:27:11.620
queues or memory overwrites. Again, to[br]keep the project accessible to beginners,
0:27:11.620,0:27:15.240
we did the OS configuration using the[br]graphical interface where you can see all
0:27:15.240,0:27:19.620
tasks and their configuration, for example[br]the priority. You can add or remove
0:27:19.620,0:27:23.610
interrupts. And you can also configure the[br]various queues in memory. There is still a
0:27:23.610,0:27:31.260
lot of memory left even though the memory[br]controller is less performant. So you can
0:27:31.260,0:27:41.050
easily add your own application on top of[br]this. That's all for the hardware and
0:27:41.050,0:27:45.150
software section, you can find more[br]details on GitHub. I would like to move to
0:27:45.150,0:27:50.110
the next section and show you a usage[br]example. There are usually two budgets for
0:27:50.110,0:27:54.190
people working in automotive security[br]Either they are automotive engineers who
0:27:54.190,0:27:58.640
learn about security or they are security[br]engineers who wrote about automotive
0:27:58.640,0:28:03.050
systems. Since this is a security[br]conference and I assume most people do not
0:28:03.050,0:28:07.310
need me to explain how the platform can be[br]used to study and research basic security
0:28:07.310,0:28:15.150
topics, I will focus on the automotive[br]side. So diagnostics and calibration topic
0:28:15.150,0:28:25.070
is already covered by many security [br]talks. I will not spend time on this. So
0:28:25.070,0:28:29.890
I will spend time on something[br]that is not often mentioned at security
0:28:29.890,0:28:37.000
conferences: Control algorithms and safety[br]critical hardware and software. And for
0:28:37.000,0:28:39.960
this, I would like to demonstrate the[br]design of a PID controller for cruise
0:28:39.960,0:28:43.790
control as an example. I will show you how[br]being knowledgeable in control systems may
0:28:43.790,0:28:49.490
be relevant to security engineers, and how[br]many of the activities that are done by
0:28:49.490,0:28:54.860
engineers in the automotive industry can[br]also be simulated using open source tools,
0:28:54.860,0:29:01.380
including RAMN. Once we have an[br]implementation in C that works, I would
0:29:01.380,0:29:04.920
then use it as a reference to talk about[br]safety critical systems and the
0:29:04.920,0:29:14.221
differences with real ECU hardware and[br]software. So let's get started. Cruise
0:29:14.221,0:29:17.890
control is very simple: When a human is[br]controlling the throttle with the
0:29:17.890,0:29:24.820
accelerator pedal depending on the skill[br]the car may have an uneven speed. What we
0:29:24.820,0:29:28.820
want is an ECU that optimizes the control[br]of the throttle so that we can maintain a
0:29:28.820,0:29:37.310
steady speed. An automatic car can be very[br]easy to model. If you press the
0:29:37.310,0:29:41.350
accelerator pedal, which opens the[br]throttle, you will get speed out of your
0:29:41.350,0:29:45.590
car. But the relationship between speed[br]and throttle is not as simple as a
0:29:45.590,0:29:50.480
multiplication. No, we have to follow the[br]laws of dynamics. In this case that's the
0:29:50.480,0:29:56.760
sum of forces on the car is equal to its[br]mass times its acceleration. We can
0:29:56.760,0:30:00.640
consider that there is a force pushing the[br]car that is proportional to the throttle,
0:30:00.640,0:30:06.140
and that there is an opposing force[br]proportional to the speed due to friction.
0:30:06.140,0:30:12.110
When we solve this diversal equation, what we[br]expect to see is that the speed follows an
0:30:12.110,0:30:17.990
exponential curve. And a simple way to[br]control the speed that may come to your
0:30:17.990,0:30:22.240
mind is open loop control. You make some[br]measurements on the flat road of the
0:30:22.240,0:30:26.860
relationship between throttle and maximum[br]speed, and you keep in a lookup table.
0:30:26.860,0:30:31.380
When the user asks the ECU to reach a[br]certain speed, the ECU can use the lookup
0:30:31.380,0:30:38.250
table to find what throttle controls[br]should be applied based on past
0:30:38.250,0:30:43.330
measurements. And this may work in some[br]situations, but according to the laws of
0:30:43.330,0:30:51.170
dynamics, as soon as we reach an upward[br]slope, the car will lose speed because of
0:30:51.170,0:30:56.420
gravity. So at least that is what we[br]expect, but we should verify that on the
0:30:56.420,0:31:02.230
CAN bus. This is something we can use RAMN[br]for. Here again, using an external CAN
0:31:02.230,0:31:07.980
adapter connected to a second PC. On that[br]PC I simply receive data from the physical
0:31:07.980,0:31:13.140
CAN bus. For the rest of the section I[br]will only be modifying the firmware on the
0:31:13.140,0:31:25.560
power train ECU. I will not change the[br]simulator, I will not even reboot it.
0:31:25.560,0:31:30.610
So in the simulator, I drove around the city[br]to try to find a nice place to experiment.
0:31:30.610,0:31:40.280
More precisely, I looked for a place with[br]flat road followed by an upward slope.
0:31:40.280,0:31:44.070
Then I programmed the power train ECU to a[br]apply a constant throttle, which is only
0:31:44.070,0:31:49.220
one line of code. And after reprogramming[br]the ECU I let the car drive straight and I
0:31:49.220,0:32:08.220
recorded data from the CAN bus. I used an[br]open source tool for CAN bus analysis
0:32:08.220,0:32:14.040
called Bus Master. Bus Master allows you[br]to load DBC files or to input manually the
0:32:14.040,0:32:18.770
format of your CAN frames. Here I simply[br]told Bus Master what were the CAN
0:32:18.770,0:32:24.010
arbitration IDs of the throttle control[br]message and the speed sensor message. And
0:32:24.010,0:32:30.110
what was the format of the payload. Once I[br]do that, I can plot the evolution of the
0:32:30.110,0:32:36.190
throttle and speed over time. And the[br]results we get are exactly what we
0:32:36.190,0:32:40.810
expected from our differential equations.[br]The speed of the vehicle is following an
0:32:40.810,0:32:44.380
exponential curve and as soon as we reach[br]the upward slope, we start loosing speed
0:32:44.380,0:32:49.220
because the throttle is constant. There[br]are some noise and non-linearities at low
0:32:49.220,0:32:54.270
speed but overall it seems our model of[br]the car is correct. We are approaching the
0:32:54.270,0:33:01.320
problem correctly. What we can see here is[br]that it takes about 40 seconds for one
0:33:01.320,0:33:06.400
test-drive. And 40 seconds is already too[br]long. So before testing the ECU in the
0:33:06.400,0:33:09.890
driving simulator, we want to use the[br]software that can simulate differential
0:33:09.890,0:33:13.790
equations so that we can see the impact of[br]the cruise control algorithm directly,
0:33:13.790,0:33:18.960
without having to wait for 40 seconds.[br]Most of the time this is done using a
0:33:18.960,0:33:25.330
professional tool such as Matlab and[br]Simulink. But here we will use open source
0:33:25.330,0:33:30.460
tool Scilab. It has a graphical interface[br]where we can connect inputs and outputs
0:33:30.460,0:33:37.230
from a block diagram. Differential[br]equations are a bit hard to deal with
0:33:37.230,0:33:41.120
because the relationship between inputs[br]and outputs is complicated. What you
0:33:41.120,0:33:45.640
typically do in control theory is use a[br]Laplace transform, which will change the
0:33:45.640,0:33:50.590
variable called t to a complex number[br]called s. This may be complicated with a
0:33:50.590,0:33:53.980
contradictory background, but you just[br]need to know that a differentiation is
0:33:53.980,0:33:58.680
equivalent to a multiplication by s and[br]that integration is equivalent to division
0:33:58.680,0:34:05.300
by s. In our system it is easier to model[br]the Laplace transform because we now have
0:34:05.300,0:34:09.730
a simple relationship between throttle and[br]speed. Speed equals transfer function of
0:34:09.730,0:34:18.199
car times throttle. And based on the[br]measurements from the CAN bus, we can
0:34:18.199,0:34:25.760
evaluate the transfer function of the car[br]to be equal to approximately 1 / (1 + 4s).
0:34:25.760,0:34:30.299
We can simulate the car in Scilab by[br]using a block function which has the exact
0:34:30.299,0:34:36.960
same transfer function. Using Scilab, we[br]can now test various scenarios and get the
0:34:36.960,0:34:41.389
results immediately. Here I am testing the[br]scenario in which we start from zero
0:34:41.389,0:34:46.760
speed, apply a constant throttle and after[br]20 seconds, we add a new force - gravity -
0:34:46.760,0:34:52.950
which corresponds to the slope. And this[br]is what we call here the disturbance. And
0:34:52.950,0:34:57.490
with Scilab simulation we can verify we[br]get waveforms similar to our measurements
0:34:57.490,0:35:01.519
on the CAN bus. With a constant throttle,[br]the speed follows an exponential curve
0:35:01.519,0:35:07.990
that is close to maximum speed after[br]around 14 seconds. And as soon as there is
0:35:07.990,0:35:11.840
a disturbance: the gravity here, showing[br]green, we can check that the car looses
0:35:11.840,0:35:18.390
speed because there is no reaction from[br]the throttle. So to fix that the solution
0:35:18.390,0:35:24.740
is obvious: The ECUs need to have[br]feedback. We need the ECU to make use of
0:35:24.740,0:35:29.670
the speed sensor data that it can find on[br]the CAN bus so that it can adapt the
0:35:29.670,0:35:35.480
throttle to the actual speed of the[br]vehicle. So first solution that may come
0:35:35.480,0:35:40.160
to mind to software engineers is Bang-Bang[br]Control. Bang-Bang Control is quite
0:35:40.160,0:35:45.460
simple. You measure the speed and if it is[br]above a certain threshold, you stop
0:35:45.460,0:35:49.730
applying the throttle. If it goes below a[br]certain threshold, you apply the throttle
0:35:49.730,0:35:58.619
again. This is extremely easy to implement[br]in C on the ECU. And once we reprogram the
0:35:58.619,0:36:03.009
ECU on RAMN, we can make measurements on[br]the CAN bus and verify that this time we
0:36:03.009,0:36:09.049
are not loosing speed anymore when we[br]reach a slope. But as you can see, there
0:36:09.049,0:36:13.799
are some oscillations. And as you can[br]imagine, the oscillations are not
0:36:13.799,0:36:18.430
something very nice for passengers.[br]Apparently people driving like this is the
0:36:18.430,0:36:22.890
reason cruise control was invented. I do[br]not know if that story is true, but I can
0:36:22.890,0:36:27.710
believe it. So Bang-Bang Control made a[br]good start, but it is not good enough for
0:36:27.710,0:36:35.660
cruise control. And the most famous[br]algorithm used in control theory is the
0:36:35.660,0:36:40.280
PID controller. You can find a lot of[br]resources online. The PID controller is
0:36:40.280,0:36:44.829
one of the control mechanism used in[br]software of the self-driving AI of CARLA.
0:36:44.829,0:36:48.960
In the PID controller you measure the[br]difference between the target speed and
0:36:48.960,0:36:54.849
the current speed. You call that different[br]error and you can control the throttle
0:36:54.849,0:36:59.799
using the sum of 3 control blocks. The[br]error multiplied by Kₚ. The integral of
0:36:59.799,0:37:05.740
the error multiplied by Kᵢ and the[br]derivative of the error multiplied by Kd.
0:37:05.740,0:37:17.099
Kₚ, Kᵢ and Kd are constant called gains.[br]And you need to have a very fine tuning of
0:37:17.099,0:37:22.140
those gains to achieve optimal control.[br]Here I can simulate the PID controller
0:37:22.140,0:37:27.289
using Scilab with different blocks.[br]Remember that the division by s is an
0:37:27.289,0:37:32.869
integration, and the multiplication by s[br]is a derivation. Thanks to the simulation
0:37:32.869,0:37:37.549
I am able to try many values without[br]having to actually drive the car. And when
0:37:37.549,0:37:47.750
we are able to find correct values for the[br]PID controller, we get this. The ECU is
0:37:47.750,0:37:51.240
able to reach a target quite quickly[br]without oscillations and without
0:37:51.240,0:37:57.559
overshooting the maximum speed. And when[br]there is a disturbance so gravity, it will
0:37:57.559,0:38:02.000
dynamically adapt the controls of the[br]throttle so that the target speed is
0:38:02.000,0:38:07.829
maintained. So this is good, because this[br]is what we want for cruise control. But is
0:38:07.829,0:38:13.039
a gain of only one control block is[br]correct, the speed of the vehicle may look
0:38:13.039,0:38:16.539
like something totally different,[br]potentially dangerous. And this is why the
0:38:16.539,0:38:21.190
integrity of calibration data is important[br]not only from a safety point of view, but
0:38:21.190,0:38:25.230
also from a security point of view.[br]Because an attacker should not be able to
0:38:25.230,0:38:37.110
make an ECU have a dangerous behavior with[br]only one small change. The last thing I
0:38:37.110,0:38:41.119
need to explain is how to implement these[br]algorithms in C, and this is not obvious
0:38:41.119,0:38:45.470
because we're dealing with integration and[br]derivations, which are not possible for
0:38:45.470,0:38:51.190
digital functions. So there are many ways[br]to implement this in a digital PID
0:38:51.190,0:38:58.109
controller in C. I will just explain two[br]approaches. The first approach is to stay
0:38:58.109,0:39:02.320
in the time domain and approximate the[br]derivation by the difference between two
0:39:02.320,0:39:07.400
successive errors divided by the sampling[br]time. And we can approximate the integral
0:39:07.400,0:39:14.930
operation with a Riemann sum which is a[br]running sum of errors so far multiplied by
0:39:14.930,0:39:20.940
the sampling time. This may look a bit[br]intimidating, but when you look at it
0:39:20.940,0:39:25.190
closely, you can see it is just a[br]combination of constants and values that
0:39:25.190,0:39:33.400
can be computed from current and past[br]sensor values from the CAN bus. The actual
0:39:33.400,0:39:39.380
implementation in C looks like this. We[br]need to define 2 variables. One to store
0:39:39.380,0:39:45.630
the running sum of errors and one to store[br]the error of the previous control loop
0:39:45.630,0:39:51.280
execution. In the control loop, we define[br]constant gains for each stage. We compute
0:39:51.280,0:40:00.119
the current error. We add the error to the[br]sum of all errors. We compute the
0:40:00.119,0:40:05.450
difference between current errors and[br]previous error. We then add all those
0:40:05.450,0:40:10.420
values with the respective gain to the[br]output variable and then we clamp that
0:40:10.420,0:40:16.730
output in case it goes out of bound. We[br]then apply the throttle control and save
0:40:16.730,0:40:24.780
the current error in the previous error[br]variable for use in the next iteration.
0:40:24.780,0:40:30.849
The second approach is to use a Laplace[br]transform of the PID controller. We first
0:40:30.849,0:40:34.930
need to convert it to a Z transform, the[br]equivalent of Laplace transform but for
0:40:34.930,0:40:38.970
digital signals. It looks a bit[br]complicated, but there are many tools to
0:40:38.970,0:40:44.369
do the conversion for you. If you want to[br]do the conversion by hand, one way is to
0:40:44.369,0:40:55.059
use the bilinear transformation in which[br]you replace s by this, to approximate the Z
0:40:55.059,0:41:06.529
transform of your ECU. And again, this may[br]all look a bit intimidating, but you can
0:41:06.529,0:41:10.950
actually compute the throttle output by[br]using the throttle output from 2
0:41:10.950,0:41:16.789
iterations ago, the current error, the[br]previous error and the error before that
0:41:16.789,0:41:21.230
which can all be computed from sensor[br]values on the CAN bus. And while this
0:41:21.230,0:41:26.159
control algorithm is equivalent to our[br]previous implementation, it looks totally
0:41:26.159,0:41:32.130
different. And what I would like to stress[br]here that identical control algorithms may
0:41:32.130,0:41:35.960
have very different software[br]implementations, which may be relevant for
0:41:35.960,0:41:47.859
reverse engineers. I only show the first[br]implementation not waste time, but you can
0:41:47.859,0:41:52.589
see now that the ECU in RAMN is able to[br]make the car maintain a constant speed and
0:41:52.589,0:42:05.269
for dynamic control of the throttle. So[br]that's it for the example. I just wanted
0:42:05.269,0:42:08.880
to show that RAMN can be used for[br]realistic activities of the CAN bus and
0:42:08.880,0:42:14.430
that the ECUs are not just doing some[br]random easy work. The control theory part
0:42:14.430,0:42:18.460
may be complicated and if that was going[br]too fast for you at least I hope it proves
0:42:18.460,0:42:22.269
there is a lot of things to discover and[br]experiment with. And that all that
0:42:22.269,0:42:37.420
learning can be done with open source[br]tools. Now I would like to discuss what
0:42:37.420,0:42:41.430
would have been different with real ECUs[br]because, as you can imagine, actual ECU
0:42:41.430,0:42:47.279
software is not as simple as this. I will[br]also show you what alternatives we have.
0:42:47.279,0:42:53.119
Technologies hidden behind NDAs, so that[br]we can get as close as we can to real
0:42:53.119,0:42:59.630
ECUs. We showed in RAMN that this cruise[br]control ECU worked, but we only tried it
0:42:59.630,0:43:06.030
on a single scenario, namely a flat road[br]followed by an upward slope. But what
0:43:06.030,0:43:09.970
about this scenario in which a car in[br]front is driving slowly? Or what about a
0:43:09.970,0:43:14.619
scenario in which we are in a downward[br]slope? In this case the ECU will not be
0:43:14.619,0:43:18.390
able to prevent a car from going too fast[br]because it does not have access to the
0:43:18.390,0:43:24.750
brakes, which could lead to an accident.[br]And the difficult problem here is not
0:43:24.750,0:43:29.110
whether you can think of one more[br]scenario. The difficult problem is can you
0:43:29.110,0:43:34.430
think of them all are you sure? And[br]thinking of all potential scenarios,
0:43:34.430,0:43:38.430
quantifying the risk and implementing[br]countermeasures is what makes automotive
0:43:38.430,0:43:46.970
systems really different. And to prove[br]that an ECU is reasonably safe, you
0:43:46.970,0:43:52.569
actually need to follow ISO 26262[br]standard, which is a standard for
0:43:52.569,0:43:58.740
functional safety. The standard defines[br]different requirements at many levels. Not
0:43:58.740,0:44:03.480
all ECUs are equally critical, so safety[br]relevant issues are assigned and
0:44:03.480,0:44:10.349
automotive safety integrity level or ASIL[br]for short. And ASIL A is a less critical
0:44:10.349,0:44:17.369
level and ASIL D is the most critical[br]level. So if you were to design a real
0:44:17.369,0:44:21.329
cruise control ECU for use in a real car,[br]you could not just connect some random ECU
0:44:21.329,0:44:25.859
to the CAN bus and try it on the highway.[br]You will need to go through a lot of
0:44:25.859,0:44:32.009
analysis, such as HAZOP, HARA, FMEA, STPA[br]and so on. Usually there are so many
0:44:32.009,0:44:36.890
requirements that they cannot be tracked[br]with only a human and a sheet of paper.
0:44:36.890,0:44:46.250
They are managed using dedicated tools[br]such as Rational Doors. Now let's discuss
0:44:46.250,0:44:50.700
how the software would be different. The[br]main contribution of automotive software
0:44:50.700,0:44:55.410
is to realize control algorithms safely.[br]But without countermeasures, many things
0:44:55.410,0:45:01.119
could go wrong. For example there could be[br]bugs in the ECU application code. And then
0:45:01.119,0:45:04.589
without any bug the software will be[br]robust enough when there are transient
0:45:04.589,0:45:11.760
errors in the hardware. There could also[br]be problems with the toolchains that
0:45:11.760,0:45:24.210
compile the firmware and problems with the[br]libraries and RTOS. And when we have a
0:45:24.210,0:45:28.359
close look at the PID controller[br]implementation which seemed good enough in
0:45:28.359,0:45:32.740
our testing, you can see it is actually a[br]terrible implementation. We are mixing
0:45:32.740,0:45:37.680
integers and unsigned integers and floats[br]without proper checks and type casting. We
0:45:37.680,0:45:45.410
are not checking for overflows and also[br]random software issues. And this is not
0:45:45.410,0:45:48.670
acceptable, both for safety and security.[br]And in this case, the problems were
0:45:48.670,0:45:52.070
obvious on purpose, but sometimes it can[br]be very hard to spot because they stem
0:45:52.070,0:45:58.829
from very subtle computing issues. And[br]those issues may lead to system failures.
0:45:58.829,0:46:03.440
So to avoid such scenarios, the automotive[br]industry usually mandates the use of a
0:46:03.440,0:46:07.940
language subset which restricts what[br]developers can do, but makes sure that
0:46:07.940,0:46:15.849
numerical errors are less likely to[br]happen. So usually in the automotive
0:46:15.849,0:46:22.089
industry, the standard that is used is[br]MISRA-C and it is very similar to CERT-C,
0:46:22.089,0:46:30.600
which is popular in the security industry.[br]Using a language subset is only one of the
0:46:30.600,0:46:36.119
requirements that are dictated by ISO[br]26262. There are many other requirements.
0:46:36.119,0:46:40.930
At a high level they try to enforce a low[br]complexity of the software. For example,
0:46:40.930,0:46:45.810
by restricting the size of components,[br]restricting the copying between software
0:46:45.810,0:46:51.150
components and making sure the scheduling[br]is appropriate. And that there are not too
0:46:51.150,0:46:55.329
many interrupts. But we also have more[br]concrete requirements, such as restricting
0:46:55.329,0:46:59.410
functions to 1 entry and 1 exit point,[br]forbid dynamic memory, avoid global
0:46:59.410,0:47:07.670
variables, limit the use of pointers and[br]so on. The other issues we have to deal
0:47:07.670,0:47:11.830
with, which is riddled with bugs is[br]transient errors. In the harsh
0:47:11.830,0:47:16.380
environment, data is not always reliable.[br]There may be a bit flip occurring outside
0:47:16.380,0:47:22.890
of memory, for example, because of noise[br]and communication lines, but also may be
0:47:22.890,0:47:26.589
bit flips occurring inside a microcontrollers[br]memory. For example, because of cosmic
0:47:26.589,0:47:31.950
rays. Those issues do not originate from[br]software, they originate from hardware,
0:47:31.950,0:47:35.670
but they do need to be addressed by[br]software because remember, in the case of
0:47:35.670,0:47:41.309
the example cruise control ECU, just one[br]bit flip could lead to unwanted behavior of
0:47:41.309,0:47:47.400
the ECU and the car. So to address those[br]issues, automotive controllers need
0:47:47.400,0:47:52.003
special countermeasures. For example[br]having redundant memory or having
0:47:52.003,0:48:00.079
redundant CPUs. In ECUs, you will[br]typically find microcontrollers that have
0:48:00.079,0:48:04.290
been designed specially for automotive[br]use. All those microcontrollers require
0:48:04.290,0:48:09.241
you to sign an NDA so you can not just buy[br]them and start programming them. So that
0:48:09.241,0:48:15.920
makes it a bit hard to study an actual ECU[br]microcontroller and real automotive
0:48:15.920,0:48:23.119
software. ISO 26262 is not the only[br]standard for safety critical systems. ISO
0:48:23.119,0:48:29.920
26262 is actually derived from IEC 61508,[br]so they are both similar in their
0:48:29.920,0:48:35.750
concepts. And IEC61508 microcontrollers[br]they do not require NDAs for most other
0:48:35.750,0:48:42.339
activities you may be interested in. And[br]more completely RAMN can be used with
0:48:42.339,0:48:47.420
STM32L4 or STM32L5 microcontrollers. And[br]for those microcontrollers, you do not
0:48:47.420,0:48:52.650
need an NDA to download guidelines on how[br]to implement safe software. For example,
0:48:52.650,0:48:56.240
you can find a list of features that are[br]required for safety applications, and you
0:48:56.240,0:49:00.700
can request more data that you would need[br]to actually achieve compliance with
0:49:00.700,0:49:07.400
IEC 61508, such as the FMEA and FMEDA. But to[br]obtain those data, you would need to sign an
0:49:07.400,0:49:13.329
NDA. No, I personally do not think that[br]those data are essential for education and
0:49:13.329,0:49:19.670
research. So using such microcontrollers[br]is a good alternative. But again, let me
0:49:19.670,0:49:23.299
stress that this is an alternative for[br]learning and researching, not for actual
0:49:23.299,0:49:28.660
use in a car. I don't have time to detail[br]all the safety features, let me just talk
0:49:28.660,0:49:35.220
about memory redundancy, since this one[br]impacts the code of the application of the
0:49:35.220,0:49:42.150
example cruise control ECU. So in the[br]example, we wrote the gain of each stage
0:49:42.150,0:49:47.390
in code memory defining them as constants.[br]For safer applications, this would not be
0:49:47.390,0:49:53.289
here. They belong to another section, the[br]data flash where ECC protection can be
0:49:53.289,0:49:57.920
activated. If possible, calibration data[br]should be stored twice with checksums and
0:49:57.920,0:50:04.299
preferably MACs. If you're not familiar[br]with ECC memory, it is a kind of memory
0:50:04.299,0:50:09.349
that can detect bit flips and sometimes[br]automatically corrects them. Another
0:50:09.349,0:50:13.480
memory is also available for the RAM, [br]but not at all addresses. So in the
0:50:13.480,0:50:17.240
application, we have to ensure that safety[br]critical variables are placed in a section
0:50:17.240,0:50:24.520
of RAM in which bit flips can be detected,[br]in this case in section SRAM2. For data in
0:50:24.520,0:50:30.819
RAM that are actually constants such the[br]gains you may also want to activate write
0:50:30.819,0:50:36.579
protection, a feature that is only[br]available in SRAM2. Last slide about
0:50:36.579,0:50:44.200
software. In the example cruise control,[br]we are using GCC toolchain in ISO 26262 it
0:50:44.200,0:50:48.119
is a requirement to have what is called a[br]tool confidence lever to ensure that
0:50:48.119,0:50:53.190
poor chains will not introduce errors as it[br]could be the case with some optimizations.
0:50:53.190,0:50:57.750
So normally you cannot use GCC. Realtime[br]operating systems and libraries may also
0:50:57.750,0:51:03.099
have problems. That is why they need to be[br]certified. Both STM32-HAL and FreeRTOS are
0:51:03.099,0:51:10.799
compliant with MISRA-C which is nice, but[br]they are not compliant with ISO 26262.
0:51:10.799,0:51:16.410
However, it looks like ST is bringing[br]Azure RTOS into the ecosystem and that one
0:51:16.410,0:51:24.700
is actually precertified ISO 26262. Maybe[br]in the future it would be an option to
0:51:24.700,0:51:30.519
experiment with with an actual ISO 26262[br]operating system. So now let's talk a bit
0:51:30.519,0:51:33.539
about hardware. In case it was not clear[br]to you, you cannot use commercial
0:51:33.539,0:51:37.700
electronics to implement an ECU.[br]Smartphone vendors will often warn you not
0:51:37.700,0:51:42.499
to let a device in your car because a[br]parked car can reach extreme temperatures
0:51:42.499,0:51:47.480
that commercial electronics are not[br]designed to resist. And if you think that
0:51:47.480,0:51:52.270
the life inside the cabin is hard, you[br]should think about an ECU which has to
0:51:52.270,0:51:56.999
stay in the engine compartment and operate[br]without failures. And you would not think
0:51:56.999,0:52:03.560
of putting a smartphone or an Arduino here[br]and trust your life with it. And extreme
0:52:03.560,0:52:06.890
temperatures are just one of the many[br]environmental factors that make it
0:52:06.890,0:52:11.289
difficult for an ECU to stay reliable. The[br]ECU also need to resist high humidity,
0:52:11.289,0:52:17.859
corrosive gases, vibrations, micro cuts,[br]load dumps, electrostatic discharges,
0:52:17.859,0:52:27.029
electromagnetic noise and so on. And when[br]subjected to such a harsh environment,
0:52:27.029,0:52:30.430
many things could go wrong with[br]electronics. You probably know about
0:52:30.430,0:52:35.089
corrosion, but many other physical[br]phenomena are at risk of happening to the
0:52:35.089,0:52:39.079
components. Solder cracs, intermetallic[br]growth, whiskers, dendrites,
0:52:39.079,0:52:44.670
electromigration, etc. For example,[br]whiskers are metal growing out of
0:52:44.670,0:52:48.349
electrical components and dendrites are[br]metals leaving the plus side towards the
0:52:48.349,0:52:53.560
minus side. And many other phenomena may[br]result in a dangerous failure. So
0:52:53.560,0:52:58.059
obviously, ECUs need to be designed to[br]resist harsh environments and have
0:52:58.059,0:53:01.779
countermeasures against all those[br]potential failures. ECUs need to pass
0:53:01.779,0:53:06.190
various tests that simulate harsh[br]environments. Those tests are usually
0:53:06.190,0:53:11.099
defined by manufacturers and the test[br]specifications are not made public. What
0:53:11.099,0:53:14.779
is made public, however, is the test[br]specifications for individual electronic
0:53:14.779,0:53:20.200
components. And those tests are usually[br]defined by AEC. So the Automotive
0:53:20.200,0:53:28.119
Electronic Council, and you can have a[br]look at them online. For RAMN, we tried to
0:53:28.119,0:53:32.049
follow design guidelines similar to those[br]of real ECUs. But of course, we cannot
0:53:32.049,0:53:37.619
follow actual rules as it to be much less[br]accessible. Completely, we selected
0:53:37.619,0:53:41.569
AEC-Q100 grade zero components for[br]everything except connectors and
0:53:41.569,0:53:46.339
microcontrollers, because those may[br]require NDAs or not be easily accessible.
0:53:46.339,0:53:51.270
Depending on the part reference, ECU[br]microcontrollers may be usable from -40 to
0:53:51.270,0:53:56.259
125°C. RAMN tried to stay close to[br]automotive grade, but it is still not
0:53:56.259,0:53:59.859
automotive grade, especially in the[br]reliability department, so it can not be
0:53:59.859,0:54:06.290
used as a real ECU. As a result, we try to[br]stay close to automotive hardware is to
0:54:06.290,0:54:10.460
help researchers evaluate the impact of[br]manufacturing tolerances and environments
0:54:10.460,0:54:16.880
because remember, manufacturers are making[br]millions of cars that need to operate on a
0:54:16.880,0:54:20.609
large temperature range. So if you are[br]developing, for example, a security
0:54:20.609,0:54:25.089
technology that relies on hardware[br]characteristics such as the clocks of the
0:54:25.089,0:54:29.869
ECUs, you will need to prove that the[br]technology works despite manufacturing
0:54:29.869,0:54:35.329
tolerances and harsh environments. And[br]with RAMN it is easy to have a large
0:54:35.329,0:54:40.499
sample of ECU networks and since they are[br]small they can easily fit in various
0:54:40.499,0:54:46.808
testing equipment. And now let's move on[br]to the last section, security. In the
0:54:46.808,0:54:51.700
automotive industry, we just can not apply[br]the same reasoning as you do in many other
0:54:51.700,0:54:56.599
industries. For example, a credit card, if[br]you detect the temperature is too cold, it
0:54:56.599,0:55:01.140
may think that it is a tampering attack[br]and decides to shut down because it is not
0:55:01.140,0:55:05.720
safety critical. On the other hand, the[br]car needs to start quickly because the
0:55:05.720,0:55:12.210
user should not be left out in the cold[br]and also credit cards have an expiration
0:55:12.210,0:55:16.569
date. So they do not need to guarantee[br]security for more than a few years. But
0:55:16.569,0:55:21.549
cars do not have an expiration date. If[br]they are well maintained they may be used
0:55:21.549,0:55:26.970
for several decades and the security[br]technologies should keep on working. So in
0:55:26.970,0:55:30.530
the end, automotive security technologies[br]have different requirements.
0:55:30.530,0:55:34.759
Unfortunately, according to past research,[br]a security technology is often less
0:55:34.759,0:55:39.339
reliable when you extend its operating[br]temperature range and its lifetime. For
0:55:39.339,0:55:45.060
example, at low temperatures, they may be[br]liable to cold boot attacks. At high
0:55:45.060,0:55:50.249
temperatures, it has also been shown that[br]electronics tend to be less reliable
0:55:50.249,0:55:53.820
concerning glitching attacks and in those[br]papers high-temperature means something
0:55:53.820,0:56:01.039
like 60 or 100°C, far from the maximum[br]temperature required for some ECUs. Also,
0:56:01.039,0:56:06.359
it has been shown that the higher age for[br]electronics usually results in different
0:56:06.359,0:56:13.150
security properties. And you may think[br]that the safety features of automotive
0:56:13.150,0:56:17.249
microcontrollers would prevent some[br]attacks such as glitching attacks, but it
0:56:17.249,0:56:22.119
has been shown that ECC memories are also[br]susceptible to glitching attacks. And that
0:56:22.119,0:56:27.550
even ISO 26262 ASIL-D microcontrollers,[br]which is the highest level of safety may
0:56:27.550,0:56:32.039
be susceptible to glitching. So safety[br]features often help, but there aren't
0:56:32.039,0:56:38.839
really enough to ensure security. What is[br]also different with automotive is that you
0:56:38.839,0:56:42.940
need to rethink the strategy in case of[br]security problems, for example, with
0:56:42.940,0:56:48.000
credit cards, it is not uncommon for[br]authentication to fail randomly. When the
0:56:48.000,0:56:54.059
credit card fails to work usually you just[br]need to try it once more and it will
0:56:54.059,0:56:59.589
probably work and everything stays again.[br]No life is at risk. But the car cannot
0:56:59.589,0:57:06.579
have the same strategy. If you add[br]authentication to the brake CAN message
0:57:06.579,0:57:10.740
and you start receiving break request that[br]fail authentication what should the car
0:57:10.740,0:57:18.210
really do. Because it may be a cyber[br]attacks, which you want to avoid, but you
0:57:18.210,0:57:22.799
should not relay out the possibility of a[br]random malfunction or a false positive for
0:57:22.799,0:57:27.289
an intrusion detection system. And by[br]adding complexity into the system, you
0:57:27.289,0:57:33.039
always increase the odds of a problem. And[br]which one would be worse between breaking
0:57:33.039,0:57:40.059
because of a cyber attack or not breaking[br]because of a malfunction? And there is no
0:57:40.059,0:57:43.509
easy way to answer that question. But what[br]I want to stress here is that many
0:57:43.509,0:57:47.450
security countermeasures that people[br]suggest for cars such as encrypting the
0:57:47.450,0:57:51.799
CAN bus, permanently disabling debug ports[br]or obfuscating the firmware, they may not
0:57:51.799,0:57:58.240
necessarily be the best ideas, because if[br]you suspect a malfunction with an ECU, you
0:57:58.240,0:58:02.839
need to investigate the problem seriously[br]because it may harm people. You cannot
0:58:02.839,0:58:09.599
just replace a car as you would with a[br]credit card or a smartphone.
0:58:09.599,0:58:13.779
So technologies that can truly take into[br]account both automotive requirements and
0:58:13.779,0:58:17.390
security requirements are better. And we[br]should make sure that education and
0:58:17.390,0:58:22.369
research in these areas are accessible to[br]many researchers without NDAs or
0:58:22.369,0:58:28.740
prohibitive costs. Now, of course, you can[br]use RAMN to try out different attacks. The
0:58:28.740,0:58:32.859
first obvious one is to inject CAN[br]messages to alter the behavior of the car.
0:58:32.859,0:58:55.759
Here for example the breaks. Another kind[br]of security that I did not mention in this
0:58:55.759,0:58:59.529
presentation is physical security for[br]sensors and actuators. Here I am
0:58:59.529,0:59:02.839
demonstrating what happens when it[br]overtake the control of the steering wheel
0:59:02.839,0:59:08.789
actuator. A human will probably break in[br]this situation. The self driving algorithm
0:59:08.789,0:59:13.109
in CARLA here does not realize it has lost[br]control of the steering wheel and is still
0:59:13.109,0:59:20.349
trying to correct the trajectory when a[br]better decision would be to stop the car.
0:59:20.349,0:59:25.299
So this is the end of the presentation. We[br]developed an inexpensive, safe and
0:59:25.299,0:59:30.249
interactive platform to study and research[br]automotive systems. The platform is
0:59:30.249,0:59:34.650
accessible to beginners. It is not[br]automotive grade, but is close enough for
0:59:34.650,0:59:39.329
research and educational purposes. The[br]project is open source and with permissive
0:59:39.329,0:59:44.436
licenses. If you have questions or ideas,[br]do not hesitate to contact us, especially
0:59:44.436,0:59:49.340
if you are involved with education,[br]research, training, CTF, etc. And thank
0:59:49.340,0:59:57.890
you for watching.
0:59:57.890,1:00:02.647
Herald: Camille, thanks for this[br]comprehensive talk, this was amazing. We
1:00:02.647,1:00:05.837
unfortunately don't have much time for[br]the questions or answers, but there is
1:00:05.837,1:00:11.780
one question that popped up, which is[br]about the hardware and your PCB. How did
1:00:11.780,1:00:15.860
you design it? How much does it cost[br]actually, how can you get hold of that
1:00:15.860,1:00:19.854
thing?[br]Camille: So I designed everything with
1:00:19.854,1:00:25.362
KiCAD. And I mean, I think a few years ago[br]it was very hard to design hardware, but
1:00:25.362,1:00:31.859
now you have footprint libraries available[br]online. It has become very easy. The board
1:00:31.859,1:00:37.341
was between 50 to 100€ for a quantity of[br]one. So microcontrollers are obviously the
1:00:37.341,1:00:42.880
expensive parts and the PCB assembling[br]parts - it is up to the PCB Fabrication
1:00:42.880,1:00:49.750
Service. If you have questions just ask me[br]on GitHub, I would be happy to answer.
1:00:49.750,1:00:59.205
rC3 postroll music
1:00:59.205,1:01:29.000
Subtitles created by c3subtitles.de[br]in the year 2021. Join, and help us!