DEVICE FOR SECURE COMMUNICATION BETWEEN CONTROL UNITS IN A VEHICLE, ELECTRONIC PROCESSING UNIT AND VEHICLE

Description

[0001] The invention relates to the technical field of cyber security in vehicles, especially commercial vehicles. In Vehicles are increasingly integrating electronic components that can exchange messages with each other. This is achieved through the creation of various communication networks, each equipped with gateways that connect these networks. These gateways perform format conversion, ensuring that messages in one communication network's format are converted to the format of another, and vice versa. This allows electronic components in one network to understand messages from different networks, and vice versa. However, in some cases, control units that heavily utilize the communication bus are networked in a separate branch, even though the same bus system is used, and no format conversion is required for this branch.The term "cybersecurity" is used to address various aspects of data security in the "digital age." This includes, among other things, network security. Here, the focus is particularly on defending against attacks on the communication network, both from within and outside the network. The potential attack vectors are as diverse as the networks themselves.

[0002] While attacks on stationary computer networks often aim to protect the confidential data stored there and prevent the introduction of malware, attacks on in-vehicle communication networks are primarily concerned with preventing the injection of falsified control and diagnostic commands. The vulnerability of in-vehicle communication networks was particularly strikingly demonstrated by a group of hackers who carried out a hacking attack on a vehicle while it was in operation in 2015. In this demonstration, falsified control commands were injected to manipulate the vehicle's BCM (Body Control Module). This resulted in the power windows being activated while driving and the windows being lowered at full speed. Even more serious attacks have also been carried out.The brakes were deactivated, as were the air conditioning, instrument cluster, infotainment system, and the steering was remotely controlled. Therefore, efforts are underway to secure the vehicle's communication networks.

[0003] US Patent 2013 227 648 A1 discloses the use of a gateway in a vehicle to defend against external attacks. Communication with the outside world is routed through this gateway, which is equipped with a firewall. The firewall can be an authentication method using a Public Key Infrastructure (PKI) to authenticate the communication partner, for example, based on a symmetric or asymmetric key exchange. The firewall can block the transmission of unauthenticated malicious information and can issue a warning message if malicious information has been transmitted.

[0004] US Patent 2019 268 376 A1 specifies the use of a gateway with a firewall for external data traffic and a gateway with a firewall for internal data traffic. The external gateway's firewall secures data traffic with communication partners outside the vehicle. All incoming messages are inspected and forwarded to the internal gateway. All messages originating from electronic control units (ECUs) within the vehicle and intended for external transmission are also inspected by the external gateway's firewall. The internal gateway can then transmit the information received from the external gateway to an internal ECU via an internal network or facilitate communication between different internal ECUs. In this case, the internal gateway is used solely for security verification.

[0005] US patent 2014 226 673 A1 specifies that the vehicle's onboard gateway device should have a connection for a workshop diagnostic tester. This gateway device also serves to authenticate the diagnostic tester when establishing a connection between it and the vehicle, and, if authentication is successful, to transmit the communication between the diagnostic tester and the vehicle's onboard systems. This gateway device is also equipped with a firewall.

[0006] The methods used to forge messages containing control commands or sensor data in the automotive sector are closely linked to the communication protocol used to transmit such messages. By far the most widely used communication protocol in vehicles is the CAN bus communication protocol. CAN bus, short for Controller Area Network, has been used in vehicles since 1991. The CAN bus communication protocol was standardized in 1994, and the ISO standard is ISO 11898. Later, further variants of this bus system were standardized. However, this CAN bus communication protocol is vulnerable to attacks based on message injection. Such attacks are also known as "spoofing." The term "spoofing" refers to the falsification of sender addresses to conceal the origin of packets.

[0007] However, the CAN bus communication protocol does not transmit sender addresses. Injecting messages would be possible, though, if an attacker managed to gain logical access to the bus line. The CAN bus uses a twisted-pair cable without shielding as its physical transmission medium. If an attacker succeeds in connecting their manipulated device to this bus line, it is easy to inject additional (manipulated) messages. This would also be possible, as demonstrated in 2015, if messages were injected via the so-called air interface. This is an on-board communication module used for external communication. It could be a 5G, LTE, or Wi-Fi modem, etc. Typically, the air interface is connected to a gateway module, which is connected to one or more of the vehicle's communication buses.

[0008] This vulnerability of the CAN bus system has recently been addressed by the development of secure CAN transceivers.

[0009] Such a CAN transceiver is known from EP 3 148 154 B1. It employs a monitoring module that checks whether the identifier of a received CAN message matches an identifier reserved for the bus station. This verifies whether the uniqueness rule for CAN message identifiers valid on the CAN bus is being violated. If a violation of the uniqueness rule is detected, an attack on the bus system is inferred, and the received CAN message violating the uniqueness rule is invalidated immediately upon reception. This is done by sending an error flag in the end-of-frame field of the received CAN message. If the other bus stations detect the error flag, they must discard the received message as invalid.Therefore, any control command contained in the message will not be executed, and the message can no longer cause any harm.

[0010] WO 2020 187 985 A1 contains an extension for secured CAN transceivers, which proposes further countermeasures.

[0011] One problem, however, is that series-produced automotive products are typically developed for a period of 10 to 15 years. This means that control units without a protected CAN transceiver are still being used in new vehicles. These remain vulnerable to tampering. This is especially true for commercial vehicle manufacturers, who use long-term product generations. Product cycles in this sector can easily exceed 15 years.

[0012] German patent DE102011084254A1 discloses a firewall solution for vehicle communication networks. It is a separate component that is connected outside of an electronic control unit (ECU) but does not include a gateway function.

[0013] Document DE102017202022A1 describes a solution in which the various control units are arranged in different security zones. These different security zones are separated from each other by a so-called domain control device. However, this domain control device does not have the additional features of a gateway, firewall functionality, and secure CAN communication. Instead, it is an add-on component housed in a separate enclosure and must also be integrated into the network.

[0014] Document US2018205703A describes so-called gateway / firewall components that are located between the vehicle bus (SAE J1939) and other communication buses within the vehicle. These components filter out malicious messages that reach the vehicle from outside via these other vehicle communication buses. However, the gateway / firewall components are additional components that are not integrated into a control unit.

[0015] However, legislators have now stipulated that from 2024 onwards, no new vehicles may be registered in the EU that do not comply with the UN-ECE R155 directive. This directive requires vehicle manufacturers to implement countermeasures against cyberattacks in their vehicle network architectures. Similar measures must be taken by the relevant UN-ECE member states in other regions of the world.

[0016] While all suppliers and commercial vehicle manufacturers will strive to offer maximum security against known cyberattacks, it is not a realistic scenario that new product generations will be developed, tested, and certified for all electronic control units, sensors, and actuators used in commercial vehicles by 2024, and that production facilities will already be converted to these new product generations by then. Furthermore, adapted network architectures will also need to be developed, tested, and produced for the new electronic components.

