EP4635133A1 - Authentication device for a vehicle - Google Patents

Abstract

The invention relates to an authentication device (202) designed to authenticate a network of network nodes for a vehicle (800). To this end, the authentication device (202) is designed to determine an overall validation value of an addable size of authentication messages about the network nodes (204), to compare the determined overall validation value with an overall validation value expected by the authentication device (202), and to authenticate the network (200) on the basis of the comparison of the expected overall validation value with the determined overall validation value.

Description

Authentication device for a vehicle

DESCRIPTION

Technical area

The invention relates to an authentication device for a vehicle, a network node, a method for authenticating a network of network nodes for a vehicle, a program element and a storage medium.

State of the art

With partially automated and highly automated driving, there are increasing demands on the vehicle that require hard real-time support from the transmission network and protocols. The volume of data must be able to be trusted quickly and the integrity of the data must be ensured. Furthermore, an on-board network will be much more flexible in the future than it is today. Nodes will be switched off during operation if they are not needed. This in turn means that the on-board network will change dynamically during runtime. Hardware plug'n'play of sensors is becoming an increasingly important topic. In vehicles, it is therefore becoming increasingly difficult to detect a change in communication, an attack via the diagnostic access, a manipulated control unit and even replaced control units.

An object of the invention is to provide improved authentication of a network for a vehicle.

The object is achieved by the subject matter of the independent patent claims. Advantageous embodiments are the subject matter of the dependent claims, the following description and the figures. The described embodiments similarly relate to the authentication device for a vehicle, the network node, the method for authenticating a network of network nodes for a vehicle, the program element and the storage medium. Synergy effects may result from various combinations of the embodiments, although they may not be described in detail.

It should also be noted that all embodiments of the present invention relating to a method may be carried out in the described order of steps, but this need not be the only and essential order of steps of the method. The methods presented here may be carried out with a different order of the steps disclosed without deviating from the respective method embodiment, unless expressly stated otherwise below.

According to a first aspect, an authentication device is provided which is configured to authenticate a network of network nodes for a vehicle. The authentication device is configured to determine a total validation value of an addable size of authentication messages across the network nodes, compare the determined total validation value with a total validation value expected by the authentication device, and authenticate the network based on the comparison of the expected total validation value with the determined total validation value.

The authentication messages are, for example, special messages that are generated and sent only for authentication. The authentication device can be one of the network nodes that has, for example, additional or dedicated services or program elements necessary for authentication. Such authentication can be carried out, for example, during setup or starting or booting up the network or during any manipulation of the network. Manipulation is, for example, the replacement of a network node or a software update. A software update can concern a configuration or an update of a program or part of a program, such as a dynamic library file.

According to one embodiment, the validation value is a message length or a runtime. A message length can be, for example, a number of transmission units such as bits or symbols. A runtime can result from the number of transmission units and the transmission speed and can be determined, for example, by measuring or determining the received bits.

In one example, the validation value is only a message length or only a runtime.

The authentication device and the network nodes are connected to one another, for example, via a network bus, also referred to as a bus in this disclosure. The authentication messages can, for example, have a header with an ID to identify the message type. The message body, i.e. the content of the message or the so-called "payload", is irrelevant and does not have to be decoded. The only important thing is the length of the message, which is defined, for example, by the number of bits in the payload or the total number of bits in the message. The runtime is then determined by the number of bits and the transmission speed.

According to one embodiment, the authentication device is configured to send a beacon, wherein the beacon is the request to a first network node to generate and send an authentication message, and wherein the authentication device is configured to Authentication message from a second network node that is different from the first network node, and is configured to determine a total validation value, wherein the total validation value corresponds to the added validation values of the authentication messages of the first network node and the second network node.

