Development of a Man-in-the-Middle Attack Device for the CAN Bus∗ András Gazdag, Csongor Ferenczi, Levente Buttyán CrySyS Lab, Department of Networked Systems and Services, Budapest University of Technology and Economics agazdag@crysys.hu csferenczi@crysys.hu buttyan@crysys.hu Proceedings of the 1st Conference on Information Technology and Data Science Debrecen, Hungary, November 6–8, 2020 published at http://ceur-ws.org Abstract Modern vehicles are full of embedded controllers called ECUs (Electronic Control Units). They are responsible for different functionalities involving processing information from sensors and controlling actuators. To perform their functions, ECUs also need to communicate with each other. Most ve- hicles use a Controller Area Network (CAN) for ECU communication. The original design of the CAN bus was focusing on safety and reliability prop- erties. Security was not an issue because these networks were considered to be isolated systems. These assumptions were correct for a long time, but they no longer hold. Modern vehicles have many interfaces towards the outside world, which renders the internal network accessible to an attacker. Bluetooth, Wifi, wireless Tire Pressure Monitoring System (TPMS), or the On-Board Diagnostics (OBD) port are all options for attackers to either di- rectly access the CAN network or compromise a component attached to it. Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). ∗ This work has been partially funded by the European Commission via the H2020-ECSEL- 2017 project SECREDAS (Grant Agreement no. 783119) and partially supported from the grant GINOP- 2.1.1-15 (the project has been supported by the European Union, co-financed by the European Social Fund. EFOP-3.6.2-16-2017-00002). The research presented in this paper have also been supported by the NRDI Office, Ministry of Innovation and Technology, Hungary, within the framework of the Autonomous Systems National Laboratory Programme, and the NRDI Fund based on the charter of bolster issued by the NRDI Office. 115 It is possible to inject fake messages, or potentially, to modify messages on the CAN, and hence, forcing some ECUs to act upon these fake messages, which may influence the overall behaviour of the vehicle. Modification attacks are complex both to carry out and to detect. The main difficulty of modification attacks is that the sender checks whether the transmitted bits correctly appear on the bus or not for safety reasons. The only network level way to circumvent this protection is to physically separate the sender and the attacked ECU on the CAN bus. This can be achieved with a physical layer Man-in-the-Middle attack. We built a proof-of-concept hard- ware device capable of modifying the CAN traffic in real-time to demonstrate that this attack is possible. It has two CAN interfaces to read messages from the original CAN bus and either just forward or modify-and-forward traffic to the attacked CAN bus. We showed with measurements that we can perform a message modification attack while keeping the introduced delay within what is allowed by the CAN specification. Keywords: Vehicle Security, CAN, ISO 11898, Man-in-the-Middle attack 1. Introduction Modern cars are not just simple mechanical devices with an engine and four wheels like they used to be. They are full of Electronic Control Units (ECU) that control the car, monitor the drivers’ every movement, and try to keep them safe on the road, while providing convenience features to them. Thus, more and more components have to communicate with each other in a car, which means that we need reliable communication channels between these components. One of the most common communication solutions is the Controller Area Network (CAN) bus. When it comes to manufacturers, they put a great emphasis on the safety of the cars. There are ABS, ESP, crash avoidance systems, or even better and better crumple zones in every car. The inter-component communication channels are protected against errors caused by the high noise environment, but security seems to be less important for manufacturers. The internal components are rarely designed to be secure from a potential attacker, although it is not unthinkable that a malicious device could be installed into a car and do some harm. For instance, it only takes one mechanic to plug such a device into an On-Board Diagnostics (OBD) port of a targeted car, and we have access to the vehicle’s CAN bus. Moreover, with the spread of Bluetooth OBD debugging probes, which can connect to the owner’s smartphone, users themselves connect more and more, potentially compromised, devices onto the CAN bus. Unfortunately, the CAN bus has no security, only safety measures. It was designed to be a robust communication bus that can withstand a high amount of noise while providing relatively high transfer speeds. At the end of every CAN message, a Cyclic Redundancy Check (CRC) code ensures that if the content of the message changes during transmission, the receiver will detect it. However, the CAN standard does not provide support for message authentication. Thus, just by receiving a message with a given ID does not guarantee that the source of the 116 message was any particular device. This leads to the issue that messages can be injected onto the bus without the communication partners ever noticing that a message was not sent by the correct device and could contain false data. Besides injecting messages, an attacker could modify the content of the message, but achieving this is much harder. With the current techniques, it is only feasible by compromising an ECU, and sending messages with modified values. This attack produces no extra messages, nor highly deviating values; thus, it is much harder to detect than simple message injection attacks, but until now, it required a more in- depth knowledge1 to carry out than just plugging in a device to the OBD port. In this paper, we present our solution to modify CAN messages in real-time, without compromising any ECU. We have created a device, which is capable of modifying ISO 11898 high-speed CAN messages in real-time. It can handle up to 100% bus load with a bus speed of 500 kbps or less, and about 60-100% busload at 1 Mbps, which is the maximum speed specified in the standard. It introduces a delay of 260 𝜇s, which is even at 1 Mbps is well within the delay of re-sending a message due to high traffic or a transient error on the bus. The device itself provides a wireless interface that can be used to remotely configure the attack parameters. All this, while consisting of cheap, commonly available parts. In Section 2, we are going to take a deeper look at the current attacks against the CAN bus and their mitigations, and how our solution differs from them. In Section 3, we summarize the important parts of the CAN standard. In Section 4, we discuss the design principles of the introduced device, the hardware and software architecture, and the operation of the device. In Section 5, we take a look at the measurements of the device, and finally, in Section 6, we conclude our work. 2. Related Work There is a large amount of published research on the (in)security of the CAN bus. Many of them propose a solution to protect the CAN bus [11, 12], but there are several papers discussing different kinds of attacks against it [3, 9]. We can generally categorize the attacks into two groups: message injection and message modification attacks. 2.1. Attacks Against the Can Bus 2.1.1. Message Injection Attacks Message injection attacks [8] are possible due to various properties of the CAN bus. First of all, since the CAN bus is a broadcast channel, during operation, every ECU connected to the CAN bus receives all of the messages. This cost-saving measure saves a lot of money for the manufacturers, since they only have to wire a few twisted pair cables throughout the whole car in order to connect the ECUs to each 1 http://illmatics.com/remote\%20attack\%20surfaces.pdf 117 other. When receiving a message, the ECUs decide whether they are interested in the given message based on its ID and process it or discard it. On the other hand, this principle also makes it easy for an attacker to eavesdrop messages on the bus, monitor the values of the sensors in real-time, or reverse engineer the messages and their purposes for a given vehicle type. The second issue with the standard is that the CAN bus does not support any kind of cryptographic message authentication measures. Any ECU can create a message with an arbitrary ID and send it to the other ECUs via the CAN bus, and the ECUs will not be able to differentiate the messages coming from two different ECUs, if they have the same ID. This makes an attacker able to craft arbitrary messages and send them to the ECUs via the CAN bus. An attacker can have multiple goals to exploit these properties, for instance, overwriting values or forcing the network into a Denial of Service attack state. Message injection attacks have several drawbacks. First of all, both the rapidly changing value behaviour and the at least doubled message periodicity is easily detectable [4]. Upon detection, the targeted ECU might switch into a fallback mode, where it ignores both the original and the injected values. Secondly, the ECU might have safety margins built-in. For instance, most, if not all of the lane assist systems have a maximum steering angle it is allowed to perform in order to keep the car in the lane. If the attacker tries to induce a higher steering angle than this maximum value, the lane assist system might just deactivate. 2.1.2. Message Modification Attacks Message modification attacks are based on the idea that instead of injecting mes- sages, one could modify the message that is being sent. There are several safety measures in the CAN standard that makes it hard if not impossible to modify mes- sages transmitted by another ECU on-the-fly (e.g., CRC, bit stuffing, sender ECU monitoring the bus during transmission, etc.). Thus, until now, the easiest way to realize this attack was to compromise an ECU [10] and modify the messages before they are even sent. 2.1.3. Denial of Service (DoS) In a DoS attack, the attacker’s goal is to render a given CAN bus unusable, which can be achieved in two ways: by adhering to the CAN standard or by breaking it. The first option is to send as many messages to the CAN bus with the lowest possible ID as physically possible. When the bus is idle, if two or more ECUs want to transmit at the same time, the one with the lowest ID will have priority. Thus, since the zero ID has priority over every other message ID, none of the regular messages will win the arbitration against the injected message, which will lead to the starvation of the regular ECUs. The second method is to force the CAN_H and CAN_L wires into dominant state and hold it there as long as the attacker wants to. While the second method could be easier to implement, it triggers the error detection in the ECUs; thus, the connected subsystem will detect that there is an error with the CAN bus. On the other hand, the first solution does adhere to 118 the rules of the CAN, and the ECUs might only think that everything is okay with the CAN bus, except it is busy at the moment. Nonetheless, using both solutions, an attacker can render a given CAN bus unusable. 2.2. Attack Mitigations There are several proposed solutions to the issues mentioned in the previous section. However, while the following measures could increase the security of the CAN bus, they are more theoretical than practically applicable solution. 2.2.1. CANAuth As mentioned before, one of the biggest deficiencies of the CAN bus is that it lacks message authentication. CANAuth [5] solves this issue by using a symmetric key based HMAC. The main idea behind the CANAuth is the following. As described in section 3.1, every bit transmitted on the CAN bus get sampled at the 75% percentile point of the bit time to ensure a reliable sampling. However, technology has developed a lot since the introduction of the CAN bus, and microelectronics are much faster nowadays. Thus we could use a higher sampling rate in order to hide authentication data in the propagation segment of every CAN bit. 2.2.2. CAN Firewall Another mitigation method is to use firewalls [1]. By using a firewall, we can phys- ically split a CAN bus into multiple separate segments and control the traffic going between them. For instance, we can apply whitelist or blacklist-based message fil- tering on each of the different segments, introduce rate limiting, etc. Thus, we can limit the possibility of message injection and DoS attacks. Adding a CAN firewall to an existing car should not require redesigning the car, since the firewall itself is just a simple device with two CAN interfaces, which can be inserted between the separated CAN segments. While this solution could appear as the ultimate solution to the shortcomings of the CAN standard, it has several issues. For instance, we have to separate every important ECU or at least every important segment with a firewall, in order to be effective, which creates an excess cost for the manufacturer. An even bigger issue is the management of the firewall. Who gets to write the filtering rules? How are the rules updated, if an update is required? Who is responsible if an important packet gets dropped unintentionally? What if an airbag does not open during an accident due to a malformed firewall rule? While these edge cases could seem unimportant, not being able to address them satisfactorily may make manufacturers deciding not to use this technology. 2.2.3. Secure CAN Transceivers A third mitigation technique is the secure CAN transceivers [2] proposed by NXP. Their idea is to introduce a new firewall-like security defense layer at the CAN 119 transceiver level. Using this new layer, they can prevent message spoofing in both the transmitting and the receiving side; i.e., detect malicious ECUs and evade DoS attacks. 2.2.4. Mitigations in Practise Based on the mitigation techniques introduced in the previous subsections, we can say that while these mitigations are great theoretical results, and could more or less enhance the security of the CAN bus, we have to emphasize that they are still not widely used in practice, and thus, do not provide protection against current attacks. NXP’s Secure CAN transceivers could be the next easy to implement security measure, but our solution introduced in this paper could still circumvent it after a minor modification. 3. The ISO 11898 High-speed CAN standard The CAN bus [6, 7] is a broadcast, serial communication protocol used mainly in vehicles. It was designed to be robust, withstand high external RF noise, while providing a high-speed communication link between the ECUs. The CAN bus is a cost-effective solution because it enables the manufacturers to connect the ECUs by placing only one twisted pair cable between them. The CAN bus uses two wires called CAN high (CAN_H) and CAN low (CAN_L), in order to implement differential signalling. The cables are twisted pair cables. On each end of the cables, the wires are connected to each other using a terminating resistor in order to achieve a nominal 120 Ohm impedance. The CAN bus has two states, driven, and not driven. When it is not driven, the CAN_H and CAN_L wires get pulled to about the same 2.5V nominal voltage using the passive pull resistors placed in the CAN transceivers. This state is also called a “recessive” bit, which represents a binary 1. When the CAN bus is driven, at least one CAN node pulls the CAN_H wire to 3.5V and CAN_L wire to 1.5V nominal voltage. This state is also called a “dominant” bit, which represents a binary 0. 3.1. Bit Timing Every CAN bus has a nominal bitrate, which gets preconfigured in the ECUs by the car manufacturer. The maximum bitrate specified by the standard is 1 Mbps, but 500 kbps and 250 kbps is also frequently used bitrates. Every bit time can be divided into the following four segments (Figure 1): • synchronization segment (Sync_Seg): This segment is used for synchroniza- tion. At the SOF, every receiving ECU synchronizes itself to the edge of the first bit, which is called a “hard sync”. There is also another kind of synchronization called bit resynchronization, which is performed at the syn- chronization segment of each bit, by the ECU fine-tuning its inner clock based 120 on the deviance between the expected time of a potential edge, and the actual time of its detection. • propagation time segment (Prop_Seg): This segment is used to compensate for physical delay times within the network (e.g., signal propagation time, internal delay of the ECUs, etc.) • phase buffer segment 1 (Phase_Seg1) and Phase buffer segment 2 (Phase_Seg2): These segments are used for edge phase error compensation. The sampling of the bus occurs after the phase buffer segment 1. The length of these segments can be fine-tuned by resynchronization, and thus, the sampling point can be moved backward or forward. Nominal bit time Sync_Seg Prop_Seg Phase_Seg1 Phase_Seg1 Sample point Figure 1. The four segments of the bit time. 3.2. Frame Timing Messages can be transmitted based on events (e.g., receiving a remote frame, a sensor value triggering a transmission) or by a trigger coming from an internal timer. The internal timer method is called Time-Triggered Communication (TTC). During communication, after every frame’s EOF segment, there is a 3-bit long intermission period. After these 3 recessive bits, the bus is considered idle, and any following dominant is considered as the SOF of the next frame. When the ECUs detects that the bus is idle, any of them may start to transmit. If two or more ECUs happen to transmit at nearly the same time, the conflict between them is resolved using contention-based arbitration. 3.3. Contention-based Arbitration When a node starts to transmit a frame, it monitors the bus during the arbitration segment of the MAC frame in order to check whether the data on the bus is the same as it is transmitting. In case it detects that despite transmitting a recessive bit, the bus is still in dominant state, it knows that another ECU tries to transmit data, and it terminates the arbitration process and turns into a receiver. This allows the other ECU to transmit its message as nothing happened, and the other ECU that lost the arbitration, can retry sending its message at a later time. Using this method requires the bus has to adhere to three key elements: 121 • The ID of the message types has to be unique. • A data frame with a given ID and a non-zero Data Length Code (DLC) value may only be sent by one ECU. • The remote frame’s DLC value has to be the same as the data frame it requests. Using this contention-based arbitration ensures that the ECU with the higher priority frame will always win the arbitration, because its ID contains more domi- nant bits, than the other potential transmitter ECU frame’s ID. 4. Malicious CAN Gateway Since the CAN standard does not support message authentication, if we manage to insert a special device in the communication line between the two ECUs, then we can add, modify, or even delete messages with an arbitrary ID. The visualization of the attack can be seen in Figure 2. Figure 2. The concept of a MITM attack in the automotive industry. 4.1. Design In order to create a CAN gateway, we used NodeMCU ESP32s microcontrollers. ESP32 is a two-core, 240MHz versatile microcontroller, with a built-in CAN con- troller and Wi-Fi module. It comes with the Espressif IoT Development Framework (ESP-IDF), which is based on the popular Free Real-Time OS (FreeRTOS) plat- form. Using the ESP-IDF allows us to create a hard-real-time device using its built-in scheduler, while providing convenient features, for instance, a built-in web server, which is useful for device configuration. There were several requirements for the proof-of-concept malicious CAN gate- way: 122 • It should be able to handle ISO 11898 High-Speed CAN messages, with a bus speed of up to 1Mbps. • It should have as low introduced delay as possible, preferably low enough that it is not significantly greater than a lost arbitration or a transient error. • Despite being a proof-of-concept device: – It should be robust enough to be used later at least for research. – It should be easy to configure during testing, and configuration shall not require reprogramming of the device. – It should be as serviceable as possible, without requiring specific hard- ware knowledge. The components should be replaceable in case it is required. The first step of the design process was to create a high-level architecture of the CAN gateway, which can be seen in Figure 3. As one can see on the figure, the CAN gateway consists of two CAN transceivers, and two ESP32s microcontrollers. One of the microcontrollers is the master, and the other one is the slave. Each microcontroller handles one side of the CAN bus via its built-in CAN controller, and the corresponding CAN transceiver. The communication between the micro- controllers is realized via a UART line. The master provides a web interface for configuration through its 2.4GHz Wi-Fi module, working as an access point. Figure 3. High-level architecture of the CAN gateway. 4.2. Implementation After designing the schematics and verifying it on a breadboard, we have built a soldered version of the circuit. We used a protoboard as the base of the device, which allowed us to apply minor changes to the hardware design without having to rebuild the complete circuit again. The components have been soldered onto the protoboard using sockets in order to make a potential component replacement easier to achieve. A picture of the finished proof-of-concept CAN gateway board can be seen on Figure 4. 123 Figure 4. The top view of the proof-of-concept CAN gateway board. 4.3. Operation After powering up the device, it provides a web interface for configuration through its Wi-Fi access point, as we mentioned before, which is a key element in making the device usable for research purposes. This web interface allows the user to configure it using a simple web browser, or via direct POST request (e.g., using curl). The graphical web configuration interface of the device can be seen on Figure 5. Figure 5. The graphical web configuration interface of the CAN gateway. The configurable parameters are the following: • Bitrate: This parameter can set the bitrate of the CAN bus. 124 • Id: The id of the CAN message to be attacked. • Offset and AttackLength: The offset controls the position of the first byte to be attacked, and the attackLength determines how many bytes will be attacked. • ByteValue: Some of the attack types require an additional parameter, which will replace the original or will be added or subtracted from the selected byte values. • AttackType: There are several different attacks the device can perform: – Passthrough: In this mode, the device relays the traffic without modi- fying any of the messages. – Replace-data-with-constant-values: In this mode, the device re- places the selected bytes in the message with the given ByteValue pa- rameter. – Replace-data-with-random-values: In this mode, the device gener- ates random bytes for each of the selected bytes in the message, and replaces them. – Add-delta-value-to-data: In this mode, we add the given ByteValue parameter to each of the selected bytes in the message. In case the resulting values would overflow, it gets capped at the maximum 255 value. – Subtract-delta-value-from-data: Similar to the previous attack type, but the byte ByteValue is subtracted instead of added. In case the re- sulting value would underflow, it gets bounded at the minimum 0 value. – Increase-data-until-max-value: In this mode, we take the lowest value from the selected bytes, increase it by one and replace all of the selected bytes if the increased byte is higher than the original. This is repeated until the max value (0xff) is reached. – Decrease-data-until-min-value: This attack type is similar to the previous one, but at the start, we take the highest value from the selected bytes and decrease it every message, until we reach 0x00. – Replace-data-with-increasing-counter: We start a counter from 0 and increase it by one at every occurrence of the message. The selected bytes get replaced with the counter. The counter can overflow. – Replace-data-with-decreasing-counter: Similar to the previous at- tack type, but the selected bytes get replaced by a decreasing counter starting from 255, which can underflow. After the user sends the configuration via the graphical web interface or via a direct POST request, the device validates the configuration on the server-side, and if it is correct, it starts the attack phase. 125 5. Evaluation During the evaluation, we performed two tests. First, we created a testbed using a Raspberry Pi with a PiCAN shield; and a NodeMCU ESP32s with an additional CAN Transceiver as our CAN nodes. Later, we used a vehicle testbed built from actual vehicle components to verify the functionalities of our device in a close-to- real-world setting. 5.1. Raspberry Pi Testbed The nodes were configured to send messages to each other via the CAN bus; how- ever, they could only send these messages through the CAN gateway. The testbed can be seen on Figure 6. Figure 6. The CAN gateway testbed using a Raspberry Pi and a NodeMCU ESP32s. During the measurements, we tested all attack types, with different IDs, offsets, and attack lengths, while logging both the UART lines, as well as the messages on both sides of the gateway. As we found, the CAN gateway managed to modify the messages with an introduced delay of 260us on the 1Mbps CAN bus. This delay is only approximately 2.3 times longer than a lost arbitration, which could be caused by a busy bus or a short transient fault. One example of the tested attacks has the following parameters: • Bitrate: 1 Mbps • Id: 0x090 126 • Offset: 2 • AttackLength: 3 • ByteValue: 0x08 • AttackType: Replace-data-with-constant-values A screenshot of a measurement can be seen on Figure 7. There are two messages traveling on the bus at the same time: A→B: ID: 0x090, Data: 0x00 0x80 0x80 0x80 0x41 0x41 0x00 B→A: ID: 0x045, Data: 0x01 0xf2 0x03 0xf4 0x05 0xf6 0x07 0xf8 However, after both messages go through the CAN gateway, the targeted message with the 0x090 ID arrives with changed values. On the arriving side, the following messages are present: A→B: ID: 0x090, Data: 0x00 0x80 0x08 0x08 0x08 0x41 0x00 B→A: ID: 0x045, Data: 0x01 0xf2 0x03 0xf4 0x05 0xf6 0x07 0xf8 Thus, we can say that the CAN gateway has successfully modified the preconfigured part of the message. Figure 7. Simultaneous message transmission in both direction. 5.2. Vehicle Testbed After verifying that our attack worked in our local testbed, we tested the malicious CAN gateway on a Citroen C5 test bench, which contains the electronics of a real-life Citroen C5 (Figure 8). 127 Figure 8. The Citroen C5 test bench. We found a CAN bus connection point between the dashboard and the ECU, we connected the CAN gateway to this point. The attack we performed was to overwrite the tachometer value with a constant, and thus force the dash to show a modified engine rpm instead of the real one. The attack parameters were the following: • Bitrate: 250 kbps • Id: 0x208 • Offset: 0 • AttackLength: 1 • ByteValue: 0x30 • AttackType: Replace-data-with-constant-values As one can see in Figure 9, despite the engine idling at 810 rpm, the dashboard shows the modified values of around 1500 rpm. 128 Figure 9. The attack of the tachometer displays different rpm than the real one. 6. Conclusion In summary, the CAN bus, which is one of the most common communication solutions for ECUs, has several security flaws since security was not in focus during its development. There are no message authentication measures; the ECUs decide to act upon a message or not based only on the CAN ID field of the message. Hence, it is possible to inject fake messages, or modify existing messages on the CAN, and by doing that, to force some ECUs to act upon these fake messages, which may influence the vehicle’s overall behavior. While message injection attacks are easy to implement, they provide several side effects, making them almost trivial to detect. Message modification attacks are hard to realize and require a more profound knowledge of the field, but they are much less detectable. In this work, our goal was to design and implement a device, capable of modifying ISO 11898 high-speed CAN messages in real-time. Our CAN gateway device was designed to perform a Man-in-the-Middle attack by separating the targeted ECU and the rest of the CAN bus. Being in a man-in- the-middle position allows our device to modify the content of any message passing through the CAN gateway without any excess message or increase in the busload. It is capable of modifying CAN messages in real-time with a minuscule introduced delay of 260 𝜇s, without being detectable by current measures. It can handle up to 100% bus load with a bus speed of 500 kbps or less, and about 60-100% busload at 1 Mbps. The device is built from low-cost, commonly available parts, and it provides a wireless interface that can be used to remotely configure the attack parameters. 129 References [1] Arilou: Feasible car cyber defense, ESCAR, 2010. [2] B. Elend, T. Walrant, G. Olma: Securing CAN Communication Efficiently With Min- imal System Impact, NXP, 2020, url: https://www.nxp.com/docs/en/white-paper/SECURECARTRANA4FS.pdf. [3] E. Evenchick: Hopping On the CAN Bus, Black Hat Asia, 2015, url: https://www.blackhat.com/docs/asia-15/materials/asia-15-Evenchick-Hopping- On-The-Can-Bus.pdf. [4] A. Gazdag, D. Neubrandt, L. Buttyán, Z. Szalay: Detection of Injection Attacks in Compressed CAN Traffic Logs, in: International Workshop on Cyber Security for Intelligent Transportation Systems, Held in Conjunction with ESORICS 2018, Springer, 2018. [5] A. Herrewege, D. Singelée, I. Verbauwhede: CANAuth - A Simple, Backward Com- patible Broadcast Authentication Protocol for CAN bus, in: Jan. 2011, p. 7. [6] Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling, Standard, Geneva, CH: International Organization for Standardization, Dec. 2015. [7] Road vehicles — Controller area network (CAN) — Part 2: High-speed medium access unit, Standard, Geneva, CH: International Organization for Standardization, Dec. 2016. [8] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage: Experimental Security Analysis of a Modern Automobile, in: 2010 IEEE Symposium on Security and Privacy, 2010, pp. 447–462, doi: https://doi.org/10.1109/SP.2010.34. [9] C. Miller, C. Valasek: Adventures in Automotive Networks and Control Units, IOActive Labs Research, 2013, url: https://ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_ Control_Units.pdf. [10] C. Miller, C. Valasek: Remote Exploitation of an Unaltered Passenger Vehicle, IOActive Labs Research, 2015, url: https://ioactive.com/pdfs/IOActive_Remote_Car_Hacking.pdf. [11] H. M. Song, H. R. Kim, H. K. Kim: Intrusion detection system based on the analysis of time intervals of CAN messages for in-vehicle network, in: 2016 International Conference on Information Networking (ICOIN), 2016, pp. 63–68, doi: https://doi.org/10.1109/ICOIN.2016.7427089. [12] A. Taylor, N. Japkowicz, S. Leblanc: Frequency-based anomaly detection for the auto- motive CAN bus, in: 2015 World Congress on Industrial Control Systems Security (WCICSS), 2015, pp. 45–49, doi: https://doi.org/10.1109/WCICSS.2015.7420322. 130