[0017] While it is possible to defend against external attacks via the air interface using a specially developed, highly secure gateway device, this does not apply to internal attacks, where an attacker gains access to the bus line and connects a manipulated electronic device. Such attacks are particularly likely in the commercial vehicle sector, as these vehicles travel long distances and cannot be parked overnight in secure depots. Furthermore, tampering with trailers is even easier. They also contain electronic components, such as brake control units, sensors, and actuators, which are connected to a so-called trailer CAN bus. When coupled to the towing vehicle, this bus connects to the towing vehicle's T-CAN port, thus establishing a connection to the towing vehicle's vehicle bus.If a manipulated electronic device is connected to the trailer CAN bus, it can inject manipulated messages onto the vehicle bus of the towing vehicle. Using an additional gateway device to defend against such injected messages is possible, but significantly increases costs.

[0018] There is therefore a need for alternative security measures that can be used, at least for a transitional period, and that comply with the criteria of the UN-ECE R155 directive. The invention aims to provide an effective alternative solution that enables the use of a mix of electronic components from existing product generations and secured electronic components from newer product generations in an adapted network architecture. This solution should also achieve the goal of reliably detecting unauthorized bus access and preventing the manipulated messages from causing damage.

[0019] The object of the invention is therefore to find a network architecture for the use of an electronic device not yet equipped with a secure CAN transceiver or Secure Onboard Communication (SecOC) that meets the requirements of the applicable UN-ECE R155 directive.

[0020] This task is solved by a device for secure communication between control units in a vehicle according to claim 1, by an electronic control unit according to claim 7 and a vehicle according to claim 19.

[0021] The dependent claims include advantageous further developments and improvements of the invention in accordance with the following description of these measures.

[0022] In In one embodiment, the invention relates to a device for secure communication between control units in a vehicle, wherein the control units are each equipped with at least one communication interface via which they can be connected to a first part of a wired vehicle bus system for exchanging messages. At least one secure control unit is provided, which is connected to the vehicle bus system. According to the specific network architecture, this secure control unit is provided with at least one further communication interface to which a part of the vehicle bus system is connected, to which at least one control unit is connected that does not include any defense measures against injected messages.The secured control unit is equipped with a gateway function and security features that at least function as a firewall, preventing attacks originating in the first part of the vehicle bus system from targeting the control units in the isolated section of the vehicle bus system. This solution has the advantage that so-called legacy control units, which are not yet equipped with a secured CAN transceiver or Secure Onboard Communication, remain usable. While they are vulnerable to injected messages, they are protected by the presence of an already secured control unit that intercepts and neutralizes messages injected in the first part of the vehicle bus system. This allows for the use of a mix of secured and vulnerable control units within a single vehicle communication bus system, while still meeting the cybersecurity requirements stipulated in the directive.This solution also offers the potential for cost savings, as it eliminates the need for an additional, separate gateway device to protect legacy ECUs. Instead, this task is handled by a newly developed ECU equipped with a secure CAN transceiver. However, this ECU must have sufficient processing power to also perform the gateway and firewall functions.

[0023] The gateway function of the secured control unit advantageously relates in particular to the routing of messages between the participants in the first and second parts of the vehicle bus system.

[0024] The advantages of the invention are particularly evident when the wired vehicle bus system corresponds to a CAN bus system, specifically a Controller Area Network, particularly the variant based on the SAE J1939 standard. The problem of vulnerability to injected messages is especially pronounced here because CAN messages are sent in content-addressed form. This means that the messages are not labeled with sender and destination addresses, which would make it easier to detect injected messages. Instead, a so-called message identifier is sent at the beginning of the message, which also indicates the message content. All stations in the CAN bus system can use this to determine whether they need the message. However, control units not equipped with protected CAN transceivers cannot use this information to distinguish whether the message was injected or actually sent by the original control unit.

[0025] It is therefore advantageous that the control units in the first part of the vehicle bus system are equipped with a secure CAN bus communication interface. This secure CAN bus communication interface is designed to detect and neutralize messages injected by a manipulated control unit in the first part of the vehicle bus system. Secure CAN transceivers of this type are already available on the market for this purpose. The Stinger type CAN transceivers from NXP Semiconductors NV are one example. It is also possible to secure the communication with an additional software stack that supports Secured Onboard Communication (SAT).

[0026] In In one embodiment of the invention, the protected control unit is an EBS brake control unit, corresponding to "Electronic Braking System," and the at least one control unit (legacy control unit) relocated to the other part of the vehicle bus system relates to a driver assistance system control unit or an environmental sensing system control unit, to which at least one environmental sensing sensor such as a camera, radar, lidar, ultrasound, or IR camera is connected. Two or more legacy control units can also be arranged in the second part of the vehicle bus system. This has the advantage that several control units from an older product generation can be reused.

[0027] In another embodiment, the invention relates to an electronic control unit with a first communication interface via which the control unit can be connected to a first part of a wired vehicle bus system for exchanging messages. This control unit is characterized in that it has at least one further communication interface to which a separate part of the vehicle bus system can be connected, wherein the control unit is provided with a gateway function and security features that at least fulfill the function of a firewall, for the purpose of defending against attacks from the first part of the vehicle bus system on one of the control units in the unsecured part of the vehicle bus system. With a control unit thus equipped, the particular network architecture as described in the first embodiment of the invention can advantageously be implemented.

[0028] To further secure the vehicle bus system, it is advantageous for the security features for the electronic control unit to also include a secure boot process. This measure monitors each step of the boot process. It even makes it possible to ensure that only the cryptographically signed bootloader is started in the control unit, for which the certificates are stored in the hardware security module. These certificates are securely stored there and protected against manipulation. This allows, for example, malicious bootloader programs that have been subsequently loaded into the control unit through manipulation to be blocked.

[0029] The gateway function of the control unit should advantageously relate to the routing of messages between the participants in the first and the separated part of the vehicle bus system.

[0030] It is particularly advantageous if the first and at least one subsequent communication interface of the electronic control unit (ECU) corresponds to a CAN bus communication interface, i.e., a Controller Area Network, specifically designed according to the SAE J1939 standard. As described, the CAN bus is vulnerable to attacks via injected messages. Therefore, it is all the more important to equip the ECU with security features specifically designed for this type of communication bus.

[0031] In this regard, it is very advantageous that the CAN bus communication interface for connection to the first part of the vehicle bus system is equipped with a secure CAN transceiver, which can defend against attacks based on injected messages from a manipulated control unit in the first part of the vehicle bus system. As described, such secure CAN transceivers are available on the market.