This means that sending the beacon results in the first network node sending an authentication message. The authentication device waits until it receives an authentication message from the second network node and determines an added validation value from the authentication messages of the first network node and the second network node. This implicitly means that in order to obtain an added validation value, the second network node sends the message to the second network node to enable the addition, and the authentication device can determine an added value such as a total runtime or a total length. The authentication device can be set up to carry out an addition itself or to measure a time until it has received the message from the second node. This is created by sending the authentication messages serially via the first and second network nodes. It should be noted that there can be further network nodes between the first and second network nodes, whose validation values can then be added to those of the first and second network nodes. The determined runtime or “total runtime” can contain offsets that arise at the network nodes or through the sending of the beacon, which can be partly physical in nature and partly caused by data processing or specifications, e.g. through a standard.

Once the authentication device has received an authentication message, it can send a beacon again. Such an authentication process forms a cycle that is described in this disclosure referred to as such. The duration or period of this cycle corresponds to the total validation value and is also referred to herein as cycle length.

According to one embodiment, the authentication device is a network node, a bus master and/or a gateway. However, it can also be, for example, a control device that has the corresponding requirements.

According to a second aspect, a network node of a network for a vehicle is provided, wherein the network node is configured to receive a beacon or an authentication message for authentication of the network, to generate an authentication message which is defined with respect to the authentication by a validation value of an addable size of the authentication messages, and to send the generated authentication message.

As already mentioned, the validation value can be a message length or a runtime, and in particular can be only one of these values.

Here we primarily consider a network that has a network bus on which only one node is allowed to send at a time. The network node is, for example, set up to send the authentication message over the bus when it is its turn. This is the case, for example, after a predecessor node with an address or ID known to it has sent its message. The address or ID of the predecessor node is, for example, preconfigured or can be obtained by the authentication device.

In this way, a chain can be formed that begins with the reception of a beacon and passes through one or more other network nodes in sequence to end again at the authentication device that has the added runtime or the added length of the Authentication messages are determined. In the latter case, for example, the authentication message, or its payload, of the previous network node could be appended to the authentication message generated by the current network node, or the authentication device determines the length of the authentication messages each time a node involved in the authentication sends one and gradually adds up the lengths.

According to one embodiment, the network node is an electronic control unit (ECU), a sensor, a display device, an actuator or another network-capable device. In all cases, the network node must have hardware logic and/or software logic that can generate and send the authentication messages.

According to a third aspect, a network is provided comprising an authentication device as described herein and at least one network node as described herein. The network may further comprise a network bus and is not limited to an authentication device.

In one variant, there can be one or more additional authentication devices in the network. The beacon is a network-wide signal or a network-wide message that can be received by all network nodes. If there is another authentication device in the network that also knows a valid overall validation size, it can also perform authentication. In this case, the starting authentication device is different from the device that performs the authentication. In another variant, the additional authentication device can be part of the chain, i.e. an intermediate authentication station, so to speak, which itself sends an authentication message. There can therefore be several authentication devices in the chain. The authentication device, e.g. a bus master, can thus be configured to receive the last authentication message of the chain and to acquire the validation value of an addable size of the authentication messages for authentication.

According to one embodiment, the validation value of the authentication messages is individual for each network node. The network node can be configured with a validation value statically or dynamically, whereby the validation values usually differ from network node to network node.

According to one embodiment, the network has further network nodes, and the authentication device is configured to determine which network node is part of the chain based on a dynamically generated or stored security pattern.

According to one embodiment, the security pattern further contains one or more of the following values: individual validation value for each network node, ID of the previous network node.

This means that the validation value for a network node and a receiving node can be preconfigured. The validation value, e.g. the individual length of an authentication message from a network node, can be configured before delivery, so that the individual value is only known to the respective network node. Furthermore, each network node only knows the predecessor node, which is preconfigured or communicated to it dynamically.

The authentication device can thus be set up to send the validation value to the network nodes. This increases flexibility. Security is provided by the fact that as long as a malicious device does not know the total runtime or the total length, it is not possible for it to identify a single malicious network node. or to configure all network nodes with validation values that result in a valid overall validation value. It must only be ensured that the total runtime or the total length of the authentication messages remains secret and cannot be manipulated, and that the validation value of a network node cannot be read, e.g. if it is taken from the network and analyzed by an attacker. Since the network is secure after, for example, a network node has been replaced with a malicious network node, it can also be assumed that there is no malicious software in the network that can read the validation values during runtime.

