Authentication device for a vehicle

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

[0001] Authentication device for a vehicle

[0002] DESCRIPTION

[0003] Technical area

[0004] 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.

[0005] State of the art

[0006] With partially and highly automated driving, vehicle requirements are increasingly being placed on the vehicle that require hard real-time support from the transmission network and protocols. The data volumes must be quickly relied upon, and the integrity of the data must be ensured. Furthermore, the on-board network will be much more flexible in the future than today. Nodes will be shut down during operation when they are not needed. This, in turn, means that the on-board network will undergo significant dynamic changes during runtime. Hardware plug-and-play of sensors is becoming an increasingly important issue. Therefore, changes in communication, attacks via diagnostic access, manipulated control units, and even replaced control units are becoming increasingly difficult to detect in vehicles.

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

[0008] 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 can arise from various combinations of the embodiments, although they may not be described in detail.

[0009] Furthermore, it should 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 sole and essential order of steps in the method. The methods presented herein may be carried out with a different order of the disclosed steps without deviating from the respective method embodiment, unless expressly stated otherwise below.

[0010] According to a first aspect, an authentication device is provided that is configured to authenticate a network of network nodes for a vehicle. The authentication device is configured to determine a total validation value of a summable number 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.

[0011] Authentication messages, for example, are special messages generated and sent solely for authentication. The authentication device can be one of the network nodes that, for example, has additional or dedicated services or program elements required for authentication. Such authentication can be performed, for example, during setup or startup of the network, or during any manipulation of the network. Manipulation could include, for example, replacing a network node or performing a software update. A software update can involve a configuration or updating a program or a program component, such as a dynamic library file.

[0012] According to one embodiment, the validation value is a message length or a propagation time. A message length can be, for example, a number of transmission units such as bits or symbols. A propagation time 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.

[0013] In one example, the validation value is solely a message length or solely a runtime.

[0014] The authentication device and the network nodes are connected to each other, 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 need to be decoded. Only the length of the message is relevant, which is defined, for example, by the number of bits in the payload or the total number of bits in the message. The runtime then results from the number of bits and the transmission speed.

[0015] 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 receive an 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.

[0016] This means that sending the beacon causes the first network node to send 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. It follows implicitly 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 configured to perform an addition itself or to measure a time until it has received the message from the second node. This time is generated by serially sending the authentication messages via the first and second network nodes.It should be noted that there may be additional 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 propagation time or "total propagation time" may include offsets that arise at the network nodes or from the transmission of the beacon. These offsets may be partly physical in nature and partly due to data processing or specifications, e.g., a standard.

[0017] Once the authentication device has received an authentication message, it can send another beacon. Such an authentication process represents a cycle, which is referred to as such in this disclosure. The duration or period of this cycle corresponds to the total validation value and is also referred to herein as the cycle length.

[0018] 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 unit that meets the corresponding requirements.

[0019] 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 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.

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

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

[0022] In this way, a chain can be formed that begins with the reception of a beacon and passes sequentially through one or more additional network nodes, ending again at the authentication device, which determines the combined runtime or the combined length of the authentication messages. 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 could determine the length of the authentication messages each time a node involved in the authentication sends one and gradually add up the lengths.

[0023] 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.

[0024] 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.

[0025] In one variant, one or more additional authentication devices can be present in the network. The beacon is a network-wide signal or a network-wide message that can be received by all network nodes. If another authentication device is present in the network that also knows a valid overall validation value, it can also perform authentication. In this case, the starting authentication device is different from the device performing the authentication. In another variant, the additional authentication device can be part of the chain, i.e., an intermediate authentication station that itself sends an authentication message. Thus, several authentication devices can be present 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 capture the validation value of an addable size of the authentication messages for authentication.

[0026] According to one embodiment, the validation value of the authentication messages is unique for each network node. The network node can be configured with a validation value statically or dynamically, with the validation values ​​typically varying from network node to network node.

[0027] 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.

[0028] 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.