[0032] Another advantage is that the security features still include a certificate-based authentication function for an external diagnostic tester connected to a control unit or gateway device of the first part of the vehicle bus system. This is essential to prevent malware from being loaded onto the control unit using a manipulated diagnostic tester.

[0033] For the same purpose, it is advantageous if the security equipment even includes an HSM module (Hardware Security Module) to ensure secure authentication of at least the external diagnostic tester connected to a control unit of the first part of the vehicle bus system. The HSM module can securely store keys and certificates used for authentication. Furthermore, the HSM module can contain a processing unit required to securely execute cryptographic calculations such as hash algorithms, key derivations, encryption and decryption algorithms, signature calculations, random number calculations, authentication and identification calculations, etc.

[0034] While the secured control unit can authenticate the diagnostic tester using strong certificate-based authentication, this is not possible for the legacy control unit located in the isolated part of the vehicle bus system, as it lacks the necessary algorithms, let alone an HSM module. In this case, it is advantageous that the security features of the secured control unit still function as a diagnostic client control unit, enabling "seed key" authentication of a control unit connected to the isolated part of the vehicle bus system for executing diagnostic functions that are triggered by communication with the certificate-verified external diagnostic tester.This also makes it possible to read the fault memory entries in the legacy control units using the diagnostic tester, because the secured control unit supports these diagnostic functions after secure authentication of the diagnostic tester.

[0035] In a further embodiment of the invention, it is advantageous that the safety equipment also has the function of preventing certain diagnostic commands received from the external diagnostic tester, which are classified as dangerous and are directed to the control unit under test in the unsecured part of the vehicle bus system. Such dangerous diagnostic commands are, in particular, commands relating to reading and writing memory areas of the control unit under test that are allocated for the execution of computer programs or for the permanent storage of computer programs in non-volatile memory areas.

[0036] In a particularly secure embodiment of the invention, the safety equipment further includes the function of verifying incoming diagnostic commands, individually or in groups, by repeatedly performing the certificate-based authentication of the external diagnostic tester before the relevant diagnostic command is forwarded to the control unit under test in the unsecured part of the vehicle bus system. However, this has the disadvantage of increasing the time required to perform the test.

[0037] Additionally, the security features in the protected control unit can still include the function of a secure software update process, allowing the replacement of computer programs stored in the non-volatile memory area. This measure can, for example, involve ensuring that the computer program to be loaded is provided with a digitally signed hash code, which is verified in the control unit before the program is written to the non-volatile memory. Otherwise, this software update option should be disabled, as it would otherwise be possible to load malware into the non-volatile memory area.

[0038] Three possible variants of the realization of the invention consist of providing a brake control unit EBS, corresponding to "Electronic Braking System", or a control unit for a distance control system or a control unit for an automatic driving system with the safety equipment according to the invention.

[0039] Another embodiment of the invention consists of a vehicle with a drive unit and an electronically controlled braking system, which includes a device according to the invention.

[0040] Exemplary embodiments of the invention are shown in the drawings and are explained in more detail below with reference to the figures.

[0041] They show: Fig. 1 shows a towing vehicle and a semi-trailer ready for collection; Fig. 2 shows a first block diagram for the electronic equipment of a towing vehicle; Fig. 3 shows a block diagram for the electronic equipment of a semi-trailer; Fig. 4 shows the principle of networking electronic components using a CAN bus; Fig. 5 shows the format of a standard data frame for transmitting a message on the CAN bus; Fig. 6 shows the message format for transmitting a message according to the UDS diagnostic protocol; Fig. 7 shows a diagram illustrating the message exchange between the participating control units during the process of performing a diagnostic test of a legacy control unit with a diagnostic tester connected to the vehicle network; and Fig. 8 shows a second block diagram for the electronic equipment of a towing vehicle.

[0042] The present description illustrates the principles of the inventive disclosure. It is therefore understood that those skilled in the art will be able to design various arrangements which, although not explicitly described here, embody principles of the inventive disclosure and which are also intended to be protected in their scope.

[0043] Fig. 1 Figure 1 shows a towing vehicle 20 aligning itself with a trailer 10 ready for pickup. The term "trailer 10" here refers to a trailer equipped with a coupling system for a towing vehicle 20. These are primarily commercial vehicle trailers. They are often semi-trailers with a coupling system in which a kingpin of the trailer 10 is inserted into a fifth wheel 22 of the towing vehicle until it engages, creating a rotatable connection between the towing vehicle 20 and the trailer 10. However, other types of trailers are also possible, such as those used in agriculture or those towed by construction vehicles. Larger caravans, as well as recreational and sports trailers, are also included.

[0044] The towing vehicle 20 can be a typical towing vehicle 20. It is primarily a commercial vehicle. However, other towing vehicles are also possible. Further examples include towing vehicles used in agriculture, construction vehicles, and recreational vehicles. Finally, it should be noted that this list is not exhaustive. Passenger cars can also be used as towing vehicles and can likewise be equipped with the subject matter of the invention. Again, the term "towing vehicle" is used here only as an example. The invention can also be used in other vehicles that are not typically used as towing vehicles. These include buses, construction and harvesting machinery, as well as motorcycles, robots, aircraft, and drones.

[0045] The towing vehicle 20 is equipped with a drive unit 24, which, in the depicted form, corresponds to an internal combustion engine. Of course, other types of drive units can also be integrated into the towing vehicle. Electric motors and fuel cells are mentioned as further examples. The service brakes 26 on the wheels of the towing vehicle 20 are also highlighted.

[0046] Fig. 2 Figure 20 shows the structure of an exemplary vehicle electronics system of the towing vehicle. The electronic control units of a powertrain (PT) and the electronic control units of a driver assistance system (DA) are shown. Additionally, a gateway (PU1) with connected on-board communication devices (KU1 and KU2) is shown. The on-board communication device (KU1) can be configured as an LTE or 5G modem or as a WLAN module. It handles communication with devices connected to the internet or another public communication network. It also handles data traffic to other vehicles (V2V communication, also known as vehicle-to-vehicle communication) and to stationary infrastructure devices (V2X communication).For communication with other vehicles, the so-called "Sidelink" communication capability of the LTE modem or the so-called "PC5" communication capability of the 5G modem can be used. V2X communication, corresponding to vehicle-to-everything communication, can also be handled via a WLAN module.

[0047] The on-board communication device KU2 supplies the tractor unit 20 with telematics data. This includes, for example, familiar applications from the logistics sector, such as toll collection, but also data used for traffic management. It could, for example, be a GSM module. A connection T1 for a workshop diagnostic tester T1 is also connected to the central gateway PU1. Further electronic components can also be connected to the central gateway PU1, which are located in the Fig. 2 Not shown in the diagram. The electronic components of an infotainment system are given as an example. These include, for example, the navigation system, radio, telephone, and a touchscreen display for operation and information for the driver. A so-called body control module can also be connected to the PU1 gateway. This module serves to receive and implement the various settings of driver-operated components. Examples given here include the windshield wipers, windshield washer system, door locks, various lights and turn signals, power windows, seat adjustment motors, air conditioning, etc.