In principle, the network could consist of the authentication device and one or more network nodes. However, several such networks or subnetworks could also exist side by side. This would allow a malicious device to be identified directly or at least isolated.

According to one embodiment, the network is based on a physical layer according to an Ethernet standard.

The Ethernet standards available for automotive applications include, for example, the 10 Mbit/s IEEEP802.3cg standard, or standards with 100 Mbit/s, 1000 Mbit/s, or 2.5, 5, 10 Gbit/s). A variant of the IEEEP802.3ch standard is the MultiDrop mode based on CSMA/CD, which does not require switches (switch ICs), but is designed as a bus. The IEEE P802.3cg standard uses, among other things, a mechanism (PLCA, Physical Layer Collision Avoidance) to avoid collisions during bus access and to ensure fair access. Only one PHY (transceiver) is granted access to the bus at a time. This means that collisions cannot occur. Access is designed according to a so-called round robin procedure. Each control unit (ECU, electronic control unit) or each node on the bus is given the opportunity to send within a defined cycle (or sequence). A so-called headnode determines the cycle and repeatedly sends "beacons" on the bus. The nodes then start a timer depending on the ID of the previous node that they know, which determines the sequence in which they are allowed to send, and then send after the timer has expired and they recognize that it is their turn.

According to one aspect, a method for authenticating a network of network nodes for a vehicle is provided. The method comprises the following steps:

Determining a total validation value of an addable size of authentication messages across the network nodes;

Comparing the total validation value with an expected total validation value;

Authenticate the network by comparing the expected runtime with the determined runtime.

The method thus provides a mechanism in which all control devices together form a kind of blockchain and are authenticated via it. If just one node makes a minimal change to the communication, this can classify an authentication device and the bus as insecure, for example.

According to a further aspect, a program element is provided which, when executed on a processor of the authentication device, instructs the authentication device to perform the steps of the method described above.

The computer program element may be part of a computer program, but it may also be a whole program in itself. For example, the computer program element may be used to update an existing computer program to invention.

According to a further aspect, a storage medium is provided on which the program element is stored.

The computer-readable medium may be considered to be a storage medium, such as a USB flash drive, a CD, a DVD, a data storage device, a hard disk, or any other medium on which a program element as described above can be stored.

The invention can be used to detect, for example, a change in the network, such as an attack via OBD access, an exchange or manipulation of a control unit, or access to safety-critical control units via OBD or infotainment. Furthermore, attacks such as hacker attacks on vehicle networks and theft can be detected and prevented. Furthermore, sensors and sensor data can be authenticated.

Other variations of the disclosed embodiments may be understood and practiced by those skilled in the art in practicing the claimed invention by studying the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other items or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may perform the functions of several items or steps listed in the claims. The mere fact that certain measures are specified in mutually dependent claims does not mean that a combination of those measures cannot be advantageously used. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a semiconductor medium supplied together with or as part of other hardware, but may also be stored/distributed in other forms, for example via the Internet or other wired or wireless telecommunications systems. Reference signs in the claims should not be construed to limit the scope of the claims.

Short description of the drawings

In the following, embodiments of the invention are explained in more detail with reference to the schematic drawings.

Fig. 1A is a diagram of a first example scenario,

Fig. 1 B is a diagram of a second example scenario,

Fig. 2 is a block diagram of a network according to an embodiment,

Fig. 3 is a flow chart of a method for authenticating a network,

Fig. 4A is a diagram of a valid bus cycle,

Fig. 4B is a diagram of a faulty bus cycle,

Fig. 5 a flow chart of the method with further steps,

Fig. 6 a flow chart of the procedure with focus on security patterns,

Fig. 7A a first security example,

Fig. 7B a second security example,

Fig. 8 shows a vehicle with a network according to an embodiment.

Corresponding parts are provided with the same reference numerals in all figures.

Embodiments

Fig. 1 A shows a diagram of an example scenario in which an existing communication connection 108 on a network bus is interfered with. In the data stream to an ECU 102, an additional data packet 106 of malware is inserted between the regular data packets 104. The sender of the data stream including the additional data packet 106 is the same. Such a data packet in an authentication message would change its length and thus be detected.