[0029] 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 known only to the respective network node. Furthermore, each network node only knows the predecessor node, which is either preconfigured or communicated to it dynamically.

[0030] The authentication device can thus be configured 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 configure a single, e.g., malicious network node or 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 still, e.g.If it is safe to replace a network node 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.

[0031] 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 could allow a malicious device to be directly identified or at least contained.

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

[0033] Ethernet standards available for automotive applications include the 10 Mbit / s IEEE P802.3cg standard, as well as standards for 100 Mbit / s, 1000 Mbit / s, or even 2.5, 5, and 10 Gbit / s. A variant of the IEEE P802.3ch standard is the CSMA / CD-based MultiDrop mode, 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 ensure fair access. Only one PHY (transceiver) is granted access to the bus at a time. This prevents collisions. Access is arranged according to a so-called round robin procedure. Each control unit (ECU) or each node on the bus is given the opportunity to transmit within a defined cycle (or sequence).The headnode determines the cycle and recurringly sends "beacons" on the bus. The nodes then start a timer based on the ID of the predecessor node they know, which determines the order in which they are allowed to send. They then send their own beacons after the timer expires and they recognize that it is their turn.

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

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

[0036] Comparing the overall validation score with an expected overall validation score;

[0037] Authenticate the network by comparing the expected runtime with the determined runtime.

[0038] The method thus provides a mechanism in which all control units together form a kind of blockchain and are authenticated through it. If even one node makes a minimal change to the communication, this can, for example, cause an authentication device and the bus to be classified as insecure.

[0039] 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.

[0040] The computer program element may be part of a computer program, but it may also be an entire program in itself. For example, the computer program element may be used to update an existing computer program to achieve the present invention.

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

[0042] 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.

[0043] The invention can, for example, detect changes to the network, such as an attack via OBD access, the replacement 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.

[0044] 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 elements 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 multiple items or steps recited in the claims. The mere fact that particular measures are recited in dependent claims does not mean that a combination of those measures cannot be advantageously utilized.A computer program may be stored / distributed on a suitable medium, such as an optical storage medium or a semiconductor medium supplied with or as part of other hardware, but may also be 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.

[0045] Short description of the drawings

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

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

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

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

[0050] Fig. 3 is a flowchart of a method for authenticating a network,

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

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

[0053] Fig. 5 is a flow chart of the method with further steps,

[0054] Fig. 6 a flowchart of the procedure with focus on security patterns,

[0055] Fig. 7A a first security pattern example,

[0056] Fig. 7B a second security pattern example,

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

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

[0059] Embodiments

[0060] Fig. 1A shows a diagram of an example scenario in which an existing communication connection 108 on a network bus is compromised. An additional data packet 106 of malware is inserted into the data stream to an ECU 102 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.

[0061] Fig. 1B shows a diagram of a second scenario involving the 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 a transceiver 118, for example, to bypass an immobilizer or to manipulate the engine control system. From the application's perspective, it cannot be recognized that the control unit ECU B' 116 has been replaced. The control unit ECU B' 116 can, for example, assume 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 thus invisible to the software. This represents a potential threat and can also affect sensors and actuators.

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

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

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

[0065] 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 based on the comparison of the expected total validation value with the determined total validation value.

[0066] Figures 4A and 4B show the effects of attacks and unauthenticated devices on the bus in a case where the total propagation time 410 is known to the network nodes N0, N1, N2, and N3. When a new or additional node 414, 416 is added, the total propagation time 410, 420 changes, shifting the transmission of the next beacon 408, 418 by a difference 424, so that a deviation from the expected total propagation time 410 can be detected. Any interested node can detect this shift.

[0067] 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 correct 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 sequence). Thus, the method functions 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, i.e.,Network nodes 414, 416 are affected and behave differently than defined by the security pattern. Although bus communication is not initially affected, the actual cycle length is influenced and deviates significantly from the previously defined length. This can then be identified as a problem. No network node needs to know the overall pattern or the data of the other network nodes, which is a particular advantage of the method. The network nodes only know, for example, the start of the next cycle. The method is therefore particularly suitable for highly distributed systems. At the time the new beacon 408 is sent out by the authentication device or master, each network node knows whether the bus can be considered secure or not.