[0048] The PT powertrain includes various electronic control units. Block CU1 designates an electronic engine control unit. Block CU2 designates an automatic transmission control unit. Block CU3 designates an electronic control unit for the retarder unit. This unit assists braking and prevents the friction brakes 26 at the wheels from overheating. Block CU4 designates an electronic brake control unit (EBS), corresponding to "Electronic Braking System." The reference number 26 designates one service brake per wheel. Each service brake 26 can be actuated separately by the electronic brake control unit CU4. For this purpose, the corresponding brake lines 25 are connected to the electronic brake control unit (EBS).

[0049] The reference sign DA marks a driver assistance system string in the Fig. 2 Block CU5 is an electronic control unit of an ADAS (Advanced Driving Assistance System). This adaptive cruise control system automatically maintains a safe distance from the vehicle ahead. It measures the distance and sends control commands to the powertrain control units to brake the vehicle if the distance decreases or to accelerate if the distance increases. A key feature of the CU5 electronic control unit is its integrated radar sensor for measuring the distance. In another embodiment, the CU5 control unit can be equipped without an integrated radar sensor. In this case, the radar sensor, like the SU1 camera shown, would need to be connected to the CU5 control unit. The SU1 camera serves as an additional sensor for environmental perception.It can help to identify objects in the surroundings more precisely. This can also help determine whether the measured distance values ​​are reliable. If a stereo camera is used, it can also be used for distance determination. This also offers the possibility of increasing the accuracy of the distance measurement. The electronic control unit CU5 can include a processing unit for this purpose, which performs sensor fusion with the distance values ​​provided by the radar sensor and the distance values ​​provided by the stereo camera SU1. The reference designation SU2 refers to a steering angle sensor. This is mounted on the steering system but is also connected to the driver assistance system via an additional cable, so that the driver assistance system can determine the distance more accurately when cornering.

[0050] The electronic control units CU1 to CU4 and the gateway module PU1 are networked via a bus system B1. A bus system designed for in-vehicle communication can be used for this purpose. Serial bus systems are typically used because they require the least amount of wiring. A CAN bus system (Controller Area Network) is one possible example. There are different versions of the CAN bus system, such as CAN Low Speed ​​and CAN High Speed, for different data rates of 125 kbit / s and 1000 kbit / s. Furthermore, an extended CAN bus has been specified under the name CAN-FD bus, where FD stands for "Flexible Data Rate." This specification defines an extended data frame with higher transport capacity, in which the payload area is larger. The bus architecture is described in Fig. 2 The bus B1 is represented as using a common bus line. Each device connected to this bus B1 is equipped with a communication interface IT1. If the bus system involves the CAN bus, a communication interface IT1 for the CAN bus is used accordingly.

[0051] Typically, the B1 bus system is implemented as a CAN bus and referred to as the vehicle bus. The vehicle bus is a specific CAN bus, designed according to the SAE J1939 standard. SAE standards are published by the SAE organization, the Society of Automotive Engineers.

[0052] The gateway module PU1 is also equipped with the IT1 communication interface. For communication with the on-board communication device KU1, the gateway device PU1 is equipped with an IT4 communication interface. For communication with the on-board diagnostic interface T1, the gateway device PU1 is equipped with an IT5 communication interface. For communication with the telematics unit T1, the gateway device PU1 is equipped with an IT6 communication interface.

[0053] Components CU5, SU1, and SU2 of the driver assistance system DA are networked via communication bus B1'. This communication bus B1' can also be a CAN bus. Alternatively, it can be a CAN FD bus. The electronic control unit CU4 is equipped with an additional communication interface IT2 for this purpose. Components CU5, SU1, and SU2 are also equipped with communication interface IT2. If bus B1' is also implemented as a CAN bus, communication interface IT2 is likewise designed as a CAN bus interface. A further communication bus B2 is connected to the electronic control unit CU4. This is connected to a connector T2. When a trailer 10 is coupled, this connector serves to receive the corresponding plug of the trailer 10's communication bus. The electronic control unit CU4 is equipped with communication interface IT3 for this purpose.Bus B2 can also be implemented as a CAN bus, so the IT3 communication interface could also be designed as a CAN bus interface. The CU4 electronic control unit is equipped with a gateway function (GWF) and security features (SE). These consist of a hardware security module (HSM), a firewall (FW), a secure boot loader (SBS), and a secure update loader (SUS). As already mentioned, the HSM module serves to securely store cryptographic information such as passwords, key information, and certificates, and to securely execute cryptographic calculations, such as calculating a key based on seed key information (e.g., in the Diffie-Hellman key exchange method), calculating a hash value, and performing encryption or decryption algorithms, etc.The HSM module is secure against manipulation because it is implemented with hardware and cannot be reprogrammed.

[0054] The firewall's (FW) task is to monitor data traffic across the various communication bus ports. The firewall is implemented in software and serves to restrict network access. It monitors the data traffic passing through the firewall and decides, based on predefined rules, whether certain network packets are allowed through or not. In this way, it attempts to prevent unauthorized network access. The number and type of predefined rules are crucial in determining the level of security that can be achieved. Further details on the use of the security equipment (SE) are described below. Fig. 6 explained in more detail.

[0055] The Fig. 3 Figure 1 shows a block diagram of the electronic system of a trailer 10. Reference numeral CU6 denotes a brake control unit for the trailer 10. This unit controls the service brakes 26' of the trailer's wheels in the same way as brake control unit CU4. However, brake control unit CU6 is designed as a legacy control unit and therefore does not include the safety features of control unit CU4 or a gateway function. The brake lines of the trailer 10 are designated by reference numeral 25'. Reference numeral B2 denotes the communication bus of the trailer 10. T2' denotes the connector for insertion into the T2 socket of the B2 bus of the towing vehicle 20. This connector is plugged into the T2 socket of the B2 bus of the towing vehicle 20 when the trailer 10 is coupled. Typically, the B2 bus is also designed as a CAN bus.The brake control unit CU6 is therefore equipped with a communication interface IT3, which can also be a CAN bus interface.

