< Return to Video

#rC3 - RAMN: Resistant Automotive Miniature Network

  • 0:00 - 0:15
    preroll music
  • 0:15 - 0:19
    Camille Gay: Hello, everyone. My name is Camille. I am
    a researcher at Toyota Motor Corporation,
  • 0:19 - 0:22
    and this is a presentation about RAMN, a
    platform that we developed to make
  • 0:22 - 0:28
    education and research in the automotive
    systems more accessible. The automotive
  • 0:28 - 0:32
    industry can be inaccessible to many
    people because automotive projects involve
  • 0:32 - 0:38
    prohibitive costs and be tied to NDAs that
    everybody is going to sign. What we want
  • 0:38 - 0:42
    to propose with this project is an
    inexpensive test bed to study and research
  • 0:42 - 0:46
    automotive systems, which is both open
    source and developed with open source
  • 0:46 - 0:50
    tools so that at least anyone can get
    access to a good alternative for education
  • 0:50 - 0:55
    and research. The main focus of this test
    bed is security, but you will see that the
  • 0:55 - 1:00
    usage of the test bed is not limited to
    security, and I will keep the security
  • 1:00 - 1:06
    talk mostly for the end of the
    presentation. I will start by giving a
  • 1:06 - 1:11
    short introduction about automotive
    systems. Then I will present the design
  • 1:11 - 1:15
    details of the test bed besides
    demonstrations and concrete details about
  • 1:15 - 1:21
    its hardware and software. As an example
    of how the test bed can be used, I will
  • 1:21 - 1:25
    spend some time experimenting with cruise
    control and by that I mean I will go
  • 1:25 - 1:29
    through the whole development process,
    starting from evaluating the differential
  • 1:29 - 1:34
    equations of a simple mechanical model. I
    will experiment with various control
  • 1:34 - 1:39
    strategies, implement them in C and make
    measurements in a driving simulator using
  • 1:39 - 1:46
    only data from the CAN bus. And I will do
    all that using only open source tools.
  • 1:46 - 1:49
    This is to demonstrate how the test bed
    can be used, but also to have a concrete
  • 1:49 - 1:54
    project that I can use as a reference to
    explain after what concretely would have
  • 1:54 - 1:58
    been different if we were experimenting
    with a real electronic control unit. I
  • 1:58 - 2:03
    will also explain how we can get close to
    automotive hardware and software without
  • 2:03 - 2:07
    signing NDAs. So the second part of the
    talk is mainly here to give you more
  • 2:07 - 2:11
    information about the automotive industry
    in case you are not familiar with it.
  • 2:11 - 2:16
    Before I start, let me just clarify that
    this is not an advertisement. We are not
  • 2:16 - 2:20
    selling anything we present here and do
    not profit financially from it. We're
  • 2:20 - 2:24
    simply showing design files whithout
    permising licenses and without
  • 2:24 - 2:30
    royalties. OK, so first, let me give you a
    very quick introduction about automotive
  • 2:30 - 2:35
    systems. You can see your car as a
    collection of systems divided in four
  • 2:35 - 2:38
    different domains, the powertrain domain,
    which includes the engine and the
  • 2:38 - 2:42
    transmission. The chassis domain, which
    includes the steering column and
  • 2:42 - 2:46
    suspensions. The body domain, which
    includes the lights, the doors and
  • 2:46 - 2:50
    heating, and the infotainment domain,
    which includes navigation and
  • 2:50 - 2:57
    connectivity. Many of the different
    systems that can be found in the car are
  • 2:57 - 3:02
    controlled by electronic control units or
    ECUs for short. There are many kinds of
  • 3:02 - 3:06
    ECUs in the car. Sometimes hundreds of
    them. And usually it's a lot hard to
  • 3:06 - 3:10
    understand. They have a limited number of
    inputs, generally data from sensors and
  • 3:10 - 3:16
    actuators. And they have a limited number
    of outputs generally to control actuators.
  • 3:16 - 3:21
    So, for example, an airbag ECU may use an
    accelerometer as its input and an airbag
  • 3:21 - 3:25
    trigger as its output. The role of the ECU
    would be to use data from the
  • 3:25 - 3:32
    accelerometer to detect a shock and output
    a signal as actuator to detonate an airbag
  • 3:32 - 3:39
    when the shock is detected. It is very
    common for ECUs to read data from other
  • 3:39 - 3:44
    ECUs. Most of the time ECUs will need to
    share data with other ECUs on the same
  • 3:44 - 3:49
    domain. In the case of [unclear],
    for example the transmission control unit
  • 3:49 - 3:54
    gets input from the engine ECU to
    determine the correct gear. If the data is
  • 3:54 - 3:59
    critical that connection may even be
    redundant. ECUs may also need to
  • 3:59 - 4:03
    communicate with ECUs on a different
    domain. For example the brake system,
  • 4:03 - 4:07
    usually in the chassis domain, willl need to
    communicate its data to store them, usually
  • 4:07 - 4:11
    in the body domain. Most of the time the
    technology that is used for communication
  • 4:11 - 4:17
    is CAN. And CAN technology uses a bus
    topology, which means a CAN message will
  • 4:17 - 4:21
    be received by all ECUs on the same CAN
    bus, there is no authentication or
  • 4:21 - 4:26
    encryption at the link layer. So any
    message can be sent by any ECU. And
  • 4:26 - 4:32
    security features need to be implemented
    at higher layers. A standard CAN frame
  • 4:32 - 4:38
    consist mainly of an arbitration ID of 11
    bits and a payload of 8 bytes. CAN-FD is a
  • 4:38 - 4:47
    recent evolution of CAN where the payload
    size may be extended up to 64 bytes. For
  • 4:47 - 4:51
    an ECU network manufacturers will assign a
    meaning to each arbitration ID and each
  • 4:51 - 4:55
    bit in the payload, so the file that
    determines the traffic on the CAN bus is
  • 4:55 - 5:01
    often referred to as a DBC file. For
    example, assuming a lamp controller and
  • 5:01 - 5:07
    two lamps on the CAN bus. The manufacturer
    may decide that ID 123 is used by the lamp
  • 5:07 - 5:12
    controller to communicate the command of
    both lamps, that ID 124 is used by the
  • 5:12 - 5:18
    left lamp to give feedback about the
    status and that ID 125 is used by the
  • 5:18 - 5:23
    right lamp to give feedback about its
    status. Each of those messages will be
  • 5:23 - 5:28
    broadcasted periodically by the assigned
    ECU on the CAN bus and will serve as a
  • 5:28 - 5:36
    basis for most data exchange between ECUs.
    So that's it for the introduction, there
  • 5:36 - 5:40
    are many reasons why people would be
    interested in automotive systems and ECU
  • 5:40 - 5:44
    networks. The opportunity that gets by far
    most attention from the media is
  • 5:44 - 5:50
    vulnerability research. But there are also
    other reasons. For example, owners: They
  • 5:50 - 5:54
    want to check their car's compliance with
    regulations such as emissions regulations
  • 5:54 - 6:01
    and privacy regulations. For example,
    GDPR. Other owners may want to exercise
  • 6:01 - 6:05
    their rights to repair as they are
    guaranteed by the country they live in.
  • 6:05 - 6:09
    And finally, some owners may want to
    experiment and innovative DIY features or
  • 6:09 - 6:15
    simply satisfy their curiosity and educate
    others. And while those may be valid
  • 6:15 - 6:19
    reasons to experiment with the car,
    manufacturers are typically against people
  • 6:19 - 6:22
    tinkering with a car because they may be
    worried about their intellectual property
  • 6:22 - 6:27
    being stolen, about vulnerabilities being
    exploited or people hurting themselves and
  • 6:27 - 6:33
    others while tinkering. And what probably
    suffers the most from this delicate
  • 6:33 - 6:37
    situation is education and research in
    automotive security, because people can
  • 6:37 - 6:42
    not easily get access to safe equipment or
    access the information that they would
  • 6:42 - 6:47
    need. In the long term, this may mean that
    manufacturers will have less security
  • 6:47 - 6:50
    technologies to choose from to secure
    their cars and that less talents would be
  • 6:50 - 6:55
    available to develop and evaluate them. As
    the development, of course, involves many
  • 6:55 - 6:59
    people from many companies, so it is
    important to make sure that everyone
  • 6:59 - 7:06
    involved is competent in automotive
    security. And some people are pushing for
  • 7:06 - 7:11
    more open sourcing cars and who knows,
    maybe one day the car will be 100%
  • 7:11 - 7:17
    open source, but if it happens, it is
    going to take a long time. And
  • 7:17 - 7:20
    manufacturers themselves do not have
    access to a hundred percent of the source
  • 7:20 - 7:25
    code of the cars they make because ECUs
    contain intellectual property from other
  • 7:25 - 7:30
    companies. So this is mostly a political
    topic. So there is not much we can
  • 7:30 - 7:35
    contribute to as researchers. However what
    we can contribute technically right now is
  • 7:35 - 7:39
    to try the other way around and use what
    is publicly available to make it
  • 7:39 - 7:47
    accessible, to learn and research
    automotive systems. And this is what we
  • 7:47 - 7:52
    try to do with RAMN, which is the topic of
    this presentation. The objective is to
  • 7:52 - 7:56
    provide a platform for research that is:
    Open, and by that we mean it should be
  • 7:56 - 8:01
    easy to modify the source code, and
    reprogram the ECUs; Accessible, and by
  • 8:01 - 8:06
    that we mean inexpensive, small and
    requiring no prior skills in automotive
  • 8:06 - 8:12
    systems; Safe - with no risk of accidents or
    legal repercussions; and motivating,
  • 8:12 - 8:15
    something that you can interact with so
    that you get the same kind of experience
  • 8:15 - 8:20
    as you do when you experiment with a real
    car. So already some solutions are
  • 8:20 - 8:24
    available if you want to experiment with
    an ECU network. Besides, of course, a real
  • 8:24 - 8:29
    car, the first one is making your own test
    bed from real ECUs so we can see many
  • 8:29 - 8:33
    hackers sharing the test bed at security
    conferences. And usually if you see
  • 8:33 - 8:37
    something like this, you stop and you
    immediately get interested. So it is a
  • 8:37 - 8:42
    nice way to motivate people to learn.
    Unfortunately, those are not easy to
  • 8:42 - 8:45
    reprogram because manufacturers do not
    share information about the ECUs and they
  • 8:45 - 8:53
    require a lot of skills to build. So it's
    not accessible to everyone. Another option
  • 8:53 - 8:58
    is to use development boards such as
    Arduino, and that is what you can see
  • 8:58 - 9:02
    mostly on academic papers. They have the
    advantage of being reproducible and you
  • 9:02 - 9:07
    can modify the source code as you want. So
    they can be used in many cases for
  • 9:07 - 9:12
    research. But they lack many safety
    features offered on an actual ECU hardware
  • 9:12 - 9:19
    and software. Even if you are able to
    simulate a CAN bus, you don't get the same
  • 9:19 - 9:24
    level of interaction as you do with a real
    car. So it's not something that motivates
  • 9:24 - 9:31
    people and makes them want to learn more.
    And the third option is to use a
  • 9:31 - 9:35
    professional test bed such as Pasta -
    another work from our team. This is a good
  • 9:35 - 9:39
    option because you get access to the
    source code and you can reprogram the ECUs
  • 9:39 - 9:43
    and the CAN bus network is already
    simulating a full car. So the groundwork
  • 9:43 - 9:47
    is already done. So major drawback are
    that it is very expensive. So it is not
  • 9:47 - 9:52
    accessible to everyone. So there are some
    options to study and research automotive
  • 9:52 - 9:57
    systems, but none of them seem to be both
    accessible and motivating at the same
  • 9:57 - 10:01
    time. So many people don't even think of
    running automotive systems because it
  • 10:01 - 10:05
    never occurred to them that they could
    like it. And in comparison with other
  • 10:05 - 10:09
    industries, you have so many ways to get
    started, if you want to learn about Linux,
  • 10:09 - 10:12
    you can start with a Raspberry Pi. If you
    want to learn about electronics you can
  • 10:12 - 10:17
    start with an Arduino and so on. So we
    wanted something that would give a similar
  • 10:17 - 10:27
    experience, but for automotive systems. So
    we noticed that most of the test beds that
  • 10:27 - 10:32
    people are using to experiment with ECUs
    are made of 4 ECUs. So the ECUs are often
  • 10:32 - 10:39
    communicating with each other using a CAN
    bus. So we tried to fit all that in a PCB
  • 10:39 - 10:44
    the size of a credit card. And we named
    that PCB RAMN. It features four ECUs
  • 10:44 - 10:50
    connected over a common CAN bus or CAN-FD
    bus, which is accessible from outside by a
  • 10:50 - 10:58
    terminal block. One of the ECUs is also
    connected to USB, which is also the power
  • 10:58 - 11:02
    supply. PIN-sockets can be used to
    connect sensors, actuators and additional
  • 11:02 - 11:07
    hardware and the board features many
    probes to easily access important electric
  • 11:07 - 11:17
    signals. The 4 ECUs simulate a CAN network
    with messages identical to Pasta. The name
  • 11:17 - 11:21
    RAMN is obviously a reference to Pasta as
    this is a cheap alternative, mostly aimed
  • 11:21 - 11:27
    at students. In real cars CAN messages
    typically have different payload sizes,
  • 11:27 - 11:31
    but by default we operate with maximum
    payload size, to demonstrate heavy
  • 11:31 - 11:36
    traffic, so the basic format is like this:
    Arbitration ID, 2 bytes for the data,
  • 11:36 - 11:40
    2 bytes for a counter and 4 bytes of
    additional data, random data used as a
  • 11:40 - 11:47
    placeholder for additional data such as
    checksum or MAC. You can easily modify the
  • 11:47 - 11:51
    CAN bus's arbitration ID end format. And
    here we are assuming a full by-wire
  • 11:51 - 11:56
    vehicle, which means all physical
    functions of a car are accessible to the
  • 11:56 - 12:02
    CAN bus, which is usually not the case on
    current cars. The block diagram of RAMN
  • 12:02 - 12:06
    looks like this. And as I explained
    earlier, all ECUs are periodically
  • 12:06 - 12:11
    exchanging messages on the CAN bus. If you
    connect a CAN adapter and have a look at
  • 12:11 - 12:23
    the traffic, it will typically look like
    this. So the board itself is enough to
  • 12:23 - 12:27
    simulate an ECU network, but it does not
    look very motivating. What we wanted on
  • 12:27 - 12:34
    top of this was some sensors and actuators
    to make it more interactive. So we created
  • 12:34 - 12:38
    4 expansion boards for sensors and
    actuators. To simulate the infotainment
  • 12:38 - 12:43
    domain, we simply use a screen. For the
    body domain, we use an engine key and some
  • 12:43 - 12:52
    LEDs. For the chassis domain we mainly use
    a slide switch to simulate a side brake
  • 12:52 - 12:57
    and a rotating potentiometer to simulate
    the steering wheel. And for the power
  • 12:57 - 13:01
    train domain we use slide potentiometers
    for the brake and accelerator and a
  • 13:01 - 13:09
    joystick for the shift lever. The EC
    connected to USB implements a standard CAN
  • 13:09 - 13:14
    or CAN-FD interface, either of a standard
    serial port using Slcan or over a native
  • 13:14 - 13:18
    interface on Linux thanks to the
    counterlight firmware projects. If you
  • 13:18 - 13:22
    connect the board to a USB port on the
    computer, it should be recognized as a USB
  • 13:22 - 13:26
    to CAN adapter. So it is not necessary to
    own an external CAN adapter to get
  • 13:26 - 13:33
    started. This is a demo of what it looks
    like to use RAMN. Just connect it over
  • 13:33 - 13:39
    USB, if you use Linux, you can get it to be
    recognized as a standard CAN network
  • 13:39 - 13:45
    interface. So it will show up in ifconfig.
    Then you can use various tools available
  • 13:45 - 13:48
    on Linux to observe the traffic, for
    example CAN sniffer. Here you can see the
  • 13:48 - 13:59
    traffic explained earlier, the CAN IDs on
    the left and the payload on the right. So
  • 13:59 - 14:03
    with this, we can simulate a ECU network
    with sensors and actuators, which is
  • 14:03 - 14:07
    enough for basic interactions. But it
    still doesn't feel like you are actually
  • 14:07 - 14:12
    experimenting with a car. Ideally the ECUs
    should be performing realistic ECU
  • 14:12 - 14:17
    functions, not just lighting up LEDs based
    on some switches and potentiometers. And
  • 14:17 - 14:20
    for this we thought of a connection in a
    closed loop with an open source driving
  • 14:20 - 14:28
    simulator which is an affordable and safe solution.
    To feel like you are driving the ECU network.
  • 14:28 - 14:33
    Fortunately, there is a great open source
    driving simulator for autonomous driving
  • 14:33 - 14:37
    research. It is called CARLA. It features
    a Python API. So it is very easy to
  • 14:37 - 14:42
    interact with it and it also comes with an
    example self-driving algorithm. So you can
  • 14:42 - 14:49
    immediately start experimenting with your
    virtual self-driving car. So we wrote some
  • 14:49 - 14:54
    scripts so that most sensors values for
    example speed and altitude would be
  • 14:54 - 14:59
    simulated on the computer running CARLA.
    Then broadcasted on the CAN bus. On the
  • 14:59 - 15:03
    other side we made it so that all controls
    of CARLA such as throttle, steering and
  • 15:03 - 15:08
    brakes will be decided by the ECU network.
    And this is what you could refer to as
  • 15:08 - 15:12
    HILs or Hardware-In-The-Loop simulation in
    the automotive industry, RAMN is not as
  • 15:12 - 15:30
    advanced as professional tools, but at
    least it is accessible. So to achieve
  • 15:30 - 15:34
    manual control, it is not complicated with
    CARLA. On the manual control example
  • 15:34 - 15:38
    provided with the API there is a while
    true game loop that with events of the
  • 15:38 - 15:45
    keyboard, applies controls, then updates
    the physics simulation. So CARLA does not
  • 15:45 - 15:49
    simulate the CAN bus by default so we
    created a Python class to easily interact
  • 15:49 - 15:53
    with the CAN bus using the CAN message
    specifications of RAMN. To integrate it
  • 15:53 - 15:57
    with CARLA we just need to replace
    keyboard controls with actuator control
  • 15:57 - 16:02
    data read from the CAN bus. To close the
    loop we broadcast sensor data using CAN
  • 16:02 - 16:08
    messages based on data retrieved from the
    Python API of the physics simulator. And
  • 16:08 - 16:15
    with this we are able to control the car
    manually, the potentiometers on the board.
  • 16:15 - 16:19
    Here I gently press accelerator, release
    the handbrake, and I can control the car
  • 16:19 - 16:40
    using the steering wheel
    on the expansion board.
  • 16:40 - 17:04
    Video stops
  • 17:04 - 17:05
    So manual control is nice, but
  • 17:05 - 17:10
    automatic control is better because
    ultimately we want to focus on working on
  • 17:10 - 17:14
    the CAN bus. So on the original CARLA
    project, there was also an example script
  • 17:14 - 17:19
    for automatic control. Again there is a
    while true loop where the code basically
  • 17:19 - 17:23
    simulates the physics, lets the self-
    driving AI make a decision, then applies
  • 17:23 - 17:31
    the controls to the physics simulation. To
    integrate RAMN in this certain algorithm,
  • 17:31 - 17:34
    again, we need to replace the apply
    control part with the controls from the
  • 17:34 - 17:39
    ECU network. We also need to send CAN
    messages with sensor data retrieved from
  • 17:39 - 17:44
    the Python API of the physics simulation.
    That is identical to having manual
  • 17:44 - 17:50
    control. What we need to do more is also
    send a message to broadcast the status of
  • 17:50 - 17:57
    the AI to the ECU Network, so that the ECU
    network knows what controls the AI
  • 17:57 - 18:06
    algorithm is requesting. So periodically
    the AI would broadcast its status by
  • 18:06 - 18:10
    sending messages over USB, which are
    converted into CAN messages by the ECU
  • 18:10 - 18:16
    input to USB. All ECUs on the network will
    receive those messages and will decide the
  • 18:16 - 18:22
    actual controls of the car based on their
    own algorithm. For example, the power
  • 18:22 - 18:27
    train ECU may decide to apply brakes
    depending on the highest value between the
  • 18:27 - 18:33
    AI brakes and the brake potentiometer. All
    ECUs will receive the CAN message and
  • 18:33 - 18:39
    apply the control, some ECUs may filter
    that message if they do not need it. Some
  • 18:39 - 18:44
    ECUs like the body ECU may process it and
    take action. For example, if the brakes
  • 18:44 - 18:50
    are engaged, the body ECU will light up
    the stop lamp on the expansion board.
  • 18:50 - 18:55
    Finally, the ECU connected to USB will
    forward the brake controls to the
  • 18:55 - 19:02
    simulator that will apply the brakes in
    the physics simulation. So this is what it
  • 19:02 - 19:07
    actually looks like, all I need to do
    again is release the handbrake and the car
  • 19:07 - 19:13
    will drive itself. The car is controlled
    by the ECU network, so when the car stops
  • 19:13 - 19:16
    in the simulation, it is because the
    controls were applied by the power train
  • 19:16 - 19:21
    ECU. You can see that the stop lamp lights
    up because the body ECU also received and
  • 19:21 - 19:31
    processed the break CAN message. Since the
    ECU is in charge of the controls, I can
  • 19:31 - 19:45
    force the car to stop any time by forcing
    brakes on the power train ECU potentiometer.
  • 19:45 - 19:48
    So if you connect an external
    CAN adapter to the CAN bus,
  • 19:48 - 19:53
    you'll be able to send and receive
    messages. So using RAMN you can experiment
  • 19:53 - 20:03
    with the CAN bus of the self-driving
    virtual car. When you want to reprogram an
  • 20:03 - 20:07
    ECU in the real world, you have two
    options. Either you interact with the
  • 20:07 - 20:11
    hardware bootloader of the ECUs
    microcontroller, which depends on the
  • 20:11 - 20:14
    microcontrollers model and manufacturer,
    or you interact with diagnostics and
  • 20:14 - 20:19
    calibration software, which depends on the
    car model and manufacturer. Diagnostic and
  • 20:19 - 20:24
    calibration are often done on the CAN bus,
    but other options may be available.
  • 20:24 - 20:30
    Protocols are defined by standard
    documents. You often hear about UDS and
  • 20:30 - 20:35
    OBD-II which both rely on the same
    transport layer ISO-TP. But there are also
  • 20:35 - 20:43
    other protocols, such as Keyword Protocol
    2000 or XCP. All those protocols can often
  • 20:43 - 20:50
    also be implemented over other layers. For
    the hardware bootloaders it depends on the
  • 20:50 - 20:54
    microcontroller manufacturer. For example
    for an STM 32 microcontroller you can
  • 20:54 - 20:59
    reprogram the firmware by interacting over
    CAN according to the application note
  • 20:59 - 21:05
    3154, over USB according to the
    application note 3156. Or using other
  • 21:05 - 21:12
    protocols defined in other application
    notes. In the case of RAMN, we use the
  • 21:12 - 21:16
    hardware bootloader to reprogram the ECUs
    and you can also use a UDS protocol over
  • 21:16 - 21:24
    CAN. And in the future we may consider
    adding XCP and KWD 2000. How to reprogram
  • 21:24 - 21:28
    an ECU using calibration and diagnostic
    software is a topic that is already
  • 21:28 - 21:33
    heavily discussed at automotive security
    talks, I will not spend time on this
  • 21:33 - 21:38
    topic. You can find the definition of the
    standards online. Usually you need to pay
  • 21:38 - 21:44
    for them. But you can also find summaries
    for free on some websites. For example,
  • 21:44 - 21:52
    Wikipedia. What is more interesting to
    discuss here is the hardware bootloader.
  • 21:52 - 21:55
    The various ways to force a microcontroller
    into bootloader mode are
  • 21:55 - 22:02
    described in the application note 2606.
    The format of CAN messages we need to send
  • 22:02 - 22:07
    to interact with the bootloader is defined
    in the application note 3154. And it's not
  • 22:07 - 22:12
    complicated. The format is simply common
    byte plus argument. All that within the
  • 22:12 - 22:19
    same CAN message payload. So we wrote some
    script to make it easier to interact with
  • 22:19 - 22:28
    the bootloader. So here I am showing the
    script that we use to interact with the
  • 22:28 - 22:32
    bootloader. First thing I do is retrieve
    all information from the bootloader,
  • 22:32 - 22:38
    including the version, the supported
    commands and the Chip ID. I then use a
  • 22:38 - 22:44
    read memory command to dump all known
    sections of memories. This includes the
  • 22:44 - 22:49
    ECU firmware. So it can be a good start to
    start experimenting with reverse
  • 22:49 - 23:04
    engineering. We can also activate memory
    without protection and see what happens
  • 23:04 - 23:19
    when you try to dump the memory again. And
    in this case is not allowing memory dumps
  • 23:19 - 23:22
    anymore. You can remove the memory
    protection, which will wipe out the
  • 23:22 - 23:47
    memory, and after you do that, you can use
    the bootloader to reprogram the ECUs. For
  • 23:47 - 23:51
    the hardware we also designed additional
    expansion boards with various features.
  • 23:51 - 23:56
    First one is an expansion to connect a
    JTAG debugger. Second one is about to add
  • 23:56 - 24:02
    extra QuadSPI Memories, which is why you
    see packages such as EEPROM, FRAM, NAND,
  • 24:02 - 24:10
    SRAM and so on. The third one is a board
    to add a trusted platform module. And the
  • 24:10 - 24:23
    last one is an interface to easily connect
    a chip whisperer. All those expansions are
  • 24:23 - 24:27
    compatible with each other, so you can
    stack them and create a very advanced ECU
  • 24:27 - 24:34
    network with all ECUs between a TPM and
    one gigabit of memory. And it looks better
  • 24:34 - 24:41
    when the expansions are stacked on top of
    each other. Since we would like to use
  • 24:41 - 24:45
    RAMN for education, we try to vary the
    type of electrical signals using the
  • 24:45 - 25:05
    expansions. And we added many external
    probes to easily connect external tools. You
  • 25:05 - 25:09
    can use one of the many excellent probes
    to connect an oscilloscope and have a look
  • 25:09 - 25:18
    at analog signals. For example, here's the
    brake potentiometer. Or connect a logic
  • 25:18 - 25:24
    analyzer and have a look at digital
    signals, for example, to analyze SPI
  • 25:24 - 25:34
    communication between the ECU and the
    screen. For the hardware design we kept it
  • 25:34 - 25:39
    simple using only two layers and keeping
    all components on the same side. We
  • 25:39 - 25:42
    designed the hardware with flash
    tolerances which should be easy to produce
  • 25:42 - 25:48
    with most PCB fabrication services. We use
    components with large size. So if you have
  • 25:48 - 26:00
    some skills in soldering, you should be
    able to solder one yourself. We designed
  • 26:00 - 26:05
    the hardware using KiCAD, which is an open
    source tool for designing hardware. You
  • 26:05 - 26:13
    can easily modify the schematics, layout
    and even generate nice 3D views. So
  • 26:13 - 26:19
    firmware is designed using STM32CubeIDE,
    it is accessible to beginners, and you can
  • 26:19 - 26:23
    easily reconfigure peripherals and clocks
    from the graphical interface. You will
  • 26:23 - 26:28
    even get some statistics, such as the
    estimated power consumption. But of
  • 26:28 - 26:32
    course, you do not need to use the
    graphical interface and libraries if you
  • 26:32 - 26:38
    would rather program everything yourself
    by interacting directly with registers. We
  • 26:38 - 26:43
    use free RTOS as a Real-Time operating
    system. The basic software of ECUs has
  • 26:43 - 26:47
    several tasks running in parallel, one for
    receiving CAN messages, one for sending
  • 26:47 - 26:53
    CAN messages and several periodic tasks to
    take care of the ECU control loops. Those
  • 26:53 - 26:58
    tasks receive data from different
    interrupt services within, using queues and
  • 26:58 - 27:04
    DMA memory overwrites. The tasks can also
    exchange data between each other using
  • 27:04 - 27:12
    queues or memory overwrites. Again, to
    keep the project accessible to beginners,
  • 27:12 - 27:15
    we did the OS configuration using the
    graphical interface where you can see all
  • 27:15 - 27:20
    tasks and their configuration, for example
    the priority. You can add or remove
  • 27:20 - 27:24
    interrupts. And you can also configure the
    various queues in memory. There is still a
  • 27:24 - 27:31
    lot of memory left even though the memory
    controller is less performant. So you can
  • 27:31 - 27:41
    easily add your own application on top of
    this. That's all for the hardware and
  • 27:41 - 27:45
    software section, you can find more
    details on GitHub. I would like to move to
  • 27:45 - 27:50
    the next section and show you a usage
    example. There are usually two budgets for
  • 27:50 - 27:54
    people working in automotive security
    Either they are automotive engineers who
  • 27:54 - 27:59
    learn about security or they are security
    engineers who wrote about automotive
  • 27:59 - 28:03
    systems. Since this is a security
    conference and I assume most people do not
  • 28:03 - 28:07
    need me to explain how the platform can be
    used to study and research basic security
  • 28:07 - 28:15
    topics, I will focus on the automotive
    side. So diagnostics and calibration topic
  • 28:15 - 28:25
    is already covered by many security
    talks. I will not spend time on this. So
  • 28:25 - 28:30
    I will spend time on something
    that is not often mentioned at security
  • 28:30 - 28:37
    conferences: Control algorithms and safety
    critical hardware and software. And for
  • 28:37 - 28:40
    this, I would like to demonstrate the
    design of a PID controller for cruise
  • 28:40 - 28:44
    control as an example. I will show you how
    being knowledgeable in control systems may
  • 28:44 - 28:49
    be relevant to security engineers, and how
    many of the activities that are done by
  • 28:49 - 28:55
    engineers in the automotive industry can
    also be simulated using open source tools,
  • 28:55 - 29:01
    including RAMN. Once we have an
    implementation in C that works, I would
  • 29:01 - 29:05
    then use it as a reference to talk about
    safety critical systems and the
  • 29:05 - 29:14
    differences with real ECU hardware and
    software. So let's get started. Cruise
  • 29:14 - 29:18
    control is very simple: When a human is
    controlling the throttle with the
  • 29:18 - 29:25
    accelerator pedal depending on the skill
    the car may have an uneven speed. What we
  • 29:25 - 29:29
    want is an ECU that optimizes the control
    of the throttle so that we can maintain a
  • 29:29 - 29:37
    steady speed. An automatic car can be very
    easy to model. If you press the
  • 29:37 - 29:41
    accelerator pedal, which opens the
    throttle, you will get speed out of your
  • 29:41 - 29:46
    car. But the relationship between speed
    and throttle is not as simple as a
  • 29:46 - 29:50
    multiplication. No, we have to follow the
    laws of dynamics. In this case that's the
  • 29:50 - 29:57
    sum of forces on the car is equal to its
    mass times its acceleration. We can
  • 29:57 - 30:01
    consider that there is a force pushing the
    car that is proportional to the throttle,
  • 30:01 - 30:06
    and that there is an opposing force
    proportional to the speed due to friction.
  • 30:06 - 30:12
    When we solve this diversal equation, what we
    expect to see is that the speed follows an
  • 30:12 - 30:18
    exponential curve. And a simple way to
    control the speed that may come to your
  • 30:18 - 30:22
    mind is open loop control. You make some
    measurements on the flat road of the
  • 30:22 - 30:27
    relationship between throttle and maximum
    speed, and you keep in a lookup table.
  • 30:27 - 30:31
    When the user asks the ECU to reach a
    certain speed, the ECU can use the lookup
  • 30:31 - 30:38
    table to find what throttle controls
    should be applied based on past
  • 30:38 - 30:43
    measurements. And this may work in some
    situations, but according to the laws of
  • 30:43 - 30:51
    dynamics, as soon as we reach an upward
    slope, the car will lose speed because of
  • 30:51 - 30:56
    gravity. So at least that is what we
    expect, but we should verify that on the
  • 30:56 - 31:02
    CAN bus. This is something we can use RAMN
    for. Here again, using an external CAN
  • 31:02 - 31:08
    adapter connected to a second PC. On that
    PC I simply receive data from the physical
  • 31:08 - 31:13
    CAN bus. For the rest of the section I
    will only be modifying the firmware on the
  • 31:13 - 31:26
    power train ECU. I will not change the
    simulator, I will not even reboot it.
  • 31:26 - 31:31
    So in the simulator, I drove around the city
    to try to find a nice place to experiment.
  • 31:31 - 31:40
    More precisely, I looked for a place with
    flat road followed by an upward slope.
  • 31:40 - 31:44
    Then I programmed the power train ECU to a
    apply a constant throttle, which is only
  • 31:44 - 31:49
    one line of code. And after reprogramming
    the ECU I let the car drive straight and I
  • 31:49 - 32:08
    recorded data from the CAN bus. I used an
    open source tool for CAN bus analysis
  • 32:08 - 32:14
    called Bus Master. Bus Master allows you
    to load DBC files or to input manually the
  • 32:14 - 32:19
    format of your CAN frames. Here I simply
    told Bus Master what were the CAN
  • 32:19 - 32:24
    arbitration IDs of the throttle control
    message and the speed sensor message. And
  • 32:24 - 32:30
    what was the format of the payload. Once I
    do that, I can plot the evolution of the
  • 32:30 - 32:36
    throttle and speed over time. And the
    results we get are exactly what we
  • 32:36 - 32:41
    expected from our differential equations.
    The speed of the vehicle is following an
  • 32:41 - 32:44
    exponential curve and as soon as we reach
    the upward slope, we start loosing speed
  • 32:44 - 32:49
    because the throttle is constant. There
    are some noise and non-linearities at low
  • 32:49 - 32:54
    speed but overall it seems our model of
    the car is correct. We are approaching the
  • 32:54 - 33:01
    problem correctly. What we can see here is
    that it takes about 40 seconds for one
  • 33:01 - 33:06
    test-drive. And 40 seconds is already too
    long. So before testing the ECU in the
  • 33:06 - 33:10
    driving simulator, we want to use the
    software that can simulate differential
  • 33:10 - 33:14
    equations so that we can see the impact of
    the cruise control algorithm directly,
  • 33:14 - 33:19
    without having to wait for 40 seconds.
    Most of the time this is done using a
  • 33:19 - 33:25
    professional tool such as Matlab and
    Simulink. But here we will use open source
  • 33:25 - 33:30
    tool Scilab. It has a graphical interface
    where we can connect inputs and outputs
  • 33:30 - 33:37
    from a block diagram. Differential
    equations are a bit hard to deal with
  • 33:37 - 33:41
    because the relationship between inputs
    and outputs is complicated. What you
  • 33:41 - 33:46
    typically do in control theory is use a
    Laplace transform, which will change the
  • 33:46 - 33:51
    variable called t to a complex number
    called s. This may be complicated with a
  • 33:51 - 33:54
    contradictory background, but you just
    need to know that a differentiation is
  • 33:54 - 33:59
    equivalent to a multiplication by s and
    that integration is equivalent to division
  • 33:59 - 34:05
    by s. In our system it is easier to model
    the Laplace transform because we now have
  • 34:05 - 34:10
    a simple relationship between throttle and
    speed. Speed equals transfer function of
  • 34:10 - 34:18
    car times throttle. And based on the
    measurements from the CAN bus, we can
  • 34:18 - 34:26
    evaluate the transfer function of the car
    to be equal to approximately 1 / (1 + 4s).
  • 34:26 - 34:30
    We can simulate the car in Scilab by
    using a block function which has the exact
  • 34:30 - 34:37
    same transfer function. Using Scilab, we
    can now test various scenarios and get the
  • 34:37 - 34:41
    results immediately. Here I am testing the
    scenario in which we start from zero
  • 34:41 - 34:47
    speed, apply a constant throttle and after
    20 seconds, we add a new force - gravity -
  • 34:47 - 34:53
    which corresponds to the slope. And this
    is what we call here the disturbance. And
  • 34:53 - 34:57
    with Scilab simulation we can verify we
    get waveforms similar to our measurements
  • 34:57 - 35:02
    on the CAN bus. With a constant throttle,
    the speed follows an exponential curve
  • 35:02 - 35:08
    that is close to maximum speed after
    around 14 seconds. And as soon as there is
  • 35:08 - 35:12
    a disturbance: the gravity here, showing
    green, we can check that the car looses
  • 35:12 - 35:18
    speed because there is no reaction from
    the throttle. So to fix that the solution
  • 35:18 - 35:25
    is obvious: The ECUs need to have
    feedback. We need the ECU to make use of
  • 35:25 - 35:30
    the speed sensor data that it can find on
    the CAN bus so that it can adapt the
  • 35:30 - 35:35
    throttle to the actual speed of the
    vehicle. So first solution that may come
  • 35:35 - 35:40
    to mind to software engineers is Bang-Bang
    Control. Bang-Bang Control is quite
  • 35:40 - 35:45
    simple. You measure the speed and if it is
    above a certain threshold, you stop
  • 35:45 - 35:50
    applying the throttle. If it goes below a
    certain threshold, you apply the throttle
  • 35:50 - 35:59
    again. This is extremely easy to implement
    in C on the ECU. And once we reprogram the
  • 35:59 - 36:03
    ECU on RAMN, we can make measurements on
    the CAN bus and verify that this time we
  • 36:03 - 36:09
    are not loosing speed anymore when we
    reach a slope. But as you can see, there
  • 36:09 - 36:14
    are some oscillations. And as you can
    imagine, the oscillations are not
  • 36:14 - 36:18
    something very nice for passengers.
    Apparently people driving like this is the
  • 36:18 - 36:23
    reason cruise control was invented. I do
    not know if that story is true, but I can
  • 36:23 - 36:28
    believe it. So Bang-Bang Control made a
    good start, but it is not good enough for
  • 36:28 - 36:36
    cruise control. And the most famous
    algorithm used in control theory is the
  • 36:36 - 36:40
    PID controller. You can find a lot of
    resources online. The PID controller is
  • 36:40 - 36:45
    one of the control mechanism used in
    software of the self-driving AI of CARLA.
  • 36:45 - 36:49
    In the PID controller you measure the
    difference between the target speed and
  • 36:49 - 36:55
    the current speed. You call that different
    error and you can control the throttle
  • 36:55 - 37:00
    using the sum of 3 control blocks. The
    error multiplied by Kₚ. The integral of
  • 37:00 - 37:06
    the error multiplied by Kᵢ and the
    derivative of the error multiplied by Kd.
  • 37:06 - 37:17
    Kₚ, Kᵢ and Kd are constant called gains.
    And you need to have a very fine tuning of
  • 37:17 - 37:22
    those gains to achieve optimal control.
    Here I can simulate the PID controller
  • 37:22 - 37:27
    using Scilab with different blocks.
    Remember that the division by s is an
  • 37:27 - 37:33
    integration, and the multiplication by s
    is a derivation. Thanks to the simulation
  • 37:33 - 37:38
    I am able to try many values without
    having to actually drive the car. And when
  • 37:38 - 37:48
    we are able to find correct values for the
    PID controller, we get this. The ECU is
  • 37:48 - 37:51
    able to reach a target quite quickly
    without oscillations and without
  • 37:51 - 37:58
    overshooting the maximum speed. And when
    there is a disturbance so gravity, it will
  • 37:58 - 38:02
    dynamically adapt the controls of the
    throttle so that the target speed is
  • 38:02 - 38:08
    maintained. So this is good, because this
    is what we want for cruise control. But is
  • 38:08 - 38:13
    a gain of only one control block is
    correct, the speed of the vehicle may look
  • 38:13 - 38:17
    like something totally different,
    potentially dangerous. And this is why the
  • 38:17 - 38:21
    integrity of calibration data is important
    not only from a safety point of view, but
  • 38:21 - 38:25
    also from a security point of view.
    Because an attacker should not be able to
  • 38:25 - 38:37
    make an ECU have a dangerous behavior with
    only one small change. The last thing I
  • 38:37 - 38:41
    need to explain is how to implement these
    algorithms in C, and this is not obvious
  • 38:41 - 38:45
    because we're dealing with integration and
    derivations, which are not possible for
  • 38:45 - 38:51
    digital functions. So there are many ways
    to implement this in a digital PID
  • 38:51 - 38:58
    controller in C. I will just explain two
    approaches. The first approach is to stay
  • 38:58 - 39:02
    in the time domain and approximate the
    derivation by the difference between two
  • 39:02 - 39:07
    successive errors divided by the sampling
    time. And we can approximate the integral
  • 39:07 - 39:15
    operation with a Riemann sum which is a
    running sum of errors so far multiplied by
  • 39:15 - 39:21
    the sampling time. This may look a bit
    intimidating, but when you look at it
  • 39:21 - 39:25
    closely, you can see it is just a
    combination of constants and values that
  • 39:25 - 39:33
    can be computed from current and past
    sensor values from the CAN bus. The actual
  • 39:33 - 39:39
    implementation in C looks like this. We
    need to define 2 variables. One to store
  • 39:39 - 39:46
    the running sum of errors and one to store
    the error of the previous control loop
  • 39:46 - 39:51
    execution. In the control loop, we define
    constant gains for each stage. We compute
  • 39:51 - 40:00
    the current error. We add the error to the
    sum of all errors. We compute the
  • 40:00 - 40:05
    difference between current errors and
    previous error. We then add all those
  • 40:05 - 40:10
    values with the respective gain to the
    output variable and then we clamp that
  • 40:10 - 40:17
    output in case it goes out of bound. We
    then apply the throttle control and save
  • 40:17 - 40:25
    the current error in the previous error
    variable for use in the next iteration.
  • 40:25 - 40:31
    The second approach is to use a Laplace
    transform of the PID controller. We first
  • 40:31 - 40:35
    need to convert it to a Z transform, the
    equivalent of Laplace transform but for
  • 40:35 - 40:39
    digital signals. It looks a bit
    complicated, but there are many tools to
  • 40:39 - 40:44
    do the conversion for you. If you want to
    do the conversion by hand, one way is to
  • 40:44 - 40:55
    use the bilinear transformation in which
    you replace s by this, to approximate the Z
  • 40:55 - 41:07
    transform of your ECU. And again, this may
    all look a bit intimidating, but you can
  • 41:07 - 41:11
    actually compute the throttle output by
    using the throttle output from 2
  • 41:11 - 41:17
    iterations ago, the current error, the
    previous error and the error before that
  • 41:17 - 41:21
    which can all be computed from sensor
    values on the CAN bus. And while this
  • 41:21 - 41:26
    control algorithm is equivalent to our
    previous implementation, it looks totally
  • 41:26 - 41:32
    different. And what I would like to stress
    here that identical control algorithms may
  • 41:32 - 41:36
    have very different software
    implementations, which may be relevant for
  • 41:36 - 41:48
    reverse engineers. I only show the first
    implementation not waste time, but you can
  • 41:48 - 41:53
    see now that the ECU in RAMN is able to
    make the car maintain a constant speed and
  • 41:53 - 42:05
    for dynamic control of the throttle. So
    that's it for the example. I just wanted
  • 42:05 - 42:09
    to show that RAMN can be used for
    realistic activities of the CAN bus and
  • 42:09 - 42:14
    that the ECUs are not just doing some
    random easy work. The control theory part
  • 42:14 - 42:18
    may be complicated and if that was going
    too fast for you at least I hope it proves
  • 42:18 - 42:22
    there is a lot of things to discover and
    experiment with. And that all that
  • 42:22 - 42:37
    learning can be done with open source
    tools. Now I would like to discuss what
  • 42:37 - 42:41
    would have been different with real ECUs
    because, as you can imagine, actual ECU
  • 42:41 - 42:47
    software is not as simple as this. I will
    also show you what alternatives we have.
  • 42:47 - 42:53
    Technologies hidden behind NDAs, so that
    we can get as close as we can to real
  • 42:53 - 43:00
    ECUs. We showed in RAMN that this cruise
    control ECU worked, but we only tried it
  • 43:00 - 43:06
    on a single scenario, namely a flat road
    followed by an upward slope. But what
  • 43:06 - 43:10
    about this scenario in which a car in
    front is driving slowly? Or what about a
  • 43:10 - 43:15
    scenario in which we are in a downward
    slope? In this case the ECU will not be
  • 43:15 - 43:18
    able to prevent a car from going too fast
    because it does not have access to the
  • 43:18 - 43:25
    brakes, which could lead to an accident.
    And the difficult problem here is not
  • 43:25 - 43:29
    whether you can think of one more
    scenario. The difficult problem is can you
  • 43:29 - 43:34
    think of them all are you sure? And
    thinking of all potential scenarios,
  • 43:34 - 43:38
    quantifying the risk and implementing
    countermeasures is what makes automotive
  • 43:38 - 43:47
    systems really different. And to prove
    that an ECU is reasonably safe, you
  • 43:47 - 43:53
    actually need to follow ISO 26262
    standard, which is a standard for
  • 43:53 - 43:59
    functional safety. The standard defines
    different requirements at many levels. Not
  • 43:59 - 44:03
    all ECUs are equally critical, so safety
    relevant issues are assigned and
  • 44:03 - 44:10
    automotive safety integrity level or ASIL
    for short. And ASIL A is a less critical
  • 44:10 - 44:17
    level and ASIL D is the most critical
    level. So if you were to design a real
  • 44:17 - 44:21
    cruise control ECU for use in a real car,
    you could not just connect some random ECU
  • 44:21 - 44:26
    to the CAN bus and try it on the highway.
    You will need to go through a lot of
  • 44:26 - 44:32
    analysis, such as HAZOP, HARA, FMEA, STPA
    and so on. Usually there are so many
  • 44:32 - 44:37
    requirements that they cannot be tracked
    with only a human and a sheet of paper.
  • 44:37 - 44:46
    They are managed using dedicated tools
    such as Rational Doors. Now let's discuss
  • 44:46 - 44:51
    how the software would be different. The
    main contribution of automotive software
  • 44:51 - 44:55
    is to realize control algorithms safely.
    But without countermeasures, many things
  • 44:55 - 45:01
    could go wrong. For example there could be
    bugs in the ECU application code. And then
  • 45:01 - 45:05
    without any bug the software will be
    robust enough when there are transient
  • 45:05 - 45:12
    errors in the hardware. There could also
    be problems with the toolchains that
  • 45:12 - 45:24
    compile the firmware and problems with the
    libraries and RTOS. And when we have a
  • 45:24 - 45:28
    close look at the PID controller
    implementation which seemed good enough in
  • 45:28 - 45:33
    our testing, you can see it is actually a
    terrible implementation. We are mixing
  • 45:33 - 45:38
    integers and unsigned integers and floats
    without proper checks and type casting. We
  • 45:38 - 45:45
    are not checking for overflows and also
    random software issues. And this is not
  • 45:45 - 45:49
    acceptable, both for safety and security.
    And in this case, the problems were
  • 45:49 - 45:52
    obvious on purpose, but sometimes it can
    be very hard to spot because they stem
  • 45:52 - 45:59
    from very subtle computing issues. And
    those issues may lead to system failures.
  • 45:59 - 46:03
    So to avoid such scenarios, the automotive
    industry usually mandates the use of a
  • 46:03 - 46:08
    language subset which restricts what
    developers can do, but makes sure that
  • 46:08 - 46:16
    numerical errors are less likely to
    happen. So usually in the automotive
  • 46:16 - 46:22
    industry, the standard that is used is
    MISRA-C and it is very similar to CERT-C,
  • 46:22 - 46:31
    which is popular in the security industry.
    Using a language subset is only one of the
  • 46:31 - 46:36
    requirements that are dictated by ISO
    26262. There are many other requirements.
  • 46:36 - 46:41
    At a high level they try to enforce a low
    complexity of the software. For example,
  • 46:41 - 46:46
    by restricting the size of components,
    restricting the copying between software
  • 46:46 - 46:51
    components and making sure the scheduling
    is appropriate. And that there are not too
  • 46:51 - 46:55
    many interrupts. But we also have more
    concrete requirements, such as restricting
  • 46:55 - 46:59
    functions to 1 entry and 1 exit point,
    forbid dynamic memory, avoid global
  • 46:59 - 47:08
    variables, limit the use of pointers and
    so on. The other issues we have to deal
  • 47:08 - 47:12
    with, which is riddled with bugs is
    transient errors. In the harsh
  • 47:12 - 47:16
    environment, data is not always reliable.
    There may be a bit flip occurring outside
  • 47:16 - 47:23
    of memory, for example, because of noise
    and communication lines, but also may be
  • 47:23 - 47:27
    bit flips occurring inside a microcontrollers
    memory. For example, because of cosmic
  • 47:27 - 47:32
    rays. Those issues do not originate from
    software, they originate from hardware,
  • 47:32 - 47:36
    but they do need to be addressed by
    software because remember, in the case of
  • 47:36 - 47:41
    the example cruise control ECU, just one
    bit flip could lead to unwanted behavior of
  • 47:41 - 47:47
    the ECU and the car. So to address those
    issues, automotive controllers need
  • 47:47 - 47:52
    special countermeasures. For example
    having redundant memory or having
  • 47:52 - 48:00
    redundant CPUs. In ECUs, you will
    typically find microcontrollers that have
  • 48:00 - 48:04
    been designed specially for automotive
    use. All those microcontrollers require
  • 48:04 - 48:09
    you to sign an NDA so you can not just buy
    them and start programming them. So that
  • 48:09 - 48:16
    makes it a bit hard to study an actual ECU
    microcontroller and real automotive
  • 48:16 - 48:23
    software. ISO 26262 is not the only
    standard for safety critical systems. ISO
  • 48:23 - 48:30
    26262 is actually derived from IEC 61508,
    so they are both similar in their
  • 48:30 - 48:36
    concepts. And IEC61508 microcontrollers
    they do not require NDAs for most other
  • 48:36 - 48:42
    activities you may be interested in. And
    more completely RAMN can be used with
  • 48:42 - 48:47
    STM32L4 or STM32L5 microcontrollers. And
    for those microcontrollers, you do not
  • 48:47 - 48:53
    need an NDA to download guidelines on how
    to implement safe software. For example,
  • 48:53 - 48:56
    you can find a list of features that are
    required for safety applications, and you
  • 48:56 - 49:01
    can request more data that you would need
    to actually achieve compliance with
  • 49:01 - 49:07
    IEC 61508, such as the FMEA and FMEDA. But to
    obtain those data, you would need to sign an
  • 49:07 - 49:13
    NDA. No, I personally do not think that
    those data are essential for education and
  • 49:13 - 49:20
    research. So using such microcontrollers
    is a good alternative. But again, let me
  • 49:20 - 49:23
    stress that this is an alternative for
    learning and researching, not for actual
  • 49:23 - 49:29
    use in a car. I don't have time to detail
    all the safety features, let me just talk
  • 49:29 - 49:35
    about memory redundancy, since this one
    impacts the code of the application of the
  • 49:35 - 49:42
    example cruise control ECU. So in the
    example, we wrote the gain of each stage
  • 49:42 - 49:47
    in code memory defining them as constants.
    For safer applications, this would not be
  • 49:47 - 49:53
    here. They belong to another section, the
    data flash where ECC protection can be
  • 49:53 - 49:58
    activated. If possible, calibration data
    should be stored twice with checksums and
  • 49:58 - 50:04
    preferably MACs. If you're not familiar
    with ECC memory, it is a kind of memory
  • 50:04 - 50:09
    that can detect bit flips and sometimes
    automatically corrects them. Another
  • 50:09 - 50:13
    memory is also available for the RAM,
    but not at all addresses. So in the
  • 50:13 - 50:17
    application, we have to ensure that safety
    critical variables are placed in a section
  • 50:17 - 50:25
    of RAM in which bit flips can be detected,
    in this case in section SRAM2. For data in
  • 50:25 - 50:31
    RAM that are actually constants such the
    gains you may also want to activate write
  • 50:31 - 50:37
    protection, a feature that is only
    available in SRAM2. Last slide about
  • 50:37 - 50:44
    software. In the example cruise control,
    we are using GCC toolchain in ISO 26262 it
  • 50:44 - 50:48
    is a requirement to have what is called a
    tool confidence lever to ensure that
  • 50:48 - 50:53
    poor chains will not introduce errors as it
    could be the case with some optimizations.
  • 50:53 - 50:58
    So normally you cannot use GCC. Realtime
    operating systems and libraries may also
  • 50:58 - 51:03
    have problems. That is why they need to be
    certified. Both STM32-HAL and FreeRTOS are
  • 51:03 - 51:11
    compliant with MISRA-C which is nice, but
    they are not compliant with ISO 26262.
  • 51:11 - 51:16
    However, it looks like ST is bringing
    Azure RTOS into the ecosystem and that one
  • 51:16 - 51:25
    is actually precertified ISO 26262. Maybe
    in the future it would be an option to
  • 51:25 - 51:31
    experiment with with an actual ISO 26262
    operating system. So now let's talk a bit
  • 51:31 - 51:34
    about hardware. In case it was not clear
    to you, you cannot use commercial
  • 51:34 - 51:38
    electronics to implement an ECU.
    Smartphone vendors will often warn you not
  • 51:38 - 51:42
    to let a device in your car because a
    parked car can reach extreme temperatures
  • 51:42 - 51:47
    that commercial electronics are not
    designed to resist. And if you think that
  • 51:47 - 51:52
    the life inside the cabin is hard, you
    should think about an ECU which has to
  • 51:52 - 51:57
    stay in the engine compartment and operate
    without failures. And you would not think
  • 51:57 - 52:04
    of putting a smartphone or an Arduino here
    and trust your life with it. And extreme
  • 52:04 - 52:07
    temperatures are just one of the many
    environmental factors that make it
  • 52:07 - 52:11
    difficult for an ECU to stay reliable. The
    ECU also need to resist high humidity,
  • 52:11 - 52:18
    corrosive gases, vibrations, micro cuts,
    load dumps, electrostatic discharges,
  • 52:18 - 52:27
    electromagnetic noise and so on. And when
    subjected to such a harsh environment,
  • 52:27 - 52:30
    many things could go wrong with
    electronics. You probably know about
  • 52:30 - 52:35
    corrosion, but many other physical
    phenomena are at risk of happening to the
  • 52:35 - 52:39
    components. Solder cracs, intermetallic
    growth, whiskers, dendrites,
  • 52:39 - 52:45
    electromigration, etc. For example,
    whiskers are metal growing out of
  • 52:45 - 52:48
    electrical components and dendrites are
    metals leaving the plus side towards the
  • 52:48 - 52:54
    minus side. And many other phenomena may
    result in a dangerous failure. So
  • 52:54 - 52:58
    obviously, ECUs need to be designed to
    resist harsh environments and have
  • 52:58 - 53:02
    countermeasures against all those
    potential failures. ECUs need to pass
  • 53:02 - 53:06
    various tests that simulate harsh
    environments. Those tests are usually
  • 53:06 - 53:11
    defined by manufacturers and the test
    specifications are not made public. What
  • 53:11 - 53:15
    is made public, however, is the test
    specifications for individual electronic
  • 53:15 - 53:20
    components. And those tests are usually
    defined by AEC. So the Automotive
  • 53:20 - 53:28
    Electronic Council, and you can have a
    look at them online. For RAMN, we tried to
  • 53:28 - 53:32
    follow design guidelines similar to those
    of real ECUs. But of course, we cannot
  • 53:32 - 53:38
    follow actual rules as it to be much less
    accessible. Completely, we selected
  • 53:38 - 53:42
    AEC-Q100 grade zero components for
    everything except connectors and
  • 53:42 - 53:46
    microcontrollers, because those may
    require NDAs or not be easily accessible.
  • 53:46 - 53:51
    Depending on the part reference, ECU
    microcontrollers may be usable from -40 to
  • 53:51 - 53:56
    125°C. RAMN tried to stay close to
    automotive grade, but it is still not
  • 53:56 - 54:00
    automotive grade, especially in the
    reliability department, so it can not be
  • 54:00 - 54:06
    used as a real ECU. As a result, we try to
    stay close to automotive hardware is to
  • 54:06 - 54:10
    help researchers evaluate the impact of
    manufacturing tolerances and environments
  • 54:10 - 54:17
    because remember, manufacturers are making
    millions of cars that need to operate on a
  • 54:17 - 54:21
    large temperature range. So if you are
    developing, for example, a security
  • 54:21 - 54:25
    technology that relies on hardware
    characteristics such as the clocks of the
  • 54:25 - 54:30
    ECUs, you will need to prove that the
    technology works despite manufacturing
  • 54:30 - 54:35
    tolerances and harsh environments. And
    with RAMN it is easy to have a large
  • 54:35 - 54:40
    sample of ECU networks and since they are
    small they can easily fit in various
  • 54:40 - 54:47
    testing equipment. And now let's move on
    to the last section, security. In the
  • 54:47 - 54:52
    automotive industry, we just can not apply
    the same reasoning as you do in many other
  • 54:52 - 54:57
    industries. For example, a credit card, if
    you detect the temperature is too cold, it
  • 54:57 - 55:01
    may think that it is a tampering attack
    and decides to shut down because it is not
  • 55:01 - 55:06
    safety critical. On the other hand, the
    car needs to start quickly because the
  • 55:06 - 55:12
    user should not be left out in the cold
    and also credit cards have an expiration
  • 55:12 - 55:17
    date. So they do not need to guarantee
    security for more than a few years. But
  • 55:17 - 55:22
    cars do not have an expiration date. If
    they are well maintained they may be used
  • 55:22 - 55:27
    for several decades and the security
    technologies should keep on working. So in
  • 55:27 - 55:31
    the end, automotive security technologies
    have different requirements.
  • 55:31 - 55:35
    Unfortunately, according to past research,
    a security technology is often less
  • 55:35 - 55:39
    reliable when you extend its operating
    temperature range and its lifetime. For
  • 55:39 - 55:45
    example, at low temperatures, they may be
    liable to cold boot attacks. At high
  • 55:45 - 55:50
    temperatures, it has also been shown that
    electronics tend to be less reliable
  • 55:50 - 55:54
    concerning glitching attacks and in those
    papers high-temperature means something
  • 55:54 - 56:01
    like 60 or 100°C, far from the maximum
    temperature required for some ECUs. Also,
  • 56:01 - 56:06
    it has been shown that the higher age for
    electronics usually results in different
  • 56:06 - 56:13
    security properties. And you may think
    that the safety features of automotive
  • 56:13 - 56:17
    microcontrollers would prevent some
    attacks such as glitching attacks, but it
  • 56:17 - 56:22
    has been shown that ECC memories are also
    susceptible to glitching attacks. And that
  • 56:22 - 56:28
    even ISO 26262 ASIL-D microcontrollers,
    which is the highest level of safety may
  • 56:28 - 56:32
    be susceptible to glitching. So safety
    features often help, but there aren't
  • 56:32 - 56:39
    really enough to ensure security. What is
    also different with automotive is that you
  • 56:39 - 56:43
    need to rethink the strategy in case of
    security problems, for example, with
  • 56:43 - 56:48
    credit cards, it is not uncommon for
    authentication to fail randomly. When the
  • 56:48 - 56:54
    credit card fails to work usually you just
    need to try it once more and it will
  • 56:54 - 57:00
    probably work and everything stays again.
    No life is at risk. But the car cannot
  • 57:00 - 57:07
    have the same strategy. If you add
    authentication to the brake CAN message
  • 57:07 - 57:11
    and you start receiving break request that
    fail authentication what should the car
  • 57:11 - 57:18
    really do. Because it may be a cyber
    attacks, which you want to avoid, but you
  • 57:18 - 57:23
    should not relay out the possibility of a
    random malfunction or a false positive for
  • 57:23 - 57:27
    an intrusion detection system. And by
    adding complexity into the system, you
  • 57:27 - 57:33
    always increase the odds of a problem. And
    which one would be worse between breaking
  • 57:33 - 57:40
    because of a cyber attack or not breaking
    because of a malfunction? And there is no
  • 57:40 - 57:44
    easy way to answer that question. But what
    I want to stress here is that many
  • 57:44 - 57:47
    security countermeasures that people
    suggest for cars such as encrypting the
  • 57:47 - 57:52
    CAN bus, permanently disabling debug ports
    or obfuscating the firmware, they may not
  • 57:52 - 57:58
    necessarily be the best ideas, because if
    you suspect a malfunction with an ECU, you
  • 57:58 - 58:03
    need to investigate the problem seriously
    because it may harm people. You cannot
  • 58:03 - 58:10
    just replace a car as you would with a
    credit card or a smartphone.
  • 58:10 - 58:14
    So technologies that can truly take into
    account both automotive requirements and
  • 58:14 - 58:17
    security requirements are better. And we
    should make sure that education and
  • 58:17 - 58:22
    research in these areas are accessible to
    many researchers without NDAs or
  • 58:22 - 58:29
    prohibitive costs. Now, of course, you can
    use RAMN to try out different attacks. The
  • 58:29 - 58:33
    first obvious one is to inject CAN
    messages to alter the behavior of the car.
  • 58:33 - 58:56
    Here for example the breaks. Another kind
    of security that I did not mention in this
  • 58:56 - 59:00
    presentation is physical security for
    sensors and actuators. Here I am
  • 59:00 - 59:03
    demonstrating what happens when it
    overtake the control of the steering wheel
  • 59:03 - 59:09
    actuator. A human will probably break in
    this situation. The self driving algorithm
  • 59:09 - 59:13
    in CARLA here does not realize it has lost
    control of the steering wheel and is still
  • 59:13 - 59:20
    trying to correct the trajectory when a
    better decision would be to stop the car.
  • 59:20 - 59:25
    So this is the end of the presentation. We
    developed an inexpensive, safe and
  • 59:25 - 59:30
    interactive platform to study and research
    automotive systems. The platform is
  • 59:30 - 59:35
    accessible to beginners. It is not
    automotive grade, but is close enough for
  • 59:35 - 59:39
    research and educational purposes. The
    project is open source and with permissive
  • 59:39 - 59:44
    licenses. If you have questions or ideas,
    do not hesitate to contact us, especially
  • 59:44 - 59:49
    if you are involved with education,
    research, training, CTF, etc. And thank
  • 59:49 - 59:58
    you for watching.
  • 59:58 - 60:03
    Herald: Camille, thanks for this
    comprehensive talk, this was amazing. We
  • 60:03 - 60:06
    unfortunately don't have much time for
    the questions or answers, but there is
  • 60:06 - 60:12
    one question that popped up, which is
    about the hardware and your PCB. How did
  • 60:12 - 60:16
    you design it? How much does it cost
    actually, how can you get hold of that
  • 60:16 - 60:20
    thing?
    Camille: So I designed everything with
  • 60:20 - 60:25
    KiCAD. And I mean, I think a few years ago
    it was very hard to design hardware, but
  • 60:25 - 60:32
    now you have footprint libraries available
    online. It has become very easy. The board
  • 60:32 - 60:37
    was between 50 to 100€ for a quantity of
    one. So microcontrollers are obviously the
  • 60:37 - 60:43
    expensive parts and the PCB assembling
    parts - it is up to the PCB Fabrication
  • 60:43 - 60:50
    Service. If you have questions just ask me
    on GitHub, I would be happy to answer.
  • 60:50 - 60:59
    rC3 postroll music
  • 60:59 - 61:29
    Subtitles created by c3subtitles.de
    in the year 2021. Join, and help us!
Title:
#rC3 - RAMN: Resistant Automotive Miniature Network
Description:

more » « less
Video Language:
English
Duration:
01:01:29

English subtitles

Revisions