 Welcome to your time talk operation, and this is a presentation about ramen, a platform that will be developed to make education and research in the automotive systems more accessible. The automotive industry can be inaccessible to many people because automotive projects may involve prohibitive costs and be tied to NDAs that not everybody is willing to sign. What we want to propose with this project is an expensive testbed to study and research automotive systems, which is both open source and developed with open source tools so that at least anyone can get access to a good alternative for education and research. The main focus of this testbed is security, but you will see that the usage of the testbed is not limited to security, and I will keep the security talk mostly for the end of the presentation. I will start by giving a short introduction about automotive systems, then I will present the design details of the testbed with various demonstrations and concrete details about its hardware and software. As an example of how the testbed can be used, I will spend some time experimenting with rules control, and by that I mean I will go through the whole development process starting from evaluating differential equations of a simple mechanical model. I will experiment with various control strategies, implement them in C, and make measurements in a driving simulator using early data from the canvas. And I will do all that using early open source tools. This is to demonstrate how the testbed can be used, but also to have a concrete project that I can use as a reference to explain after, what concretely would have been different if we were experimenting with a real electronic control unit. I will also explain how we can get close to automotive hardware and software without signing NDAs. So the second part of the talk is mainly here to give you more information about the automotive industry in case you are not familiar with it. Before I start, let me just clarify that this is not an advertisement, we are not selling anything we present here, and we do not profit financially from it. We are simply sharing design files with permissible licenses and without royalties. Okay, so first let me give you a very quick introduction about automotive systems. You can see a car as a collection of systems divided in four different domains, the parturing domain, which includes the engine and the transmission, the chassis domain, which includes the steering column and suspensions, the body domain, which includes the lights, the doors, and heating, and the input element domain, which includes navigation and connectivity. Many of the different systems that can be found in a car are controlled by electronic control units or ECUs or short. There are many kinds of ECUs in the car, sometimes hundreds of them, and usually they are not hard to understand. They have a limited number of inputs, generally data from sensors and actuators, and they have a limited number of outputs, generally to control actuators. So for example, an airbag ECU may use an accelerometer as its input, and an airbag trigger as its output. The role of the ECU will be to use data from the accelerometer to detect a shock and output a signal at its actuator to detonate an airbag when a shock is detected. It is very common for ECUs to need data from other ECUs. Most of the time, ECUs, we need to share data with other ECUs on the same domain. In the case of an automatic car, for example, the transmission of proper units needs input from the engine ECU to determine the current gear. If that data is critical, that connection may even be redundant. ECUs may also need to communicate with ECUs on a different domain. For example, the brake system, usually the chassis domain, we need to communicate its state to the stockman, usually in the body domain. Most of the time, the technology that is used for communication is CAN. And CAN technology uses a burst topology, which means a CAN message will be received by all ECUs on the same CAN bus. There is no authentication or encryption at the link layer, so any message can be sent by any ECU, and security features need to be implemented at higher layers. A startup CAN frame consists mainly of an arbitration ID of 11 bits and a payload of 8 bytes. CAN HD is a recent evolution of CAN, where the payload size may be extended up to 64 bytes. For an ECU network, manufacturers will assign a meaning to each arbitration ID and each bit in their payload. The file that determines the traffic on the CAN bus is often referred to as a DBC file. For example, assuming a long controller and two lamps on the CAN bus, the manufacturer may decide that ID123 is used by the long controller to communicate the command of both lamps, that ID124 is used by the left lamp to give feedback about the status, and that ID125 is used by the right lamp to give feedback about its status. Each of those messages will be broadcasted periodically by the assigned ECU on the CAN bus and will serve as the basis for most data exchange between ECUs. So that is for the introduction. There are many reasons why people may be interested in auto-test systems and ECU networks. The activity that gets by far the most attention from the media is vulnerability research, but there are also other reasons. For example, owners may want to check their class compliance with regulations, such as emissions regulations and privacy regulations, for example, GDPR. Other owners may want to exercise their rights to RIPR if they are guaranteed by the countries they live in. And finally, some owners may want to experiment and innovate with DIY features, or simply satisfy their curiosity and educate others. And while those may be valid reasons to experiment with a car, manufacturers are typically against people tinkering with a car because they may be worried about their intellectual property being stolen, about vulnerabilities being exploited, or people hurting themselves and others while tinkering. And what probably suffers the most from this delicate situation is education and research in automotive security because people cannot easily get access to safe equipment or access to the information that they would need. In the long term, this may mean that manufacturers will have less security technologies to choose from to secure their cars, and that less talents will be available to develop and evaluate them. And the development, of course, involves many people from many companies, so it is important to make sure that everyone involved is competent in automotive security. And some people are pushing for more open-sourcing cars and who knows, maybe one day a car will be 100% open source, but if it happens, it is going to take a long time. And manufacturers themselves do not have access to 100% of the source code of the cars they make because ECUs contain intellectual property from other companies. So this is mostly a political topic, so there is not much we can contribute to as researchers. However, one way we can contribute technically right now is to try the other way around and use what is publicly available to make it accessible to learn and research automotive systems. And that is what we try to do with Raven, which is a topic of this presentation. The objective is to provide a platform for research that is open and by that we mean it should be easy to modify the source code and reprogram the ECUs. Accessible and by that we mean inexpensive, small and requiring no prior skills in automotive systems, safe with no risk of accidents or legal repercussions, and motivating, something that you can interact with. So that you get the same kind of experience as you do when you experiment with a real car. So there are already some solutions available if you want to experiment with an EC network, besides, of course, a real car. So the first one is making your own test bed from real ECUs. So we can see many hackers sharing that test bed at security conferences. And usually if you see something like this, you stop and you immediately get interested. So it is a nice way to motivate people to learn. Unfortunately, those are not easy to reprogram because manufacturers do not share information about the ECUs, and they require a lot of skills to build. So it's not accessible to everyone. Another option is to use development boards, such as Arduino. And that is what you can see mostly on academic papers. They have the advantage of being reproducible and you can modify the source code as you want. So they can be used in many cases for research, but they lack many safety features for open phone and actual ECU hardware and software. Even if you are able to simulate a CAN bus, you don't get the same level of direction as you do with a car. So it's not something that motivates people and makes them want to learn more. And the third option is to use a professional test bed, such as Pasta, another work from our team. This is a good option because you get access to the source code and you can reprogram the ECUs and the CAN bus network is already simulating a full car. So the groundwork is already done. It's a major drawback, so that it is very expensive. So it is not accessible to everyone. So there are some options to study and research automotive systems, but none of them seem to be both accessible and motivating at the same time. So many people don't even think of learning about automotive systems because it never occurred to them that they could like it. And in comparison with other industries, you have so many ways to get started. If you want to learn about Linux, you can start with a Raspberry Pi. If you want to learn about electronics, you can start with an Arduino and so on. So we wanted some things that would give a similar experience, but for automotive systems. So we noticed that most of the test beds that people are using to experiment with ECUs are made of four ECUs. So the ECUs are often communicating with each other using a CAN bus. So we tried to fit all that in a ECB, the size of a credit card, and we named that PCB ramen. It features four ECUs connected over a CAN bus which is accessible from outside by your terminal block. One of the ECUs is also connected to connect to USB, which is also the power supply. Pins sockets can be used to connect sensors, actuators, and additional hardware. And the port features many probes to easily access important electric signals. The four ECUs simulate a CAN network with messages identical to pasta. The name ramen is obviously a reference to pasta because it is a cheap alternative, mostly aimed at students. In real course, CAN messages typically have different payload sizes, but by default we operate with maximum payload size to demonstrate heavy traffic. So the basic format is like this, arbitration ID, two bytes of the data, two bytes for a counter, and four bytes of additional data, random data used as a placeholder for additional data such as checksum or MAC. You can easily modify the CAN messages arbitration ID in format, and here we are assuming a full by-wire vehicle, which means all physical functions of a car are accessible to the CAN bus, which is usually not the case on current cars. The block diagram of ramen looks like this, and as I explained earlier, all ECUs are periodically exchanging messages on the CAN bus. If you connect a CAN adapter and have a look at the traffic, it will typically look like this. So the port itself is enough to simulate an EC network, but it does not look very motivating. What we wanted on top of this was some sensors and actuators to make it more interactive. So we created four expansion boards for sensors and actuators to simulate the infotainment domain we simply use a screen. For the body domain, we use an engine key and some LEDs. For the chassis domain, we mainly use a slide switch to simulate the side brake and a rotating potentiometer to simulate the steering wheel. And for the powertrain domain, we use slide potentiometers for the brake and accelerator, and a joystick for the shift lever. The EC connected to USB implements a standard CAN or KFD interface, either over a standard serial port using SL CAN or over a native interface on Linux, thanks to the Kondalight firmware projects. If you connect the port to USB ports on a computer, it should be recognized as a USB to CAN adapter. So it is not necessary to own an external CAN adapter to get started. This is a little more of what it looks like to use ramen. Just connect it over USB if you use Linux. You can get it to be recognized as a standard CAN network interface. So it will show up in this config. Then you can use various tools available on Linux to observe the traffic. For example, CAN sniffer. Here you can see the traffic explained earlier, the CAN IDs on the left, and the payload on the right. So with this, we can simulate an EC network with sensors and actuators that is enough for basic interactions, but it still does not feel like you are actually experimenting with a car. Ideally, the ECU should be performing realistic ECU functions, not just lighting up LEDs based on some switches and potentiometers. And for this, we thought that the connection in a closed loop with an open source driving simulator would be an affordable and safe solution to feel like you are driving the ECU network. Fortunately, there is a great open source driving simulator for autonomous driving research. It is called Cora. It features a Python API which is very easy to interact with it. And it also comes with an example central algorithm. So you can immediately start experimenting with a virtual safe driving car. So we wrote some scripts so that most sensors value, for example, speed and altitude would be simulated on the computer running car then broadcasted on the canvas. On the other side, we made it so that all controls of car such as throttle, steering, and brakes would be decided by the ECU network. And this is what you could refer to as hails or hardware in the loop simulation in the automotive industry. Ramen is not as advanced as professional tools but at least it is accessible. So to achieve manual control, it is not complicated with Cora. On the manual control example provided with the API, there is a wide true game loop that reads events of the keyboard, applies controls, then updates the physics simulation. So Cora does not simulate a canvas by default. So we created a Python class to easily interact with the canvas using the canvas as a specification of Ramen. To integrate it with Cora, we just need to replace keyboard controls with accurate control data read from the canvas. To close the loop, we broadcast sensor data using CAD messages based on data retrieved from the Python API of the physics simulator. Every piece we're able to control the car manually is the potentiometers on the board. Here, identity press accelerator, release the handbrake, and I can control the car using the steering wheel as the expansion board. So manual control is nice but automatic control is better because ultimately we want to focus on working on the canvas. So on the original Cora project, there is also an example script for automatic control. Again, there is a wide true loop where the code basically simulates the physics, lets the server in AI make a decision, then applies the controls to the physics simulation. To integrate Ramen with the server algorithm, again, we need to replace the applied control part with the controls from the EC network. We also need to send CAD messages with sensor data retrieved from the Python API of the physics simulation that is identical to having manual control. What we need to do more is also send message to broadcast the status of the AI to the EC network. So that the EC network knows what controls the AI algorithm is requesting. So periodically, the AI will broadcast its status by sending messages over USB, which are converted into CAD messages by the EC connected to USB. All ECUs on the network will receive those messages and will decide the actual controls of the car based on their own algorithm. For example, the partner ECU may decide to apply breaks depending on the highest value between the AI breaks and the break potentiometer. All ECUs will receive the CAD message that applies the control. Some ECUs may filter that message if they do not need it. Some ECUs, like the body ECU, may process it and take action. For example, if the breaks are engaged, the body ECU will light up the stop lamp on the expression board. Finally, the ECU connected to USB will forward the break controls to the simulator that will apply the breaks in the physics simulation. So this is what it actually looks like. All I need to do again is release the handbrake and the car will drive itself. So the car is controlled by the EC network. So when the car stops in the simulation, it is because the controls were applied as a pro-trail ECU. You can see that the stop lamp lights up because the body ECU also received and processed the break CAD message. Since the ECU is in charge of the controls, I can force the car to stop anytime by forcing breaks of the pro-trail ECU potentiometer. So if you connect an external CAD adapter to the CAN bus, you will be able to send and receive messages. So using Raman, you can experiment with the CAN bus of a self-driving virtual car. When you want to reprogram an ECU, in the real world, you have two options. Either you interact with the hardware bootloader as the ECU's microcontroller, which depends on the microcontroller's model and manufacturer, or you interact with diagnostics and calibration software, which depends on the car model and manufacturer. Diagnostic and calibration are often done on the CAN bus, but other options may be available. Protocols are defined by standard documents. You often hear about UDS and OBD2, which both rely on the same transport layer IsoTP, but there are also other protocols, such as Keyword Protocol 2000 or XCP. All those protocols can often also be implemented over other layers. For the hardware bootloaders, it depends on the microcontroller manufacturer. For example, for an XTM32 microcontroller, you can reprogram the firmware by interacting over CAN, according to the application note 3154. Over USB, according to the application note 3156, are using other protocols defined in other application notes. In the case of RAMEN, we use the hardware bootloader to reprogram the ECU's, and we can also use the UDS protocol over CAN. And in the future, we may consider adding XCP and KWP 2000. How to reprogram an ECU using calibration and diagnostic software is a topic that is already heavily discussed at automotive security talks, so I will not spend time on this topic. You can find the definition of the standards online. Usually, you need to pay for them, but you can also find summaries for free on some websites. For example, Wikipedia. What is more interesting to discuss here is the hardware bootloader. The various ways to force a microcontroller into bootloader mode are described in the application note 2606. The format of CAN messages you need to send to interact with the bootloader is defined in the application note 3154, and it's not complicated. The format is simply command byte plus argument, all that within the same CAN message payload. So we wrote some script to make it easier to interact with the bootloader. So here I am showing the script that we used to interact with the bootloader. First thing I do is retrieve all information from the bootloader, including the version, to supported commands, and the chip ID. I then use the read memory command to dump all known sections of memories. This includes the ECU firmware. So it can be a good start to start experimenting with reverse engineering. You can also activate memory without protection and see what happens when you try to dump the memory again. And in this case, it's not allowing memory dumps anymore. You can remove the memory protection, which will wipe out the memory. And after you do that, you can use the bootloader to reprogram the ECUs. For the hardware, we also designed additional expansion boards with various features. First one is an expansion to connect a JTAG debugger. Second one is a board to add external quad-SPA memories, which are SYC packages, such as EEPROM, F-RAM, FlashNOR, NAN, S-RAM, and so on. The third one is a board to add a trusted platform module. And the last one is an interface to easily connect a chip whisperer. All those expansions are compatible with each other, so you can stack them and create a very advanced EC network with all ECUs between a TPM and one gigabit of memory. And it looks better when many expansions are stacked on top of each other. Since we would like to use Raman for education, we try to vary the type of electrical signals used in the expansions. And we added many external probes to easily connect external tools. You can use one of the many external probes to connect an oscilloscope and have a look at analog signals. For example, here's a bright potentiometer. Or connect a logic analyzer and have a look at digital signals. For example, to analyze SPI communication between the ECU and the screen. For the hardware design, we kept it simple, using only two layers and keeping all components on the same side. We designed the hardware with large tolerances so it should be easy to produce with most PCB fabrication services. We used components with large size, so if you have some skills in soldering, you should be able to solder one yourself. We designed the hardware using PCAD, which is an open source tool for designing hardware. You can easily modify the schematics layout and even generate nice PD views. So firmware is designed using STM32 cube ID. It is accessible to beginners and you can easily reconfigure peripherals and clocks from the graphical interface. You will even get some statistics such as estimated power consumption. But of course, you do not need to use the graphical interface in libraries if you would rather program everything yourself by interacting directly with registers. We use FreeRcast as a real-time operating system. The basic software of ECUs has several tasks running in parallel, one for receiving messages, one for sending messages and several periodic tasks to take care of the ECU control loops. Those tasks receive data from different interrupt services within, using queues and DM memory overrides. The task can also exchange data between each browser using queues or memory overrides. Again, to keep the project accessible to beginners, we did the OS configuration using the graphical interface where you can see all tasks as a configuration, for example, the priority. You can add or remove interrupts and you can also configure the values queues and memory. There is still a lot of memory left and then even on the memory controller with less performances. So you can easily add your own application on double this. All that's all for the hardware and software section. You can find more details on GitHub. I would like to move to the next section now and show you a usage example. There are usually two patterns for people working in automotive security. Either there are automotive engineers who run about security or there are security engineers who run about automotive systems. Since this is a security conference and I assume most people do not need me to explain how the platform can be used to study and research basic security topics, I will focus on the automotive side. The diagnostics and calibration topic is already covered by many security talks so I will not spend time on this. So I will spend time on something that is not often mentioned in security conferences, control algorithms and safety critical hardware and software. And for this, I would like to demonstrate the design of the PID controller for cruise control as an example. I will show you how being knowledgeable in control systems may be relevant to security engineers and how many of the activities that are done by engineers in the automotive industry can also be simulated using open source tools including ramen. Once we have an implementation in C that works, I will then use it as a reference to talk about safety critical systems and the differences with real ECU hardware and software. So let's get started. Cruise control is very simple. When a human is controlling the portal with the accelerator pedal, depending on the skill that the car may have an available speed, what we want is an ECU that optimizes the control of the throttle so that we can maintain a steady speed. An automatic car can be very easy to model. If you press the accelerator pedal which opens the throttle, it will get speed out of your car. But the relationship between speed and throttle is not as simple as a multiplication. Now, we have to follow the laws of dynamics. In this case, that's a sum of forces on the car is equal to its mass times its acceleration. We can consider that there is a force pushing the car that is proportional to the throttle and that there is an opposing force proportional to the speed due to friction. When we solve this differential equation, what we expect to see is the speed to follow an exponential curve. And a simple way to control the speed that may come to your mind is open look control. We make some measurements on a flat road of the relationship between throttle and maximum speed and you keep it in a lookup table. When the user asks the ECU to reach a certain speed, the ECU can use the lookup table to find what throttle control should be applied based on path measurements. And this may work in some situations but according to the laws of dynamics, as soon as we reach an upward slope, the car will lose speed because of gravity. So at least that is what we expect but we should verify that on the canvas. This is something we can use random for. Here, I am using an external can adapter connected to a second PC. On that PC, I simply receive data from the physical canvas. For the rest of the section, I will only be modifying the firmware on the portrait ECU. I will not change the simulator, I will not even reboot it. So in the simulator, I drove around in the city to find a nice place to experiment. More precisely, I looked for a place with a flat road followed by an upward slope. Then I programmed the portrait ECU to apply a constant throttle, which is only one line of code. And after reprogramming the ECU, I left the car drive straight and I recorded data from the canvas. I use an open source tool for canvas analysis called Bus Master. Bus Masters allows you to load DVC files or to input manually the format of your canvas. Here, I simply told Bus Master what were the kind of application ideas of the throttle control message and the speed sensor message and what was the format of the payload. Once I do that, I can pull the evolution of the throttle and speed over time. And the results we get are exactly what we expected from our differential equations. So speed of the vehicle is following an exponential curve and as soon as we reach the upward slope, we start using speed because the throttle is constant. There are some notes and non-linearities at low speed, but overall it seems our model of the car is correct. We are approaching the problem correctly. What we can see here is that it takes around 40 seconds for one test drive. And 40 seconds, it's already too long. So before testing the ECU in the driving simulator, we want to use a software that can simulate differential equations so that we can see the impact of the cruise control algorithm directly without having to wait 40 seconds. Most of the time, this is done using a professional tool such as MacLab or Simulik, MacLab and Simulik, but here we will use the open-source tool SyLab. It has a graphical interface where we can connect inputs and outputs from a block diagram. Differential equations are a bit hard to deal with because the relationship between inputs and outputs is complicated. What you typically do in control theory is use the Laplace transform, which will change the variable from time t to a complex number called s. This may be complicated with our control theory background, but you just need to know that a differentiation is equivalent to a multiplication by s and that an integration is equivalent to a division by s. And our system is easier to model with the Laplace transform because we now have a simple relationship between spotter and speed. Speed equals transfer function of car times spotter. And based on the measurement from the canvas, we can evaluate the transfer function of the car to be equal to approximately one over one plus four s. We can simulate the car in SyLab by using a block function which has the exact same transfer function. Using SyLab, we can notice various scenarios and get the results immediately. Here I am testing the scenario in which we start from zero speed, apply a constant throttle, and after 20 seconds we add a new force, gravity, which corresponds to the slope. And this is what we call here the disturbance. And with SyLab simulation, we can verify we get waveforms similar to our measurements on the canvas. With a constant throttle, the speed follows an exponential curve that is close to maximum speed after around 14 seconds. And as soon as there is a disturbance, the gravity here showing green, we can check that the car loses speed because there is no reaction from the throttle. So to fix that, the solution is obvious. The ECUs need to have feedback. We need the ECU to make use of the speed sensor data that it can find on the canvas so that it can adapt the throttle to the actual speed of the vehicle. The first solution that may come to mind to software engineers is bang-bang control. Bang-bang control is quite simple. You measure the speed and if it is above a certain threshold, you stop applying the throttle. If it goes below a certain threshold, you apply the throttle again. This is extremely easy to implement in C on the ECU. And once we reprogram the ECU, the ECU on runway, we can make measurements on the canvas and verify that this time we are not losing speed anymore when we reach a slope. But as you can see, there are some oscillations. And as you can imagine, the oscillations are not something very nice for passengers. Apparently, people driving like this is the reason cruise control was invented. I did not know that story is true, but I can't believe it. So bang-bang control may be a good start, but it is not good enough for cruise control. And the most famous algorithm used in control theory is a PID controller. You can find a lot of resources online. A PID controller is one of the control mechanisms used in software with the central AI of KARA. In the PID controller, you measure the difference between the target speed and the current speed. You call that difference the error. And you can control the throttle using the sum of three control blocks. The error multiplied by Kp, the integral of the error multiplied by Ki, and the derivative of the error multiplied by Kd. Kp, Ki, and Kd are constants called gains. And you need to have a very fine tuning of those gains to achieve optimal control. Here, I can simulate the Kd controller using SIDA with different blocks. Remember that the division by S is an integration and the notification by S is a derivation. Thanks to the simulation, I am able to try many values without having to actually drive the car. And when we are able to find correct values, when we are able to find correct values for the PID controller, we get this. So ECU is able to reach a target speed quickly without oscillations and without overshooting the maximum speed. And when there is a disturbance to gravity, it will dynamically add up the controls of the throttle so that the target speed will maintain. So this is good because this is what we want for a cruise control. But if the gain of only one control block isn't correct, the speed of the vehicle may look like something totally different, potentially dangerous. And this is why the integrity of calibration data is important, not only from a safety point of view, but also from a security point of view because an attacker should not be able to make an ECU have a dangerous behavior with only one small change. And last thing I need to explain is how to implement this algorithm in C. And this is not obvious because we are dealing with integration and derivations which are not possible for digital functions. So there are many ways to implement this in a digital PID controller in C. I will just explain two approaches. The first approach is to stay in the time domain and approximate the derivation by the difference between two successive errors divided by the sampling time. And we can approximate the integral operation with a Riemann sum, which is a running sum of errors so far multiplied by the sampling time. This may look a bit intimidating, but when you look at it closely, you can see it is just a combination of constants and values that can be computed from current and past tense of values from the canvas. So actual implementation in C looks like this. We need to define two variables, one to store the surrounding sum of errors and one to store the error from the previous control loop execution. In the control loop, we define constant gains for each stage. We compute the current error. We add the error to the sum of all errors. We compute the difference between current errors and previous error. We then add all those value with that respective gain to the output variable and we clone that output in case it goes out of bound. We then apply the total control and save the current error in the previous error variable for use in the next iteration. The second approach is to use the Laplace transform of the PID controller. We first need to convert it to a Z transform, the equivalent of Laplace transform, but for digital signals. It looks a bit complicated, but there are many tools to do the conversion for you. If you want to do the conversion by hand, one way is to use the binary binary transformation, in which you replace S by this. To approximate the Z transform of your ECU. And again, this may all look a bit intimidating, but you can actually compute the total output by using the total output from two iterations ago, the current error, the previous error and the error before that, which can all be computed from sensor values on the canvas. And while this control algorithm is equivalent to our previous implementation, it looks totally different. And what I would like to stress here is that identical control algorithm may have very different software implementations, which may be relevant for reverse engineers. I only show the first implementation not waste time, but you can see now that the ECU in ramen is able to make the car maintain a constant speed if a dynamic control of the throttle. So that's it for the example. I just wanted to show that ramen can be used for realistic activities on the canvas, and that the ECUs are not just doing some random easy work. The control theory part may be complicated, and if that was going too fast for you, at least I hope it proves there is a lot of things to discover and experiment with, and that all that learning can be done with open source tools. Now I would like to discuss what would have been different with ECUs, because as you can imagine, the actual ECU software is not as simple as this. I will also show you what technologies we have, technologies hidden behind NDAs, so that we can get as close as we can to real ECUs. We show that ramen in ramen that this cruise control ECU worked, but we only tried it on a single scenario, namely a flat road followed by an upward slope. But what about the scenario in which a car in front is driving slowly? Or what about the scenario in which we are in a downward slope? In this case, the ECU will not be able to prevent the car from going too fast because it does not have access to the brakes, which could lead to an accident. And the difficult problem here is not whether you can think of one more scenario. The difficult problem is, can you think of them all? And are you sure? And thinking of all dangerous scenarios, quantifying the risk and implementing contravengers is what makes automotive systems really different. And to prove that an ECU is reasonably safe, you ideally need to follow ISO 262 standard, which is a standard for functional safety. The standard safety, the standard defines different requirements at many levels. Not all ECUs are equally critical, so safety relevant ECUs are assigned an automotive safety integrity level or ACL for shots. And ACLA is the less critical level, and SLD is the most critical level. So if you were to design a real cruise control ECU for use in a real car, you could not just connect some random ECU to the canvas and try it on the highway. You will need to go through a lot of analysis, just such as hazard, error, FMEA, STPA, and so on. Usually there are so many requirements that it cannot be tracked with only a human and a sheet of paper. They are managed using dedicated tools such as rational doors. So let's discuss how the software will be different. The main contribution of automotive software is to realize control algorithm safely. But without countermeasures, many things could go wrong. For example, there could be bugs in the ECU application code. And then without any bug, the software may not be robust enough when there are transient errors in the hardware. There could also be problems with the tool chains that compare to firmware, and problems with the libraries and RTOS. And when we have a close look at the PID controller implementation, which seemed good enough in our testing, you can see it is actually a terabyte implementation. We are mixing integers and unsigned integers and floats before proper checks and typecasting. We are not checking for overflows and other random software issues. And this is not acceptable above for safety and security. And in this case, the problems were obvious on purpose, but sometimes it can be very hard to spot because they stand from very subtle computing issues. And those issues may lead to system failures. So to avoid such scenarios, the automotive industry usually mandates the use of a language subset, which restricts what developers can do, but make sure that numerical errors are less likely to happen. So usually, usually in the automotive industry, the start of this use is MISRACI. And it is very similar to SIRT-C, which is popular in the safety industry. Using a language subset is only one of the requirements that are dictated by ISO 26262. So many other requirements at a high level, they try to enforce a low complexity of the software. For example, by restricting the size of components, restricting the coupling between software components and making sure the scheduling is appropriate. And that's not too many interrupts. But they also have more concrete requirements, such as restricting functions to one entry and one exit point, forbid dynamic memory, avoid global variables, limit the use of pointers, and so on. The other issues we have to deal with, which is additive to bugs, is transient errors. In a harsh environment, data is not always reliable. There may be bitflips occurring outside of memory, for example, because of noise and communication lines, but there may also be bitflips occurring inside of macro-controllers' memory, for example, because of cosmic rays. Those issues do not originate from software, they originate from hardware, but they do need to be addressed by software, because, remember, in the case of the example cruise control ECU, just one bitflip could lead to unwanted behavior of the ECU on the car. So to address these issues, automatic micro-controllers need special control measures, for example, having redundant memory or having redundant CPUs. In ECUs, you will typically find micro-controllers that have been designed specially for automotive use. All those micro-controllers require you to sign an NDA, so you cannot just buy them and start programming them. So that makes it a bit hard to study an actual ECU microcontroller and read automotive software, but ISO 26262 is not the only standard for safety-critical systems. ISO 26262 is actually derived from IEC 61508, so they are both similar in their concepts. And IEC 61508 microcontrollers, they do not require NDAs for most other activities you may be interested in. And more concretely, Raven can be used with STM32L4 or STM32L5 microcontrollers. And for those microcontrollers, you do not need an NDA to download guidelines on how to implement safe software. For example, you can find a list of features that are required for safety applications. And you can request more data that you would need to actually achieve compliance with IEC 61508, such as the FMEA and FMEDA. But to obtain those data, you would need to sign an NDA. No, I personally do not think that those data are essential for education and research. So using such microcontrollers is a good alternative. But again, let me stress that this is an attempt for learning and researching, not for actual use in the car. I don't have time to detail all the safety features. Let me just talk about memory redundancy since this one impacts the code of the application of the example cruise control EC. So in this example, we wrote the gain of each stage in code memory, defining them as constants. For a safer application, they should not be here. They belong to another section, the data flash where ECC protection can be activated. If possible, calibration data should be stored twice with text sums and preferably max. If you are not familiar with ECC memory, it is a kind of memory that can detect B-flips and sometimes automatically correct them. But not that memory is also available for the RAM, but not that hard addresses. So in the application, we have to ensure that safety critical variables are placed in a section of RAM in which B-flips can be detected. In this case, in section S1-2. For data in RAM that are actually constant, such as the gains, you may also want to activate write protection, a feature that is only available in S1-2. Okay, last slide about software. In the example cruise control, we are using GCC tool chain. In ISO 26262, it is a requirement to have what is called a tool confidence level to ensure that tool chains will not introduce errors, as it could be the case with some optimizations. So normally you could not use GCC. Real-time operating systems and libraries may also have problems, that is why they need to be certified. Both STM32-HAL and free RTOS are compliant with Biswasi, which is nice, but they are not compliant with ISO 262. However, it looks like ST is breaking all zero RTOS into the ecosystem, and that one is actually pre-certified ISO 26262. So maybe in the future, it would be an option to experiment with an actual ISO 26262 operating system. So now let's talk a bit about hardware. In case it was not clear to you, you cannot use commercial electronics to implement an ECU. Smartphone vendors will often warn you why not to let a device in your car, because a parked car can reach extreme temperatures that commercial electronics are not designed to resist. And if you think that the life inside the cabin is hard, you should think about an ECU, which has to stay in the engine compartment and operate without failures. And you would not think of putting a smartphone on an Arduino here and trust your life with it. And extreme temperatures are just one of the many environmental factors that make it difficult for an ECU to stay reliable. The ECU also needs to resist high humidity, corrosive gases, vibrations, microcuts, load dumps, electrostatic discharges, electromagnetic noise, and so on. And when subjected to such a harsh environment, many things could go wrong with electronics, you probably know about corrections, but many other physical phenomena are at risk of happening to the components. Solder cracks, incalmetallic growth, whiskers, dendrites, electron migration, et cetera. For example, whiskers are metal growing out of electrical components, and dendrites are metal leaving the plus side towards the minus side. And many other phenomena may result in a dangerous failure. So obviously, ECUs need to be designed to resist harsh environments and hard contra-measures against all those potential failures. ECUs need to pass various tests that simulate harsh environments. Those tests are usually defined by manufacturers and the test specifications are not made public. What is made public, however, is the test specifications for individual electronic components. And those tests are usually defined by AC, so the automotive electronic console. And you can have a look at them online. For RAMEN, we try to follow design daylights similar to those of real ECUs, but of course we cannot follow actual rules as it would be much less accessible. Completely, we selected AC-Q100 grade zero components for everything except collectors and microcontrollers because those may require NDA or not be easily accessible. Depending on the part reference, ECU microcontrollers may be usable from minus 40 to 125 degrees. RAMEN tried to stay close to automotive grade, but it is still not automotive grade, especially in the reliability department, so it can't be used as a real ECU. And the reason we try to stay close to automotive hardware is to help researchers evaluate the impact of manufacturing tolerances and environments because remember, manufacturers are making millions, of course, then need to operate on a large operator range. So if you are developing, for example, a security technology that relies on hardware characteristics such as the clocks of the ECUs, you will need to prove that the technology works despite manufacturing tolerances and harsh environments. And with RAMEN, it is easy to have a large sample of ECU networks and since they are small, they can easily fit in various testing equipment. And now let's move on to the last section, security. So in the automotive industry, you just cannot apply the same reasoning as you do in many other industries. For example, a credit card, if it detects the temperature is too cold, it may think that it is a tampering attack and decide to shut down because it is not safely critical. On the other hand, a card needs to start quickly because the user should not be left out in the cold. And also credit cards have an expiration date, so they do not need to guarantee security for more than a few years, but cards do not have an expiration date. If they are well maintained, they may be used for several decades and the security technologies should keep on working. So in the end, automotive security technologies have different requirements. Unfortunately, according to past research, a security technology is often less reliable when you extend its operating temperature range and its lifetime. For example, at low temperatures, you may become vulnerable to cold boot attacks. At high temperatures, it has also been shown that electrolytes tend to be less reliable concerning glitching attacks and in those papers, high temperature means something like 60 degrees or 100 degrees Celsius. Far from the maximum temperature, we call it for some ECUs. Also, it has been shown that the higher age for electronics usually results in different security properties. And you may think that the safety features of automotive microcontrollers will prevent some attacks such as glitching attacks, but it has been shown that ECC memories are also susceptible to glitching attacks and that even ISO 2662-ACLT microcontrollers is the highest level of safety may be susceptible to glitching. So safety features often help, but they are really enough to ensure security. What is also different with automotive is what you need to rethink your strategy in case of security problems. For example, with credit cards, it is not uncommon for authentication to fail randomly. When a credit card fails to work, usually you just need to try once more and it will probably work. And even if it fails again, no light is at risk. But the card cannot have the same strategy. If you add authentication to the can break, if you add authentication to the break can message and you start receiving break request messages that fail authentication, what should the card really do? Should the card really do? Because it may be a cyber attack which you want to avoid, but you should not rule out the possibility of a random malfunction or a false positive for an intrusion detection system. And by adding complexity into the system, you always increase the odds of a problem. And which one would be worse between breaking because of a cyber attack or not breaking because of a malfunction? And there is no easy way to answer that question, but what I want to stress here is that many security countermeasures that people suggest for car, such as encrypting the canvas, permanently disabling debug ports or obfuscating the firmware, they may not necessarily be the best ideas because if you suspect a malfunction with an ECU, you need to investigate the problem seriously because it may harm people. You cannot just replace the car as you would with your credit card or a smartphone. So technologies that can truly take into account both automotive requirements and security requirements are better and we should make sure that education and research in these areas are accessible to many researchers without NDAs or prohibitive costs. Now, of course, you can use ramen to try out different attacks. The first obvious one is to inject messages to alter the behavior of the car. Here, for example, the brakes. Another kind of security that I did not mention in this presentation is physical security for sensors and actuators. Here, I am demonstrating what happens when I overtake the control of the steering wheel actuator. A human will probably brake in this situation. The state driving algorithm in CARLA here does not realize it has lost control of the steering wheel and it is still trying to correct the trajectory when a better decision will be to stop the car. So this is the end of the presentation. We developed an inexpensive, safe and interactive platform to study and research automotive systems. The platform is accessible to beginners. It is not automotive grade but it is close enough for research and educational purposes. The project is open source and with permissive licenses. If you have questions or ideas, do not hesitate to contact us, especially if you are involved with education, research, trainings, CTF, et cetera. And thank you for watching. Camille, thanks for this comprehensive talk. This was amazing. We unfortunately don't have much time for your question and answers, but there's one question that popped up which is about the hardware and your PCB. How did you design it? How much does it cost actually? How can you get actually hold of that thing? Yes, so I designed everything with KiCad. And I mean, I think a few years ago, it was very hard to design hardware, but now you have footprint libraries available online. It has become very easy. So BOM was between 50 to 100 euros for a quantity of one. The microcontrollers are obviously the expensive parts. And the PCB and assembling part, it is up to the PCB fabrication service. If you have questions, just ask me on GitHub. I will be happy to answer.