[0056] Fig. 4 This diagram illustrates the principle of networking electronic components using a CAN bus. A CAN network is a system comprised of CAN nodes (electronic components (control units, sensors, actuators) with CAN interfaces) that exchange data with each other via their respective CAN interfaces and a transmission medium (bus line) connecting all CAN interfaces. Three CAN nodes (100) are shown. The bus structure of the CAN bus is linear. Therefore, there is a bus line (150) to which all three CAN nodes (100) are connected. In most applications, a twisted, unshielded two-wire cable (unshielded twisted pair - UTP) is used as the bus line (150), enabling symmetrical signal transmission. In symmetrical signal transmission, the signals are transmitted as voltage differences across two lines. The wire pair consists of a non-inverted CANH signal and an inverted CANL signal.The receivers reconstruct the original data signal from the difference between the signals present on these two conductors. This has the advantage that common-mode interference occurring on both conductors of bus line 150 is canceled out by the difference calculation and thus does not affect the transmission.

[0057] To prevent signal reflections, the bus line 150 is terminated at both ends with a terminating resistor RT equal to the characteristic impedance of the bus line (120 ohms). A CAN interface consists of two parts: the communication software and the communication hardware. While the communication software encompasses higher-level communication services, the basic communication functions are typically implemented in hardware. Two hardware components are distinguished here: The CAN controller 140 ensures the uniform execution of the CAN communication protocol, thereby relieving the host 160, on which the aforementioned communication software runs, of this task. The CAN transceiver 120 connects the CAN controller 140 to the CAN bus 150. It shapes the signals for data transmission during the sending process and performs signal conditioning during reception.

[0058] The Fig. 5 shows the format of a standard data frame for transmitting a message on the CAN bus.

[0059] The ISO 11898-1 transmission frame contains many different individual bits that serve control purposes. The various fields and control bits of the transmission frame are listed with their English names in the following table. The length of each field is also given. Table 1 Control Bit Ausführliche Bezeichnung Länge SOF Start of Frame 1 Bit Identifier Identifier 9 Bits RTR Remote Transmission Request 1 Bit IDE Identifier Extension 1 Bit r Reserved Bit 1 Bit DLC Data Length Code 4 Bit Data Field Data Field 0-8 Bytes CRC CRC Sequence 15 Bit DEL CRC CRC Delimiter 1 Bit ACK Acknowledge 1 Bit DEL ACK ACK Delimiter 1 Bit EOF End of Frame Code 4 Bit

[0060] A CAN frame contains a Start-of-Frame (SOF) field, an Arbitration field, a Control field, a Data field, a Cyclic Redundancy Check (CRC) field, an ACK field, an End-of-Frame (EOF) field and an Intermission Sequence (ITM) field.

[0061] The SOF field is a field that indicates the start of a CAN frame, i.e., the beginning of a message. The arbitration field identifies a message and assigns it a priority. Based on the length of an identification field associated with it, the CAN frame is divided into a standard format and an extended format (the standard format is shown). In the standard format, the arbitration field has a length of 11 bits. For the extended format, the length of the identification field in the arbitration field is 29 bits.

[0062] The identifier determines the priority of the data frame and, together with the acceptance filtering, ensures the sender-receiver relationships defined in the communication matrix within the CAN network. The communication matrix specifies which messages each electronic control unit (ECU) processes. Therefore, if a message arrives whose message identifier is not listed there, this message is filtered out by the acceptance filtering and not forwarded to the application. Simultaneously, the aforementioned uniqueness rule must also be observed for the CAN bus. This rule stipulates that a message identifier is reserved for a message from a specific ECU type and may not be reused for a different message from a different ECU.

[0063] The RTR bit informs the receivers of the frame type (data frame or remote frame). A dominant RTR bit indicates a data frame, and a recessive bit indicates a remote frame. Additionally, the arbitration field can contain a 1-bit Identification Extension Field (IDE) to identify whether a frame is in the standard or extended format. A value of 0 indicates the standard format, while a value of 1 indicates the extended format. The DLC field displays the number of payload bytes in the message. These payload bytes are transported in the data field. A maximum of eight payload bytes can be transmitted in a single data frame. To protect against transmission errors, the payload bytes are protected by a 15-bit checksum transmitted in the CRC field, using a cyclic redundancy check.Based on the result of the CRC check, the receivers in the ACK slot acknowledge receipt either positively or negatively. An ACK bit is transmitted at the end of the message by the CAN controllers that have received the message correctly. The station that sent the message checks whether the ACK bit is present on the CAN bus. If ACK is not found, this indicates that a station could not receive the message correctly, and the sending station can attempt to retransmit it. The transmission of a data frame is terminated with seven recessive bits, which corresponds to the End Of Frame (EOF) code.

[0064] The following is an example of a diagnostic procedure when an external diagnostic device DT is connected to the on-board electronics of the towing vehicle 20, based on the Fig. 6 explained. The electronic control units involved are listed in the top row of the Fig. 6 The following components are shown and labeled with the corresponding reference numerals: the onboard diagnostics interface (OBDI), which may be contained in connector T1; the processing unit (PU1, gateway device); the brake control unit (CU4); and the electronic control unit (CU5), which is equipped with a radar sensor and performs distance control to vehicles ahead. In the first step (S1), the connected diagnostic test device (DT) sends a message to the onboard diagnostics interface (OBDI) to initiate a diagnostic session. The entire diagnostic session follows the diagnostic communication protocol according to ISO standard 14229. Therefore, this standard is expressly referenced with regard to the disclosure of the invention. This diagnostic protocol is also known as the Unified Diagnostic Service Protocol (UDS service). For the purpose of explaining the invention, particular reference is made to variant ISO 14299-1 in the 2020 version.In this variant, the opening of the diagnostic session is secured with a certificate. The message for opening the diagnostic session contains the certificate with which the diagnostic device DT authenticates itself. This certificate confirms that the certificate holder is authorized to use the diagnostic tester and possesses both the necessary public and private keys for secure communication. The public key is visible in the certificate, while the private key is embedded but encrypted. The address of the control unit to be tested is also included. In the example shown, the address of control unit CU5 is specified in the UDS message. This is therefore a legacy control unit that does not include any additional security features. The onboard diagnostic interface (OBDI) receives the ODS message and forwards it to the processing unit PU1, i.e., the gateway device.

[0065] The diagnostic protocol should ideally be supported by all electronic control units (ECUs) installed in a vehicle. This makes it possible to test and maintain these ECUs. The diagnostic services operate at a different level than, for example, the CAN protocol, which itself only uses the first layer (the physical layer) and the second layer (the data link layer) of the OSI reference model for data communication. The UDS service itself can be assigned to parts of the session layer and parts of the application layer of the OSI model. A diagnostic message always has a uniform structure and is divided into a SID field (service ID), a parameter field, and a data field. This message format is used in the Fig. 7 The SID field has a fixed length of 8 bits. The parameter field has a length of 16 bits. The UDS standard allows messages with a data field of any length. The maximum size is therefore determined by the transport protocol used to transmit the UDS messages. For example, the commonly used ISO transport protocol according to ISO standard ISO 15765-2 allows messages up to 4095 bytes in length.

