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