Fig. 1 B shows a diagram of a second scenario with a manipulation of control units, in which a control unit 114 is replaced. In the normal case, the ECU A 102 communicates with the ECU B 114 via the transceivers 110 and 112. In an attack scenario, the ECU B 114 could be replaced by an ECU B' 116 with transceiver 118, for example to bypass an immobilizer or to manipulate the engine control. From the application's point of view, it cannot be recognized that this is a replaced control unit ECU B' 116. The control unit ECU B' 116 can, for example, take on the original name, such as an ID, an IP address or a bus system address, of the original control unit ECU B 114 and is therefore invisible to the software. This represents a potential danger and can also affect sensors and actuators.

In another example scenario, a jump from, for example, an infotainment domain of an ECU server or domain controller to a driver assistance system (ADAS, Advanced Driver Assistance Systems) domain should be prevented.

Fig. 2 shows a block diagram of a network comprising an authentication device 202 and several network nodes 204 and a network bus 206.

Fig. 3 shows a block diagram of a method 300 for authenticating a network of network nodes for a vehicle, comprising the steps:

Determining 302 a total validation value of an addable size of authentication messages across the network nodes, comparing 304 the determined total validation value with an expected Total validation value, and authenticating 306 the network by comparing the expected total validation value with the determined total validation value.

Figures 4A and 4B show the effects of attacks and unauthenticated devices on the bus in a case where the network nodes NO, N1, N2, N3 know the total runtime 410. When a new or additional node 414, 416 is added, the total runtime 410, 420 changes and postpones the sending of the next beacon 408, 418 by a difference 424 so that a deviation from the expected total runtime 410 can be detected. Any interested node can detect this shift.

The secure scenario is shown in Fig. 4A. Each network node, e.g. a control unit, a sensor or an actuator, follows the pattern and sends exactly the message in the right size (e.g. 200 bytes). The sum of all data packets or message lengths in the cycle (sent and not sent) then defines the cycle length 410, i.e. the total validation value, and thus also the time of transmission of the next beacon 408, 410, which is received by all participants NO, N1, N2, N3. No synchronization is necessary here, since each network node transmits immediately when the bus is free (observing the specified order). The method therefore works without the need for precise coordination of the transmission cycle. Fig. 4B shows a case in which an attack or an error has occurred. One or more participants, e.g. network nodes 414, 416, are affected and behave differently than defined by the security pattern. This does not initially affect the bus communication. However, the actual cycle length is affected and deviates significantly from the previously defined one. This can then be identified as a problem. In this case, no network node needs to know the overall pattern or have knowledge of the data of the other network nodes, which is a particular advantage of the method. The network nodes only have knowledge of, for example, the start of the next cycle. The method is therefore particularly suitable for a highly distributed system. At the time the new beacon 408 is sent out by the authentication device or master, each network node then knows whether the bus can be considered secure or not.

The method 300 presented in Fig. 3 can be part of a network procedure with further steps, which has the following steps, as shown in Fig. 5:

In step 502, the network bus is initialized.

In step 504, the number of bus participants capable of transmitting, i.e. the network nodes described here, is determined.

In step 506, a security pattern is defined. The security pattern contains, for example, the individual validation values such as the runtime or length of the authentication message. These can be determined using a random generator, for example. The security pattern can also define the order in which the network nodes send their authentication message. The network nodes thus form a chain with, for example, the authentication device as the start and end link, whereby the authentication device itself does not generate and send an authentication message. Alternatively, there are other authentication devices in the chain that do not necessarily generate and distribute a security pattern, but receive it from the master of the bus.

In step 508, the overall validation value is calculated based on the pattern. Alternatively, for example, an overall validation value can first be specified or already configured and the security pattern in step 506 is defined under the condition of this specified overall validation value. The overall validation value can optionally be transmitted to all network nodes. In an alternative, the overall validation value can be transmitted to some of the network nodes, which can then also carry out authentication.