[0066] Communication based on the diagnostic protocol operates on a request-response principle. This allows service requests defined in UDS to be sent to the control units, which must support the specified UDS services. The diagnostic tester initiates the service by sending a request to the control unit, which then sends back a positive or negative response upon completion. If the service execution takes longer than the specified runtime, the control unit must send a preliminary response (requestCorrectlyReceived-ResponsePending) at regular intervals. This confirms receipt of the request but indicates that execution is still ongoing. This makes it possible, for example, to query and reset the fault memory of individual control units. Another UDS service involves, for example, updating the firmware of a control unit.

[0067] The UDS standard, specifically ISO 14229-1 (2018), defines 27 service requirements. These diagnostic messages (request and response messages) are transmitted in the payload field at the data link layer of the CAN protocol when communication is routed over a CAN bus. If the UDS message is based on the standard or extended CAN bus protocol at lower layers, a protocol stack must be installed on the diagnostic tester and the participating control units. This stack ensures that the data fields of several CAN bus messages are collected at the transport layer until the complete UDS message has been transmitted. The participating control unit or diagnostic tester can then evaluate the UDS message.

[0068] The following diagnostic service requirements are specified in the UDS standard ISO 14229-1 (2018), see Table 2. Table 2 SID Service SID Service 0x10 Diagnostic Session Control 0x31 Routine Control 0x11 ECU Reset 0x34 Request Download 0x14 Clear Diagnostic Information 0x35 Request Upload 0x19 Read DTS Information 0x36 Transfer Data 0x22 Read Data by Identifier 0x37 Request Transfer Exit 0x23 Read Memory by Address 0x38 Request File Transfer 0x24 Read Scaling Data by Identifier 0x3D Tester Present 0x27 Security Access 0x3E Write Memory by Address 0x28 Communication Control 0x83 Acccess Timing Parameters 0x29 Authentication 0x84 Secured Data Transmission 0x2A Read Data by Periodic Identifier 0x85 Control DTC Setting 0x2C Dynamically Define Data by Identifier 0x86 Response on Event 0x2E Input Output Control by Identifier 0x87 Link Control 0x2F 0x7F Negative Response SID

[0069] In the example shown from Fig. 6 In step S2, the gateway device PU1 receives the opening message from the diagnostic interface T1. This message corresponds to the UDS message with SID 0x29. It initiates the authentication phase for the diagnostic tester DT. The gateway device PU1 then evaluates the complete UDS message. Based on the control unit address of the control unit CU5 under test, which is contained within the message, the gateway device PU1 forwards the message to the connected communication bus B1. The UDS message is converted into a multitude of CAN messages, which are transmitted via the CAN bus B1. The gateway device PU1 is designed for this type of conversion. In step S3, the opening message is received from the protected brake control unit CU4 as a number of CAN messages. As previously described, the brake control unit CU4 is equipped with a gateway function GWF and additional safety features SE.The gateway function GWF contains the list of CAN message identifiers relevant to the control units located in the isolated section B1'. When such a message arrives at the brake control unit CU4, it is first checked by the protected CAN transceiver. If it is determined to be an injected message, it is immediately neutralized. This can be done, as described earlier, by sending an error flag. Additionally, the allowed messages are checked by the firewall FW. This check takes place in steps S4 and S5 after the UDS message for opening the diagnostic session has been received. In step S4, the certificate contained in the UDS message is verified for authenticity. The HSM module HSM is also used for this purpose. If the authenticity of the certificate is not verified, the diagnostic session is not opened.In step S5, the control unit information transmitted in the UDS message, including address and type, is checked. If an address or other type of the addressed legacy control unit is specified here, the diagnostic session is not opened. Thus, the firewall FW, in conjunction with the HSM module and the secured CAN transceiver, prevents spoofing attacks, for example.

[0070] If the diagnostic tester's request with certificate was verified and the underlying CAN messages were not detected as tampered with, the correctness of the verified certificate is confirmed after step S5. First, the secured brake control unit CU4 sends the confirmation to the central gateway device PU1. The central gateway device PU1 then forwards this confirmation, if necessary after conversion to the format suitable for bus B5, to the diagnostic interface. The onboard diagnostic interface (OBDI) then forwards the message confirming the certificate's authenticity to the diagnostic tester DT.

[0071] This then initiates the next step in opening the diagnostic session. This step is designated S9. The diagnostic tester DT sends a request to the OBDI diagnostic interface to prove its possession of the private key. This UDS message contains a signature that the diagnostic tester DT calculated using the private key. The addressed control unit is to verify that the diagnostic tester DT possesses the private key. In step S10, this UDS message is sent from the OBDI diagnostic interface to the central gateway device PU1. From there, it is sent in step S11 to the brake control unit CU4. The brake control unit CU4 verifies the authenticity of the calculated signature using the diagnostic tester DT's public key. The hardware security module (HSM) can be used for this purpose.The SSH authentication protocol is cited as an example of authentication based on this key pair. This protocol is described in Request for Comment RFC 4252. The result of the key verification is transmitted back to the diagnostic tester DT in steps S13 to S15. This key verification step is necessary because the certificate is public and can therefore easily fall into the hands of attackers. It is therefore essential to verify that the certificate owner actually knows the private key. This verification is performed in steps S9 to S15.

[0072] Upon successful verification of private key ownership, the diagnostic tester DT initiates a diagnostic session. In steps S16 to S18, the diagnostic message for initiating the diagnostic session is cascaded to the secured control unit CU4. In step S19, this brake control unit CU4 converts this UDS message into the format valid for the control unit CU5 under test, following authentication of the diagnostic tester DT. This step depends on the version of the diagnostic tester DT and can be omitted if the diagnostic tester DT already delivers the UDS message in a format understandable to the legacy control unit CU5. In step S20, the CAN messages that the legacy control unit CU5 expects to initiate the diagnostic session are generated. The diagnostic message sent here to initiate the diagnostic session corresponds to the UDS message with SID 0x27. The adaptive cruise control control unit CU5 then generates a so-called "seed".This is a string of characters generated by a random number generator. This occurs in step S21. In step S22, a portion of this string is sent as a challenge to the secured control unit CU4 using challenge-response authentication. The brake control unit CU4 appends its private key to the received portion of the string and uses this key to calculate the corresponding key according to the agreed-upon cryptographic algorithm. This calculation can also be performed in the hardware security module (HSM). This occurs in step S23. The calculated key is transmitted to the legacy control unit CU5 in step S24. In step S25, the legacy control unit CU5 compares the received key with the key it calculated itself. It uses the same algorithm that works with the seed generated in step S21. The result of the key comparison is returned to the diagnostic tester DT in steps S26 to S29.If the diagnostic session started successfully, the diagnostic tester DT sends the first diagnostic command in step S30. This diagnostic command is routed along the same path and, after steps S31 and S32, reaches the protected control unit CU4. The firewall function FW in the brake control unit CU4 checks the diagnostic command in step S33. This check specifically verifies whether the diagnostic command is classified as dangerous. This includes, in particular, the diagnostic commands "Read Memory by Address" with SID 0x23 and "Write Memory by Address" with SID 0x3D, "Request Download" with SID 0x34, and "Request Upload" with SID 0x35, which can be used for a firmware update. Such diagnostic commands are blocked and not executed. If the diagnostic command is not classified as dangerous, it is converted in step S34 into the legacy format required for the legacy control unit CU5.In this format, the diagnostic command is sent to the legacy control unit CU5 in step S35. The diagnostic command is then processed by the legacy control unit CU5. The result of the test is transmitted to the brake control unit CU4 in step S36. From there, it is forwarded to the diagnostic tester DT in steps S37 to S39. Typically, further diagnostic commands are sent by the diagnostic tester DT during the open diagnostic session and executed by the legacy control unit CU5. This is described in the... Fig. 5 This is indicated by the outline of steps S30 to S39. For clarity, this frame is therefore referred to as a "loop".