[0068] 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:

[0069] In step 502 the network bus is initialized.

[0070] In step 504, the number of transmitting bus participants, ie the network nodes described here, is determined.

[0071] 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, for example, using a random generator. The security pattern can also define the order in which the network nodes send their authentication messages. The network nodes thus form a chain with, for example, the authentication device as the first and last 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 bus master.

[0072] 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 based on this specified overall validation value. The overall validation value can optionally be transmitted to all network nodes. Alternatively, the overall validation value can be transmitted to a subset of the network nodes, which can then also perform authentication.

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

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

[0075] 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, not the content. This implicitly maps the bus cycle. Only after a node has sent may the next node send, and so on. Once 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. Thus, each participant has a direct influence on this time. The next beacon time can therefore be accurately predicted.

[0076] In step 516, the validation of the overall validation value takes place, ie the authentication and verification of the overall validation value is carried out according to the method 300.

[0077] For example, steps 504 to 512 and 516 can be performed by the authentication device.

[0078] Fig. 5 thus also depicts the process of bus identification, pattern definition, and transmission. There can be various points in time for verifying authentication. This could be a so-called "terminal 30," i.e., when the power supply is connected, or a service, a plug-and-play of a new control unit, or any other point in time, which is either permanently configured or dynamically communicated to the participants on the bus. To define the cycle length, knowledge of the number of participants is necessary—that is, 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 simply devices that can technically participate in the process. This is shown in Fig. 6. Furthermore, it should also be considered which control units serve for monitoring, i.e., as authentication devices.

[0079] Fig. 6 shows a flowchart 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 substeps 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 that should be informed of the security result are determined, 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 previously saved and preconfigured pattern. The pattern defines which participant or network node (ECU, sensor, actuator, etc.) sends an authentication message.The pattern also defines the message lengths to be sent. No time synchronization is necessary for this, as the control units send one after the other 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 additional control units should be notified. If only the bus master, for example the gateway, is to monitor the bus as the authentication device, only the pattern is transmitted in step 616. In this case, the cycle length does not need to be transmitted. Otherwise, i.e., if additional control units are to be included in the verification, 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 in itself, as an attacker cannot do anything with the actual number or value.Only when the combination of all control units is known can the overall validation value be achieved.

[0080] 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 needs 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.

[0081] The security level works in combination with all participants, similar to a blockchain-based system. The applied pattern then uniquely 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 generated 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.

[0082] In one embodiment, the pattern does not directly specify the length of the authentication message, but can 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 is synonymous with the authentication message. The pattern can also be permanently encoded in a secure memory area and then queried upon request, or the frame length can be determined using it.

[0083] 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.

[0084] This process makes it possible to block attacks in the hardware, preventing them from even reaching the ECU software or potentially being forwarded. This relieves the burden on resources and any firewalls. The attacker can no longer gain access to the system using this process. Furthermore, attacks can not only be fended off, but the mere attempt can also be diagnosed. The process also offers an additional method for only allowing authorized access to the vehicle's on-board network. The standard hardware does not need to be modified; the existing hardware can be reused. The required computing capacity is low, so a security process can be implemented and even subsequently written to the flash memory without affecting the system resources (memory, computing power, real-time capability).The process also has the unique advantage that no active intervention in the communication is required. The safety procedure can be executed and checked silently. Furthermore, not all control units need to participate in the process. The process can also be evaluated in real time and does not require any further calculations or analysis in a cloud.

Claims

PATENT CLAIMS 1. An 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 quantity of authentication messages across 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. A 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 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 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 any 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. The network (200) of claim 8 or 9, wherein the security pattern further includes 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.

14. Storage medium on which the program element according to claim 13 is stored.

15. A vehicle comprising an authentication device (202) according to any one of claims 1 to 4.

Images