In step 510, the security pattern is sent, for example, in individual form to the network nodes. This means that the network nodes are sent, for example, the length of the authentication message to be generated and the ID of the predecessor node. Alternatively, steps 504 to 510 or part of these steps can be replaced by a preconfiguration. The order of steps 510 and 508 can also be swapped.

In step 512, a beacon is sent, which starts the sending of the authentication messages.

In step 514, the authentication messages are generated and sent by the network nodes in the defined order according to the respective validation value. This means that each node on the bus sends a predefined data packet, for example after startup or initialization or after the vehicle starts. Only the size of the packet is relevant here and not the content. This implicitly maps the bus cycle. Only after a node has sent can the next node send, and so on. When all nodes have had their turn, the master can send a new beacon to start a new cycle, whereby the time of sending this new beacon depends exclusively on the sum of the nodes' delays. Each participant therefore has a direct influence on this time. The next beacon time can therefore be predicted precisely.

In step 516, the validation of the total validation value takes place, i.e. the authentication and checking of the total validation value is carried out according to the method 300.

Steps 504 to 512 and 516 can, for example, be performed by the authentication device.

Fig. 5 therefore also shows the process of bus identification and pattern definition and transmission. There can be different points in time for checking authentication. This can be a so-called "terminal 30", i.e. when the power supply is connected, or a service, a plug'n'play of a new control unit, or at any other point in time, which is either permanently configured or communicated dynamically to the participants on the bus. In order to define the cycle length, knowledge of the number of participants is necessary - i.e. which control units are included in the security procedure, or which control units are to be tested. For example, all of them could always be included, or just a subset of the connected participants. The subset can be control units that are either particularly safety-critical, devices with a monitoring function, or just devices that can technically participate in the procedure. This is shown in Fig. 6. It should also be taken into account which control units are used for monitoring, ie as authentication devices.

Fig. 6 shows a flow chart of the method with a focus on the creation and transmission of the security pattern. The reference symbols are related to Fig. 5. Step 504 is divided into two sub-steps 602 and 604. Accordingly, in 602 it is determined which control units or participants should be checked by the method. These are, for example, newly connected control units, control units that have been in sleep mode, control units with an online connection, multiple interfaces, etc. In step 604 the control units are determined that should be informed of the security result, such as only the bus master, all control units or diagnostic devices, etc. In step 508 the method either dynamically determines a security pattern or uses a pattern that has already been saved and preconfigured. The pattern defines which participant or network node (ECU, sensor, actuator, etc.) sends an authentication message. Furthermore, the pattern defines the message lengths that are to be sent. No time synchronization is necessary for this, because the control units send in sequence or when the previous one has sent its authentication message. In step 510, the cycle length or the total validation value is calculated. In step 612, a decision is made as to whether further control units are to be informed. If only the bus master as an authentication device, for example the gateway, monitors the bus is to be used, only the pattern is transmitted in step 616. The cycle length does not need to be transmitted in this case. Otherwise, i.e. if additional control units are to be used for checking, the cycle length can first be transmitted in step 614 and then step 616 can be used to transmit the pattern. This is not confidential information itself, since an attacker cannot do anything with the actual number or value. The total validation value can only be achieved when the combination of all control units is known.

Figures 7A and 7B show two examples of a security pattern 702. In the pattern 702 shown in Fig. 7A, nodes 0, 1, 5, 7 and 8 send (Tx) an authentication message with the specified length L in bytes, while all other nodes do not send an authentication message. The nodes that do not send an authentication message are also part of the pattern 702, since not sending also influences the cycle length. The advantage of this is that the pattern 702 does not have to be completely distributed or known, only the respective node has to know its own values. In Fig. 7B, nodes 1, 3, 5 and 8 send an authentication message. The lengths L differ partially from those of the pattern 702 in Fig. 7A.

The security level works in combination with all participants, similar to a blockchain-based system. The applied pattern then clearly determines the cycle length. Various patterns are possible here. In a first example, the pattern is a static pattern that is encrypted and programmed. In a second example, the pattern is a dynamically created pattern. In a third example, the pattern is based on predefined parameters such as the current time. In a fourth example, the pattern is based on the MAC addresses of the participants.