[0073] An optional extension is included in the Fig. 6 Also shown, outlined, and labeled "Option." While in the method described above, the secured control unit CU4 acts as a diagnostic client after certificate-based authentication of the diagnostic tester DT and performs the challenge-response authentication typical for legacy control units in steps S16 to S29, an additional authentication method can be used after the optional extension to further limit attack vectors. In this case, after the diagnostic session is opened in steps S40 to S47, all diagnostic communication is additionally secured. For each diagnostic command sent during the session, the messages from the diagnostic tester DT are authenticated again. This is done by adding a signature to each diagnostic command. The secured control unit CU4 verifies whether the signature is correct.The UDS message used to agree on the session key corresponds to the UDS message with SID 0x84.

[0074] In step S40, the diagnostic tester DT calculates a diagnostic session key based on an agreed-upon initial value. In step S41, an agreed-upon portion of a session secret is transmitted to the OBDI diagnostic interface. In step S42, the OBDI forwards the message containing this portion of the session secret to the central gateway PU1. In step S43, the gateway device PU1 sends the message to the brake control unit CU4. In step S44, the session key is calculated using the portion of the session secret agreed upon for this brake control unit. The results of the session key calculation are then communicated back in steps S45 to S47. This type of authentication would then take place in the secured brake control unit CU4 in the respective step S33.Communication according to the option for calculating the "Shared Key" in steps S40 to S47 can be carried out in the manner of the well-known "Diffie-Hellman Key Exchange" method.

[0075] To protect the control units connected to the vehicle bus B1 against internal and external attacks, it is necessary to equip them with secure CAN transceivers. As described earlier, these secure CAN transceivers can detect and neutralize tampered messages using measures at the data link layer. An alternative security option is to equip the control units connected to the vehicle bus B1 with Secure Onboard Communication (SecOC). This method ensures authenticated message transmission for internal vehicle communication. This corresponds to the described "Diffie-Hellman Key Exchange" method, which, however, is a measure related to the UDS diagnostic protocol, i.e., at the higher layers of the OSI reference model.

[0076] To ensure that no unauthorized modifications are possible to the software stack installed in the secured brake control unit CU4, it is advantageous to equip this brake control unit CU4 with a Secure Boot Manager and a Secure Update Manager to protect software updates. Commercial embedded software stacks are available for this purpose. The AUTOSAR organization has established requirements and rules that such embedded software stacks should meet.

[0077] Optionally, the firewall FW in the brake control unit CU4 could be configured with anomaly detection that reports when suspicious messages are sent to any of the legacy control units networked in the isolated section of the vehicle bus B1'. The firewall could then send a warning message to the vehicle manufacturer or an authority. This warning message can be sent via the on-board communication device KU1 or via the on-board communication device KU2.

[0078] With the outlined approach, a vehicle manufacturer can demonstrate compliance with the UN-ECE R 155 directive without simultaneously upgrading all vehicle components to the latest security standard. The vast majority of attacks are detected by the presented solution. The remaining residual risk can be classified as "acceptable" for a vehicle not equipped with a fully autonomous driver.

[0079] The Fig. 8 Figure 1 shows a second example of a block diagram for the electronic equipment of a towing vehicle. In this diagram, the same reference numbers denote the same components as in Figure 2. Fig. 2 The difference lies in the swapping of the two control units CU4 and CU5. Fig. 8 The protected control unit is the one that performs the distance control to vehicles ahead and includes the radar sensor. A conventional brake control unit CU4 is used as the legacy control unit in the separated part of the vehicle bus B1'. This arrangement allows the control unit system to be operated in a protected manner according to the requirements of UN ECE Directive R155, even though the brake control unit does not yet have any additional safety features.

[0080] It is also possible to network other and / or additional legacy control units in the separated part of the vehicle bus B1', which are then also protected against the described attacks, especially spoofing attacks.

[0081] All examples mentioned herein, as well as conditional formulations, are to be understood without limitation to such specifically cited examples. For instance, it is recognized by experts that the block diagram shown here represents a conceptual view of an exemplary circuit arrangement. Similarly, it is understood that a flowchart, state transition diagram, pseudocode, and the like are different ways of representing processes that are essentially stored in computer-readable media and can thus be executed by a computer or processor.

[0082] It should be understood that the proposed method and associated apparatus can be implemented in various forms of hardware, software, firmware, specialized processors, or a combination thereof. Specialized processors can include application-specific integrated circuits (ASICs), reduced instruction set computers (RISCs), and / or field-programmable gate arrays (FPGAs). Preferably, the proposed method and apparatus are implemented as a combination of hardware and software. The software is preferably installed as an application program on a program storage device. Typically, this is a machine based on a computer platform that includes hardware such as one or more central processing units (CPUs), random access memory (RAM), and one or more input / output (I / O) interfaces. An operating system is also typically installed on the computer platform.The various processes and functions described here may be part of the application program or a part that is executed via the operating system.

[0083] The disclosure is not limited to the embodiments described here. There is scope for various adaptations and modifications that a person skilled in the art would consider based on their expertise and in relation to the disclosure itself. Reference symbol list (part of the description)