In one embodiment, the pattern does not directly specify the length of the authentication message, but it may contain one or more parameters from which the network node can derive the length. For example, the authentication device, which is the master, sends a parameter value to the network node, e.g. a control unit, which the control unit adds to the last two digits of its MAC address and then uses as the length for the next data packet, which here is equivalent to the authentication message. The pattern can also be permanently encoded in a secure memory area and then queried on request or the frame length can be determined with it.

Fig. 8 schematically shows a vehicle 800 with a network 200 described herein, comprising an authentication device 202, several network nodes 204, and a network bus 206.

The process makes it possible to block attacks in the hardware and thus prevent them from reaching the ECU software or even a possible forwarding. This relieves the burden on resources and possible firewalls. The attacker can no longer gain access to the system using the process. Furthermore, attacks can not only be fended off, but the attempt itself can also be diagnosed. The process also offers another method to only allow authorized access to the vehicle's on-board network. The common hardware does not have to be changed; the existing hardware can continue to be used. The computing capacity required is low, so that a security procedure can be implemented and subsequently written to the flash memory without affecting the system resources (memory, computing power, real-time capability). The process also has the particular advantage that there is no need to actively intervene in the communication. The security procedure can be carried out and checked silently. In addition, not all control units have to participate in the process. The process can also be evaluated in real time and does not require any further calculation or analysis in a cloud.

Claims

PATENT CLAIMS 1. Authentication device (202) configured to authenticate a network (200) of network nodes (204) for a vehicle (800); wherein the authentication device (202) is configured to determine a total validation value of an addable size of authentication messages via the network nodes (202), compare the determined total validation value with a total validation value expected by the authentication device (202), and authenticate the network based on the comparison of the expected total validation value with the determined total validation value. 2. Authentication device (202) according to claim 1, wherein the validation value is a message length or a runtime. 3. Authentication device (202) according to claim 1 or 2, wherein the authentication device (202) is configured to send a beacon (402), wherein the beacon (402) is the request to a first network node to generate and send an authentication message; to receive an authentication message from a second network node (204) that is different from the first network node (204); and to determine a total validation value, wherein the total validation value corresponds to the added validation values of the authentication messages of the first network node (204) and the second network node (204). 4. Authentication device (202) according to one of claims 1 to 3, wherein the authentication device (202) is a bus master and/or a gateway. 5. Network node of a network for a vehicle (800), wherein the network node is configured to receive a beacon (402) or an authentication message for authentication of the network; then to generate its own authentication message, which is defined with respect to the authentication by a validation value of an addable size of the authentication messages; and to send the generated authentication message. 6. Network node according to claim 5, wherein the network node is a control unit (ECU, electronic control unit), a sensor, or an actuator. 7. A network (200) comprising an authentication device (202) according to one of claims 1 to 4; and at least one network node (204) according to claim 5 or 6. 8. The network (200) of claim 7, wherein the validation value of the authentication messages is individual for each network node (204). 9. Network (200) according to one of claims 7 or 8, wherein the network (200) has further network nodes (204), and wherein the authentication device (202) is configured to determine which network node (204) is part of the chain according to a dynamically generated or a stored security pattern (702). 10. Network (200) according to one of claims 8 or 9, wherein the security pattern further contains one or more of the following values: individual validation value for each network node (202), ID of the previous network node (202). 11. Network (200) according to one of claims 7 to 10, wherein the network (200) is based on a physical layer according to an Ethernet standard. 12. A method (300) for authenticating a network (200) of network nodes for a vehicle (800), comprising the steps: Determining (302) a total validation value of an addable size of authentication messages across the network nodes (204); Comparing (304) the determined total validation value with an expected total validation value; Authenticating (306) the network by comparing the expected total validation value with the determined total validation value. 13. A program element which, when executed on a processor of the authentication device (202) according to any one of claims 1 to 4, instructs the steps of the method according to claim 12 to be carried out. 14. Storage medium on which the program element according to claim 13 is stored. 15. Vehicle comprising an authentication device (202) according to one of claims 1 to 4.