[0084] 10 Trailer 12 Support 14 Kingpin 20 Tractor 22 Coupling element 24 Drive unit 25, 25'Brake line 26, 26'Service brake 100CAN node 120CAN transceiver 130Termination resistor 140CAN controller 150Twisted two-wire cable 160Host B1 Vehicle communication bus, first part B1' Vehicle communication bus, detached part B2 2. Communication bus B3 3. Communication bus B4 4. Communication bus B5 5. Communication bus DT Diagnostic tester IT1 - IT6 Various communication interfaces KU1 On-board communication module KU2 Telematics module CU1 Electronic engine control unit CU2 Electronic transmission control unit CU3 Electronic retarder control unit CU4 Electronic brake control unit CU5 Electronic driver assistance system CU6 Electronic brake control unit FW Firewall HSM Hardware security module OBDI Diagnostic interface PU1 Electronic processing unit (gateway) SE Security equipment S1-S47 Steps in the course of a diagnostic session SU1 Camera SU2 Steering angle sensor T1 Diagnostic connector T2 Connection socket for trailer bus system T2' Connection connector for trailer bus system

Claims

1. Device for secured communication between control units in a vehicle (20), each of the control units (CU1 - CU4) being equipped with at least one communication interface (IT1) by means of which they are connected to a first part of a wired vehicle bus system (B1) for the exchange of messages, characterized in that at least one secured control unit (CU4, CU5) is provided which is connected to the vehicle bus system (B1), the secured control unit (CU4, CU5) being provided with at least one further communication interface (IT2) to which a separate part of the vehicle bus system (B1') is connected, and in that the secured control unit (CU4, CU5) is provided with a gateway function (GWF) and security equipment (SE) which fulfills at least the function of a firewall (FW) by means of which attacks from the first part of the vehicle bus system (B1) on one of the control units (CU5, CU4) in the separate part of the vehicle bus system (B1') are repelled, the communication interface (IT1) of the secured control unit (CU4, CU5) being a secured CAN bus communication interface (IT1) that is designed in such a way that it can repel attacks by injected messages from a manipulated control unit in the first part of the vehicle bus system (B1).

2. Device according to any of the preceding claims, characterized in that the gateway function (GWF) of the secured control unit (CU4, CU5) relates to the routing of the messages between the participants in the first and the separate part of the vehicle bus system (B1, B1').

3. Device according to claim 1 or 2, wherein the wired vehicle bus system (B1) corresponds to a CAN bus system (controller area network), in particular in the variant according to the SAE J1939 standard.

4. Device according to claim 3, characterized in that the control units (CU1-CU4) in the first part of the vehicle bus system (B1) are equipped with a secured CAN bus communication interface (IT1), the secured CAN bus communication interface (IT1) being designed to be able to repel on attacks by injected messages from a manipulated control unit in the first part of the vehicle bus system (B1).

5. Device according to claim 4, characterized in that the secured CAN bus communication interface (IT1) is equipped with a secured CAN transceiver (120) or is provided with a software stack that is designed for secured onboard communication.

6. Device according to any of the preceding claims, characterized in that the secured control unit (CU4, CU5) is a brake control unit EBS (electronic braking system) and the control units (CU5, CU4) that are moved into the separate part of the vehicle bus system (B1') include at least one driver assistance system control unit (CU5) or an environment sensing system control unit to which at least one environment sensing sensor (SU1) is connected.

7. Electronic control unit, having a first communication interface (IT1) by means of which the control unit (CU4, CU5) can be connected to a first part of a wired vehicle bus system (B1) for the exchange of messages, characterized in that the control unit (CU4, CU5) has at least one further communication interface (IT2) to which a separate part of the vehicle bus system (B1') can be connected, the control unit (CU4, CU5) being provided with a gateway function and security equipment which fulfills at least the function of a firewall (FW) for the purpose of repelling attacks from the first part of the vehicle bus system (B1) on one of the control units (CU5, CU4) in the separate part of the vehicle bus system (BT), the communication interface (IT1) of the secured control unit (CU4, CU5) being a secured CAN bus communication interface (IT1) that is designed in such a way that it can repel attacks by injected messages from a manipulated control unit in the first part of the vehicle bus system (B1).

8. Electronic control unit according to claim 7, characterized in that the security equipment (SE) also includes software that enables the function of a secured boot process.

9. Electronic control unit according to claim 7 or 8, characterized in that the gateway function (GWF) of the control unit (CU4, CU5) relates to the routing of the messages between the participants in the first and the separate part of the vehicle bus system (B1').

10. Electronic control unit according to any of claims 7 to 9, wherein the first communication interface (IT1) and at least one further communication interface (IT2) corresponds to a CAN bus communication interface (controller area network), in particular in the variant according to the SAE J1939 standard.

11. Electronic control unit according to claim 10, characterized in that the CAN bus communication interface (IT1) for connection to the first part of the vehicle bus system (B1) is equipped with a secured CAN transceiver (120) or is provided with a software stack which is designed for secured onboard communication SecOC and can repel attacks by injected messages from a manipulated control unit in the first part of the vehicle bus system (B1).

12. Electronic control unit according to claim 10 or 11, characterized in that the security equipment (SE) further has a function for certificate-based authentication of an external diagnostic tester (DT) that is connected to a control unit or a gateway unit (PU1) of the first part of the vehicle bus system (B1).

13. Electronic control unit according to claim 12, characterized in that the security equipment (SE) includes an HSM module (HSM) (hardware security module) to ensure secure authentication of at least the external diagnostic tester (DT) that is connected to a control unit or a gateway unit (PU1) of the first part of the vehicle bus system (B1).

14. Electronic control unit according to any of claims 7 to 13, characterized in that the security equipment (SE) further has the function of a diagnostic client control unit for seed key authentication of a control unit (CU4, CU5) that is connected to the separate part of the vehicle bus system (B1') with regard to the execution of diagnostic functions which are called up by communication with the certificate-verified external diagnostic tester (DT).

15. Electronic control unit according to any of claims 7 to 14, characterized in that the security equipment (SE) further has the function of preventing certain diagnostic commands which are received from the external diagnostic tester (DT) and addressed to the control unit (CU5, CU4) to be tested in the separate part of the vehicle bus system (BT) and which are classified as dangerous, in particular with regard to reading and writing memory regions allocated for the execution of computer programs or for the permanent storage of computer programs in non-volatile memory regions.

16. Electronic control unit according to any of claims 7 to 15, characterized in that the security equipment (SE) further has the function of verifying incoming diagnostic commands, individually or in groups, in which the external diagnostic tester (DT) is re-authenticated each time before the relevant diagnostic command is forwarded to the control unit to be tested in the separate part of the vehicle bus system.

17. Electronic control unit according to any of claims 7 to 16, wherein the security equipment further has the function of a secured software update process in which the computer programs stored in the non-volatile memory region are exchanged.

18. Electronic control unit according to any of claims 7 to 17, wherein the electronic control unit (CU4) is a brake control unit EBS (electronic braking system) or a control unit (CU5) for a distance control system or a control unit for an automatic driving system.

19. Vehicle comprising a drive unit (24) and a braking system having an electronic control unit (CU4), characterized in that the vehicle (20) has a device according to any of claims 1 to 6.