Reduction in manipulation of vehicle software

Abstract

To reduce manipulation of vehicle software.SOLUTION: A first aspect of the present disclosure relates to a computer-implemented method. The method includes a step of analyzing communication between a first component of a plurality of components for an on-vehicle network of a vehicle and a central device for reducing manipulation of software, the communication protected by one or more encryption methods. The central device for reducing manipulation is a part of the on-vehicle network and is designed for reduction of software in each of the plurality of components for the on-vehicle network. The method further includes a step of recognizing, by the central device for reducing manipulation of software, the possibility of manipulation of software of the first component, and a step of introducing, by the central device for reducing manipulation, measures for reducing manipulation of the software of the first component.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] Regarding vehicle software. [Background technology]

[0002] In recent years, vehicles have become increasingly embedded in open contexts (i.e., vehicles have one or more interfaces through which data is received and / or transmitted during operation and which are in turn used for the operation of the vehicle). Furthermore, the complexity of vehicle components, and in particular their software, continues to increase. Furthermore, vehicle software is updated during operation in an ever more diverse manner.

[0003] As a result, the possibilities for tampering with the software of vehicle components become more diverse. Summary of the Invention [Problem to be solved by the invention]

[0004] In some state-of-the-art methods, the detection and especially the mitigation of tampering (i.e., repair so that a defined (safe) state is achieved) involves considerable effort and therefore time delays. For example, in the context of a factory maintenance, the tampered software of a component (e.g., a control device) can be reset, thus repairing the tampering. In other techniques, a remote computer system can request software, which resets the tampered software of a component (e.g., a control device), thus repairing the tampering. In both cases, there can be a significant period between the detection of the tampering and the mitigation of the tampering. In some situations, the operation of the vehicle is hindered during this period (e.g., predetermined safety standards are no longer met). In some cases, the vehicle can no longer be driven or its functionality can be significantly impaired. Therefore, improved techniques for mitigating software tampering are desirable. [Means for solving the problem]

[0005] A first general aspect of the present disclosure relates to a computer-implemented method, the method including analyzing communications secured by one or more cryptographic methods between a first component of a plurality of components of an in-vehicle network of a vehicle and a central device for software tamper mitigation. The central device for tamper mitigation is part of the in-vehicle network and is designed for software mitigation in each of the plurality of components of the in-vehicle network. The method further includes recognizing, at the central device for software tamper mitigation, potential software tampering of the first component based on the analysis of the communications, and deploying, by the central device for tamper mitigation, countermeasures for mitigating software tampering of the first component.

[0006] A second general aspect of the present disclosure relates to a system designed to carry out the method according to the first general aspect. A third general aspect of the present disclosure relates to a central device for mitigating software tampering of components of an in-vehicle network of a vehicle, the central device being designed to perform the method of the first general aspect.

[0007] A fourth general aspect of the present disclosure relates to an in-vehicle network for a vehicle, the in-vehicle network including a plurality of components including a first component and a central device for mitigating software tampering according to the third general aspect.

[0008] A fifth general aspect of the present disclosure relates to a vehicle that includes and / or is part of a system according to the second general aspect and / or includes an in-vehicle network according to the fourth general aspect.

[0009] The techniques of the first through fourth general aspects of the present disclosure may, in some cases, have one or more of the following advantages. First, in some situations, it can be ensured that the central device for mitigating software tampering is reliably aware of the existence of software tampering in the first component (and possibly other components) and can subsequently implement countermeasures. Often, software tampering detection is first performed locally in the first component. The first component must communicate with the (remote) central device for mitigating software tampering (e.g., send a message that tampering has been confirmed) so that the tampering can be recognized on its side. This communication of the first component (and possibly other components) is protected by one or more cryptographic methods. In an illustrative example, communication between the security module of the first component and the central device for mitigating software tampering may be encrypted. This measure can make it difficult or impossible for an intruder to intercept and / or disrupt communication between the respective components and the central device for mitigating software tampering. In the absence of such means, an attacker may try to prevent the implementation of countermeasures for tampering by affecting communications in systems with a central device for mitigating software tampering, or to induce unnecessary countermeasures under the guise of tampering (which may in turn have a negative impact on the operation of the vehicle).

[0010] Second (and as a consequence of the first advantage), the techniques of the present disclosure enable the secure use, in some cases, of a central device for mitigating software tampering. Systems with a central device for mitigating software tampering can be more easily scaled and / or used in older vehicles (vehicles not designed according to the latest standards) compared to some state-of-the-art techniques. For example, a central device for mitigating tampering can be relatively easily modified to “monitor” additional components. In some cases, this requires little or no modification to the “monitored” components, facilitating use in older vehicles. In some cases, the central device for mitigating tampering itself can also be retrofitted via a software update. For example, an existing component of a vehicle (e.g., a central vehicle communication interface or a central vehicle computer) can be provided with the (additional) functionality of a central device for mitigating tampering via a software update.

[0011] Several terms are used in this disclosure as follows: That is, a "component" (of an in-vehicle network) in this disclosure has its own hardware resources, including at least one processor for executing instructions and memory for storing at least one software component. The term "processor" also includes a multi-core processor, or multiple separate components that assume (and possibly share) the tasks of a central processing unit of an electronic device. A component can independently perform tasks (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other operational tasks). However, in some examples, a component can also be controlled by another component. A component can be physically separated (e.g., with its own housing) or integrated into a higher-level system. A component can be a vehicle control device or communication device. A component can be an embedded system. A component can include one or more microcontrollers.

[0012] An "embedded system" is a component that is embedded in a technological context, where the component undertakes measurement, monitoring, control, communication, and / or other work tasks.

[0013] A "(dedicated) control device" is a component that controls one (only) function of the vehicle. A control device may, for example, take on engine control, braking system control, or assist system control. Here, a "function" may be defined at different levels of the vehicle (for example, a function may use a single sensor or actuator, but may also use multiple assemblies that are grouped together in a larger functional unit).

[0014] The term "software" or "software component" may basically refer to each piece of software of a component (e.g., a controller) of the present disclosure. In particular, a software component may be a firmware component of a component of the present disclosure. Firmware is software that is embedded in an (electronic) component and performs basic functions therein. Firmware is functionally closely linked to the respective hardware of the component (such that one is not available without the other). Firmware may be stored in non-volatile memory such as flash memory or EEPROM.

[0015] The term "update" or "software update" includes all data that directly or after a corresponding processing step forms a software component of a component according to the present disclosure. Updates may include executable code or code that has not yet been compiled (code stored in the memory of the corresponding component).

[0016] The term "tampering" in this disclosure includes any modification of the software of a vehicle component, which may be the result of an attack (i.e., a deliberate exertion of influence by a third party), but may also be the result of random or unintended influence.

[0017] The term "vehicle" includes any device that transports passengers and / or cargo. A vehicle may be a motor vehicle (e.g., a car or truck), but also a rail car. However, floating and flying devices may also be vehicles. A vehicle may operate at least partially autonomously or may be assisted.

[0018] An "in-vehicle network" may be each internal network of a vehicle through which vehicle components communicate. In some examples, the in-vehicle network is a short-range network. The in-vehicle network may use one or more short-range communication protocols (e.g., two or more short-range communication protocols). The short-range communication protocols may be wireless or wired communication protocols. The short-range communication protocols may include bus protocols (e.g., CAN, LIN, MOST, FlexRay, or Ethernet). The short-range communication protocols may include Bluetooth protocols (e.g., Bluetooth 5 or later) or WLAN protocols (e.g., protocols of the IEEE 802.11 family, e.g., 802.11h or later). The in-vehicle network may include interfaces for communicating with systems external to the vehicle and thus may be incorporated into other networks. However, systems external to the vehicle and other networks are not part of the in-vehicle network.

[0019] The expression "recognizing the possibility of..." means that certain events (e.g., a signal, or the absence of a signal) are interpreted according to predetermined rules in order to recognize a state in which software tampering is possible. [Brief explanation of the drawings]

[0020] [Figure 1] 1 is a flowchart illustrating a technique of the present disclosure. [Figure 2] FIG. 1 illustrates components of a vehicle's in-vehicle network that can employ techniques of this disclosure. [Figure 3] FIG. 1 illustrates exemplary components of an in-vehicle network. [Figure 4] FIG. 2 illustrates a sequence diagram of an exemplary method of the present disclosure. [Figure 5] 3 shows the in-vehicle network according to FIG. 2, with the first component being tampered with; [Figure 6]3 shows the in-vehicle network according to FIG. 2 after tampering with the first component has been repaired; DETAILED DESCRIPTION OF THE INVENTION

[0021] First, vehicles and components capable of implementing the techniques of the present disclosure, as well as basic aspects of the techniques of the present disclosure, will be discussed with reference to Figures 1-3. An example of the techniques of the present disclosure will be discussed with reference to Figure 4. Further aspects of a central device for mitigating software tampering will be described with reference to Figures 5 and 6.

[0022] Figure 1 is a flowchart illustrating the techniques of this disclosure, Figure 2 illustrates components of an in-vehicle network of a vehicle in which the techniques of this disclosure may be used, and Figure 3 illustrates example components of an in-vehicle network.

[0023] In Figure 1, the center column shows steps that may be performed in some instances by a central device for mitigating software tampering (but also by other components in other instances). The right column shows steps performed by a particular component (or group of components) of the in-vehicle network (excluding the central device for mitigating software tampering). The left column shows steps that are performed by a remote system (i.e., external to the vehicle).

[0024] The vehicle 20 includes a central device 25 for software tamper mitigation, which recognizes possible tampering. It is therefore part of the in-vehicle network (i.e., it is also part of the vehicle and travels with the vehicle). The central device 25 for software tamper mitigation may be designed to mitigate software tampering in each of the components 21-24, 27a-f of the in-vehicle network. In some examples, the central device 25 for software tamper mitigation is integrated into a central communication interface of the vehicle 20. The central communication interface may be designed to function as a data distributor for communication within the vehicle 20 and / or with the outside world via the communication interfaces 21, 22. Here, the central communication interface may support different communication protocols (for communication with the in-vehicle network or with external systems) and / or implement security features. In other examples, the central device for software tamper mitigation may be integrated into other components (further examples follow) or designed as a standalone component.

[0025] The techniques of this disclosure include analyzing 101 communications secured by one or more cryptographic methods between a first component 27c of a plurality of components 21-24, 25, 27a-f of an in-vehicle network of a vehicle 20 and a central device 25 for mitigating software tampering. Vehicle 20 is shown schematically in FIG. 2, and an exemplary first component 27c is shown in FIG. 3. Vehicle 20 is equipped with an in-vehicle network connecting the plurality of components 21-24, 25, 27a-f of vehicle 20 (the in-vehicle network may be configured as described above). The term "analysis" includes not only evaluation of the content of the communications (e.g., the content of transmitted messages), but also evaluation of patterns of communications (e.g., frequency of messages or absence of messages).

[0026] In some examples, the communication includes a message (or messages) from the first component 27c indicating possible software tampering (e.g., the message is sent from the security module of the first component, further description of which is provided below in connection with Figures 3 and 4). In this case, the central device for mitigating software tampering 25 can learn of possible tampering from the content of the message. The message (or messages) can indicate possible software tampering in various ways. In some examples, a particular type of message can indicate possible software tampering (e.g., by a particular message identifier). Additionally or alternatively, information regarding possible software tampering can be included in the payload of the message. In all examples, the transmitted information can be binary (i.e., possible tampering), or additional information regarding the tampering (e.g., regarding the type of tampering) can be transmitted.

[0027] Additionally or alternatively, the recognition may include confirming the absence of an (expected) signal (e.g., a message) (e.g., from the first component 27c). The in-vehicle network may be designed such that the plurality of components 21-24, 25, 27a-f or other components transmit a signal (e.g., periodically or upon the occurrence of a specific event, such as the startup of a component) indicating the absence of tampering with the software of each of the plurality of components 21-24, 25, 27a-f. In some examples, the signal may include a message.

[0028] The confirmation of the absence of an (expected) signal (e.g., message) can be made in various manners. In some examples, the absence can be confirmed when the signal (e.g., message) does not arrive within a predetermined time (e.g., within a predetermined time after receiving the previous signal and / or after transmitting the previous signal). Additionally or alternatively, the absence can be confirmed when the signal (e.g., message) is no longer received with the expected frequency / frequency. The confirmation of the absence of an (expected) signal (e.g., message) parameter can be configurable (e.g., changeable during operation of the vehicle) in some examples.

[0029] In some examples, the first component 27c (and possibly further components) may repeatedly (e.g., periodically or upon the occurrence of a particular event) send a signal (e.g., a message) indicating that no tampering has occurred. The central device for mitigating software tampering 25 may confirm the possibility of tampering in the absence of the signal (e.g., once or several times and / or over a predetermined period of time).

[0030] In some examples, only the first component 27c (and possibly further components) sends a signal (e.g., a message). The central device for mitigating software tampering 25 monitors only this signal. In another example, the central device for mitigating software tampering 25 and the first component 27c (and possibly further components of the in-vehicle network) can alternately send signals (e.g., messages) when no tampering is recognized (i.e., during normal operation). In other words, the central device for mitigating software tampering 25 and the first component 27c (and possibly further components of the in-vehicle network) repeatedly exchange signals (e.g., messages). For example, first, the central device for mitigating software tampering 25 can send a signal (e.g., a message) to the first component 27c. After the signal (e.g., message) is received by the first component 27c, the first component 27c on the other hand sends a signal (e.g., message) to the central device for mitigating software tampering 25, and so on. The transmissions may occur at regular or irregular intervals and / or upon the occurrence of a particular event. In either case, however, receipt of a signal triggers a subsequent transmission. The first component 27c and the central device for mitigating software tampering 25 alternately send and receive signals (e.g., messages).

[0031] In all instances where the absence of a signal is used to recognize possible tampering, this may enable the central device for mitigating software tampering 25 to recognize possible tampering even when a specific "source" of information is compromised. For example, as described above, the recognition of tampering can first occur in the (first) component itself. In these instances, the first component must forward information that tampering has been recognized to the central device for mitigating software tampering 25. Here, an intruder may tamper with the software of the first component, preventing the first component from recognizing possible tampering and / or forwarding this information. However, this intervention may result in the (first) component no longer transmitting the signal expected by the central device for mitigating software tampering, i.e., this signal is absent from the perspective of the central device for mitigating software tampering. Thereby, the central device for mitigating software tampering can, in some circumstances, recognize the possibility of tampering (and implement countermeasures) even when the first component has been compromised by tampering.

[0032] Similarly, a module (e.g., a security module) of the first component 27c can infer possible tampering in the absence of a signal (message) from the central device for mitigating software tampering 25. This can be particularly advantageous when the module (e.g., a security module) of the first component 27c is itself unaffected by software tampering, but must have communication access to a potentially compromised module of the first component 27. In this case, in some situations, the central device for mitigating software tampering 25 may not be able to securely communicate with the module (e.g., a security module) of the first component 27c (e.g., to implement countermeasure steps implemented by the module).

[0033] The protection of the communication (e.g., the messages or signals described above) can be realized in various ways. In some examples, the source at the first component 27c is the security module of the first component (which is described in more detail below with respect to FIG. 3). The security module may be separate from the remaining modules of the first component 27c in terms of its hardware and / or software (e.g., it may be a separate physical module). The security module may introduce or implement the communication between the central device and the first component, thereby (cryptographically) protecting the communication. At the side of the central device 25 for mitigating software tampering, a security module may also be incorporated into the communication (e.g., all functions of the central device 25 for mitigating software tampering may be performed by a hardware security module).

[0034] Additionally or alternatively, for cryptographic protection, communications between the first component 27c and the central device for mitigating software tampering 25 may be encrypted. For this purpose, any suitable encryption method (e.g., asymmetric or symmetric encryption method) may be used. For example, a message (or messages) from the first component 27c indicating possible software tampering (e.g., sent by the security module of the first component) may be encrypted. The message may then be decrypted by the central device for mitigating software tampering 25.

[0035] Additionally or alternatively, communications may be provided with digital signatures or MAC tags ("Message Authentication Code" tags) for cryptographic protection. In these examples, the corresponding recipient (e.g., central device 25 for mitigating software tampering or first component 27c) may check the authenticity of the message sender (and introduce further steps only if the sender is authenticated). For example, a message (or messages) from first component 27c indicating possible software tampering (e.g., sent by the security module of the first component) may be provided with a digital signature from first component 27c.

[0036] Additionally or alternatively, for cryptographic protection, communications may be protected using authenticated encryption techniques (ie, communications are both encrypted and authenticated). Additionally or alternatively, communications can be masked for cryptographic protection. For example, signals indicating possible intrusions can be hidden within the in-vehicle network data stream (e.g., by steganography methods, by methods to prevent analysis of the length of the messages in the communications, such as message padding, by methods to prevent analysis of the time of the communications, such as random transmission of messages, or by countermeasures against side-channel attacks). In some examples, signals indicating possible intrusions can be hidden in other messages of the central device 25 or the first component 27c to mitigate software tampering. For example, a message (or messages) of the first component 27c indicating possible software tampering (e.g., sent from the security module of the first component) can be hidden in one or more other messages of the first component 27c. In other examples, repeatedly transmitted signals (whose absence indicates possible software tampering) can be hidden within other messages.

[0037] Additionally or alternatively, messages can be provided with timestamps for cryptographic protection of communications, and each recipient can reject messages older than a predetermined threshold age.

[0038] In each of the above cases, cryptographic protection of communications can make it difficult (and in the best case impossible) for an intruder to prevent the information necessary to recognize possible tampering from reaching the central device 25 or the first component 27c and / or modules of the first component 27c for mitigating software tampering.

[0039] As already mentioned, in some examples, detection of tampering of the software of the first component 27c can be performed locally at the first component 27c (step 111 in FIG. 1). To that end, the first component 27c may include a (tamper) detection device 81a. The (tamper) detection device 81a may be located in a security module of the first component. In some examples, the (tamper) detection device 81a may transmit a signal indicating possible tampering of the software of the first component 27c (step 113 in FIG. 1).

[0040] Alternatively or additionally, the (tamper) detection device 61b of the central communication interface of the vehicle 20 can (remotely) detect tampering of the control unit 27c and generate a signal for the central device for software tampering mitigation 25 (which in the example of FIG. 3 is also located in the central communication interface of the vehicle 20). Thus, in some examples, the central device for software tampering mitigation 25 is also designed for central detection of software tampering of multiple components 27a, c-f of the in-vehicle network.

[0041] Alternatively, or additionally, a detection device in the remote system 30 can (remotely) detect tampering with the control device 27c and generate a signal for the central device 25 to mitigate the software tampering. In this example, the signal can be received via an interface in the vehicle. However, when tamper detection is also performed in the vehicle, the time period until tamper mitigation can be shortened in some cases.

[0042] The various detection devices 81a, 61b (in particular the detection devices 81a, 61b located in the vehicle) may be detection devices already present in the (vehicle) network. As mentioned above, software tampering can also be detected in several known ways.

[0043] Tamper detection can be performed in every conceivable manner: for example, software can be checked at startup ("secure boot") and / or during operation ("runtime tamper detection") by one or more methods for checking the veracity and / or authenticity of the software (e.g., using one or more digital signatures or other cryptographic methods).

[0044] In other examples, a signal can be generated by the components described in the preceding section, the absence of which indicates possible tampering. For example, the (tamper) detection device 81 a of the controller 27 c can generate a signal (e.g., periodically or upon the occurrence of a particular event), the absence of which can indicate tampering with the software of the controller 27 c.

[0045] In response to recognizing possible software tampering of a first component 27c of the components of the in-vehicle network of the vehicle 20 (e.g., recognizing the reception of a signal or the absence of a signal), the central device for mitigating software tampering 25 implements countermeasures 103 for mitigating tampering of the first component (which are subsequently executed in the in-vehicle network), possible countermeasures being described in more detail below.

[0046] Aspects of the first component 27c will now be further described with reference to FIG. 3 (other components of the present disclosure may similarly have the described structure). The first component 27c includes a memory 91. For example, the memory 91 may be a non-volatile memory (e.g., an EPROM memory or a flash memory). The memory 91 may be designed to store at least one software component for the first component 27c (e.g., for controlling the first component 27c). The memory 91 may be the program memory of the first component 27c. The memory 91 may include only a portion of the total memory of the first component 27c. Alternatively or additionally, the memory 91 may be distributed across multiple hardware modules and / or logical segments.

[0047] The first component 27c may include a security module 93. The security module 93 may be separate from the remaining modules of the first component 27c in terms of its hardware and / or software (e.g., a separate physical module or a standalone peripheral module). The security module may include one or more dedicated processors (e.g., at least one cryptographic accelerator). In other examples, the security module 93 may include one or more cores of a multi-core processor or other elements of a higher-level component (elements statically or dynamically assigned to the security module, which may, for example, constitute one or more cores of a multi-core processor for the security module). Also in this case, the security module (e.g., one or more cores of a multi-core processor) is isolated from the other elements (e.g., physically separated circuitry). In some examples, the security module 93 may be designed to perform one or more cryptographic functions (e.g., the cryptographic functions described further above) to cryptographically protect communications with the central device 25 to mitigate software tampering. In some examples, the communications of first component 27c (which may be analyzed to recognize possible tampering) may originate from security module 93. Additionally or alternatively, security module 93 of first component 27c may be designed to detect possible tampering (e.g., may include detection device 81a described above).

[0048] In some examples, the security module 93 is a hardware security module (HSM). In the example of Figure 3, the security module 93 is an internal security module of the component 27c. In other examples, the security module may be an external security module for the component 27c (e.g., an external security module included in another component of the vehicle 20, e.g., the central device 25 for mitigating software tampering).

[0049] Component 27c additionally includes a processor 94 for executing instructions. As noted above, the term "processor" also includes a multi-core processor, or multiple separate components that assume (and possibly share) the tasks of a central processing unit of an electronic device. In some examples, component 27c may include one or more interfaces 95 designed to communicate over an in-vehicle network transmission path 96. As seen in FIG. 3 , processor 94, security module 93, or both may have direct access to one or more interfaces 95 for communicating over the in-vehicle network transmission path 96. The transmission path may be a bus system transmission path (e.g., CAN, LIN, MOST, FlexRay, or Ethernet).

[0050] Based on FIG. 4, an exemplary flow of the method of the present disclosure will now be discussed. In FIG. 4, each column depicts the action of a particular component (or one of its modules) or system. Arrows between columns represent communication between the respective units. At the far left, a particular component (the first component 27c of the present disclosure) is depicted (e.g., an embedded system, e.g., a control unit, of the vehicle 20). The component 27c may have two modules: a main unit 403 (which may include, e.g., a processor 94) and a security module 93. The main unit 403 may be designed to provide the functionality of the component within the vehicle (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other operational tasks). In the center column, one of the other components 402 of the in-vehicle network is depicted. At the far right, the operation of the central device 25 to mitigate software tampering is depicted.

[0051] Now, at a certain point in time, as shown in Figure 4, software tampering 410 of the first component 27c (or main unit 403) may occur. The tampering may be detected 404 by the security module 93 of the first component 27c. The tampering may be recognized by the central device 25 for software tampering mitigation by analyzing communications between the central device 25 for software tampering mitigation and the first component 27c. In the example of Figure 4, this occurs because a signal 411 that would normally (periodically) be sent from the first component 27c is not sent at the expected time. The central device 25 for software tampering mitigation may recognize the absence of the signal and therefore the possible tampering of the software of the first component 27c 412 and may implement countermeasures.

[0052] 4, the countermeasure may include transferring functionality to another component 402. For example, a functionality transfer instruction 413 may be sent from the central device for mitigating software tampering 25 to the another component 402. The another component may then provide the functionality (and possibly send a confirmation 414 to the central device for mitigating software tampering 25).

[0053] Alternatively or additionally, the central device 25 for mitigating software tampering can implement further countermeasures (these countermeasures are implemented in the in-vehicle network). As shown in FIG. 4, the absence of the signal 411 periodically transmitted from the central device 25 for mitigating software tampering to the security module 93 unless tampering is recognized can indicate to the security module 93 that countermeasures should be implemented (and possibly implemented) on its side. The security module can detect the absence 423 (e.g., using the techniques described above). The security module 93 can then change 425 the functionality of the first component 27c. For example, it can deactivate the main unit 403. Alternatively or additionally, the security module 93 can put the main unit 403 into a state (e.g., a reprogramming mode) that allows the tampered software to be reset. The first component 27c can then no longer provide functionality (or can provide functionality only to a limited extent).

[0054] Additionally, the detection of tampering may be communicated to a central device 25 for software tamper mitigation. 4 shows that the change in functionality of the first component 27c is completed in time after the transition of functionality to another component 402. In other examples, both actions can be performed in the reverse order or simultaneously (e.g., within one second).

[0055] The tampering can be repaired (eg, by resetting 427 the software of the first component 27c as described further below). The following sections describe aspects of the central device 25 for mitigating software tampering. The example of FIG. 2 illustrates a central device 25 for mitigating software tampering. In some cases, a vehicle may include only one central device 25 for mitigating software tampering, designed to mitigate tampering of multiple components 21-24, 27a-f (e.g., all components of the vehicle that are capable of repairing software tampering, or a subset of these components). In other examples, a vehicle may have multiple central devices for mitigating software tampering, each part of an in-vehicle network and assigned to multiple components of the in-vehicle network (i.e., capable of repairing tampering in the software of its assigned component). However, in each case, the central device for mitigating software tampering is separate from its assigned component. The central device 25 for mitigating software tampering may, in some cases, also be designed to mitigate tampering of its own software and / or the software of components with which the central device 25 for mitigating software tampering is integrated.

[0056] 2, the components whose software tampering can be repaired using the techniques of the present disclosure include multiple control devices 27a-f. As noted above, the techniques of the present disclosure are not limited to control devices and can generally be used for each component of the in-vehicle network of vehicle 20. However, because control devices 27a-f within a vehicle generally have limited hardware resources and / or functionality, the techniques of the present disclosure may in some cases be particularly advantageous for control devices.

[0057] 2, the controllers 27a-f are divided into several domains 26a-n. The domains may be functional domains and / or local domains of the vehicle 20. A functional domain may include various components of the vehicle involved in providing a particular function of the vehicle (e.g., engine control, powertrain control, infotainment, air conditioning, etc.). A local domain may include various components of the vehicle that are physically located in a particular area of ​​the vehicle (e.g., "rear right," "front left," "interior front," etc.).

[0058] On the other hand, the domains 26a-n may include components 27a, 27d that function as central communication nodes for the respective domains 26a-n and / or assume control functions for the respective domains 26a-n. In some examples, a central device for software tampering mitigation may be part of the components 27a, 27d that function as central communication nodes for the respective domains 26a-n and / or assume control functions for the respective domains 26a-n. This central device for software tampering mitigation may be provided in addition to or as the only central device for software tampering mitigation (e.g., a central device for software tampering mitigation as part of a central communication interface of an in-vehicle network) (see further above). Alternatively or additionally, the central device for software tampering mitigation may be designed as part of the central control unit 23 of the vehicle. Alternatively or additionally, the central device for software tampering mitigation may be arranged as part of the head unit of the infotainment system (not shown in FIG. 2 ) of the vehicle 20. Further alternatively or additionally, the central device for mitigating software tampering may be located as part of a central computer ("vehicle computer") of an in-vehicle network (which may include multiple central computer "vehicle computers"), which is (significantly) more powerful than the dedicated controllers of the in-vehicle network and can take on the tasks of multiple controllers (possibly in some of the above domains).

[0059] Vehicle 20 may further include a central persistent memory 41 (i.e., memory that stores its information persistently in the vehicle, e.g., for more than one day or more than one week, and / or while the vehicle is idle). In some examples, persistent memory 41 may include flash memory. In the example of FIG. 2, persistent memory 41 is located at or directly connected to a central communication interface of vehicle 20. As described above, central device for software tamper mitigation 25 may also be located at the central communication interface of vehicle 20. When the central device for software tamper mitigation is (additionally or alternatively) located in a different component, persistent memory may additionally or alternatively be located in the same component. In this way, data stored in persistent memory can be used for tamper mitigation by the central device for software tamper mitigation. However, in other examples, the central device for software tamper mitigation and persistent memory may be located in different components of the in-vehicle network (and the central device for software tamper mitigation can access the persistent memory over the network).

[0060] The persistent memory 41 may be designed to simultaneously store the software components 42a, 42c-n for each of the multiple components 27a-f, and for this purpose, the persistent memory 41 may be designed to have a memory capacity of more than 256 MB (preferably more than 5 GB).

[0061] Countermeasures against tampering may include resetting the software of the component (also referred to in this disclosure as the "first component") whose software tampering has been recognized (e.g., using software components 42a, 42c-n stored in central persistent memory 41 for each component). Further aspects of this further countermeasure are discussed further below with reference to Figures 5 and 6.

[0062] In some examples, the software components 42a, 42c-n included in the central persistent memory 41 may be based on (e.g., generated from or correspond to) software update information 32a, 32c-n relating to each of the plurality of components 27a-n.

[0063] The software update information 32a, 32c-n can be received via an interface 21 of the vehicle 20. The interface 21 can be a wireless interface (as shown in FIG. 2), but in other examples can be a wired interface 22 (e.g., an interface for on-board diagnostics). The vehicle can be designed to receive the software update information 32a, 32c-n from the remote system 30 via one of the interfaces 21, 22. As shown in FIG. 1, the remote system 30 can select 107 the software update information 32a, 32c-n for the corresponding vehicle and transmit it to the vehicle 20 via one of the interfaces 21, 22. The remote system 30 can be any system (e.g., cloud storage and / or a distributed system) suitable for providing the software update information 32a, 32c-n. In addition to providing the software update information 32a, 32c-n, the remote system 30 can assume additional functions during vehicle operation (e.g., monitoring and / or control functions for the vehicle 20).

[0064] In some examples, software updates 32a, 32c-n for multiple components (e.g., controllers 27a, c-n) are included in a software bundle or software container 31 (i.e., the software updates are provided in a bundle). The software bundle or software container 31 (often of considerable size) is transmitted to the vehicle 20 at a particular time. As described above, the transmitted software updates 32a, 32c-n are used in the vehicle 20 to update the software of the multiple components 27a-f. To this end, the software updates 32a, 32c-n obtained from the remote system 30 may undergo one or more preparatory steps (e.g., deployment, signature verification, etc.). Additionally or alternatively, the software updates may repair vulnerabilities in the vehicle's on-board network.

[0065] Additionally or alternatively, software updates 32 a, 32 c-n (eg, in software bundles or software containers) may be received via the wired interface 22.

[0066] The software update information 32a, 32c-n may be stored in the persistent memory 41 (e.g., before being used to update the software of the components 27a, c-n) as software components 42a, 42c-n for the plurality of components 27a, c-n, before or after a possible preparatory step. The stored software components 42a, 42c-n for the plurality of components 27a, c-n are then available to the central software tamper mitigation device 25 for mitigating tampering in the plurality of components 27a, c-n. This mitigation may occur after the completion of the software update of each of the plurality of components 27a, c-n (e.g., until receipt of further software update information 32a, 32c-n).

[0067] In this way, the techniques of the present disclosure can, in some instances, address components already present in the vehicle, such as the persistent memory 41 used in the vehicle 20's software update process. In some cases, this can result in significant savings in components (as noted above, the memory required to store the software bundle or software container 31 of the software update information 32a, 32c-n can be significant). Additionally or alternatively, providing additional resources (e.g., memory) in individual components can be avoided, which can also reduce complexity and therefore error-proneness and / or cost. Additionally or alternatively, the information in the persistent memory 41 can, in many situations, be available quickly and independently of the availability of the vehicle's communication channels. This can improve the reaction time of tamper mitigation methods.

[0068] In the techniques of this disclosure, the countermeasures for mitigation may be implemented substantially without the assistance of systems (e.g., remote system 30) external to vehicle 20. For example, the countermeasures may be introduced by central device for mitigating software tampering 25 without requiring communication with systems external to vehicle 20 (during this process, vehicle 20 may fully communicate with systems external to vehicle 20 for other purposes). Additionally or alternatively, central device for mitigating software tampering 25 (or another component of the in-vehicle network) may implement the countermeasures without requiring communication with systems external to vehicle 20.

[0069] In some examples, techniques of this disclosure may include selecting one countermeasure from among multiple countermeasures based on contextual information about the vehicle. The contextual information may include information about an operating state of the vehicle 20 and / or information about predetermined rules for operation of the vehicle 20.

[0070] The operating state may be the vehicle's driving state (e.g., driving at a high speed, driving at a low speed, performing a particular driving maneuver, etc.), but may also be the vehicle's operating state while not moving. Alternatively or additionally, the context information about vehicle 20 may include ambient information and / or vehicle component status information.

[0071] The rules for the operation of the vehicle 20 may include predetermined safety standards (which in turn may depend on the operating state of the vehicle 20, determining, for example, when and in what dependencies measures relating to particular components may be introduced).

[0072] The context information may be stored at least in part in a memory (e.g., central persistent memory 41) of the central device for software tamper mitigation 25 for use in selecting a countermeasure (e.g., a portion of the context information including information regarding predetermined rules for operation of vehicle 20). The context information may, in some examples, be updated externally to vehicle 20 (e.g., as part of software update information 32b for the central device for software tamper mitigation 25 or for the component in which the central device for software tamper mitigation 25 is located).

[0073] In some examples, various countermeasures may be available to mitigate a particular tampering with the software of component 27a, c-n (the possible countermeasures are described in more detail below). Here, context information may be used to select one of the available countermeasures. In some examples, the one that most comprehensively restores the target state of the component (i.e., most comprehensively repairs the tampering) may be selected from among multiple available countermeasures. On the other hand, in some situations, available countermeasures may be excluded (e.g., when they would violate certain security criteria) based on rules contained in the context information.

[0074] For example, a first countermeasure may enable more extensive tamper mitigation than a second countermeasure, but on the other hand, may result in more serious intervention into vehicle components (and therefore a greater risk of disturbances that may be caused by the mitigation process itself). A second countermeasure may enable less extensive tamper mitigation compared to the first countermeasure, but on the other hand, may also result in less serious intervention into vehicle components. In this case, the first countermeasure may be selected in a first context (represented by the context information), and the second countermeasure may be selected in a second context (represented by the context information). In an illustrative example, the first context may be a context in which the vehicle is traveling at high speed, and the second context may be a context in which the vehicle is stationary. In other cases, the context information may include security criteria, compliance with which prohibits implementation of the first countermeasure in a first situation but permits it in a second situation.

[0075] In some examples, the countermeasures may include immediately (e.g., within five minutes or one minute) resetting the software of the first component 27a, c-f for which tampering has been detected using software components 42a, c-n stored in the central persistent memory 41 (e.g., generated based on received software update information), and later resetting the software of the component 27a, c-f using software components 42a, c-n for each component 27a, c-f. On the other hand, an immediate reset may be precluded in certain contexts (e.g., due to security criteria). For example, the later reset may be performed within a period until the next boot process of each component 27a, c-f.

[0076] Next, further aspects of the techniques of the present disclosure will be described based on Figures 5 and 6. Figure 5 shows the in-vehicle network according to Figure 2, where the first component 27c has been tampered with. Figure 6 shows the in-vehicle network according to Figure 2, where the tampering of the first component 27c has been repaired.

[0077] We first describe in more detail some aspects of detecting software tampering in components 27a, c-f of vehicle 20. As noted above, the techniques of this disclosure may involve recognizing possible software tampering in one of the components of the in-vehicle network, which in some examples includes receiving a signal. This signal can be generated in a variety of ways.

[0078] First, tampering with the software of the components 27a, c to f can be detected, which can be done locally by corresponding (tampering) detection devices of the corresponding components.

[0079] 5, the software of one of the control devices 27c (the "first component" in some examples of this disclosure) has been tampered with. A tampered software component 71 has been introduced.

[0080] Now, with reference to Figures 5 and 6, further aspects of the solution for resetting the software of the first component 27c using a software component 42c for the first component 27c stored in the central persistent memory 41 will be discussed.

[0081] The central device for tampering mitigation 25 can select a countermeasure based on the detection of tampering of the first component 27c. In the example of FIGS. 5 and 6, a reset of the software of the first component 27c is selected as the countermeasure. The reset may include restoring the software to its last authenticated state. This may include deleting and / or overwriting part or all of the software of the first component 27c (e.g., a control device). The deletion and / or overwriting of part or all of the software of the first component 27c can be performed remotely (i.e., via an in-vehicle network connection) by the central device for tampering mitigation 25. In this manner, the tampered software component 71 or parts 81a and 81b thereof can be replaced with the authentic (i.e., untampered) software component 52c or parts 53a and 53b thereof to repair the tampering.

[0082] The authentic (i.e., untampered) software 52c can be recalled from persistent memory 41. As mentioned above, persistent memory 41 can store software component 42c in a directly usable form or in a form that can be used only after one or more processing steps to reset the tampered software component 71 or first component 27c.

[0083] In some examples, the central device for tamper mitigation 25 can implement measures to ensure the authenticity of the software components 42 a, c-n used to reset the software of the components. For example, an authenticity check (e.g., based on a digital signature or another security feature) can be performed before using the software components 42 a, c-n. For the authenticity check, the central device for tamper mitigation 25 can use the functionality of the components in which the central device for tamper mitigation 25 is integrated.

[0084] In some examples, persistent memory 41 may include multiple versions of a software component for a particular component of the in-vehicle network, in which case central tamper mitigation device 25 may select one of the versions (e.g., the latest version of the software component).

[0085] In the previous sections, reference was made to measures for mitigating tampering of a first component 27c of the in-vehicle network with reference to Figures 5 and 6. However, the central device for mitigating tampering 25 is configured to introduce measures regarding tampering of software of one or more further components of the plurality of components 27a, d-f at a different time to or simultaneously with the mitigation of tampering of software of the first component 27c.

[0086] In some examples, the central tamper mitigation device 25 is designed to recognize possible software tampering of further components 27 a, d-f of the in-vehicle network and to implement further countermeasures to mitigate tampering of the further components 27 a, d-f. The detection of tampering, the implementation of countermeasures, and the enforcement of the countermeasures can proceed as described above. For example, the tampered software components of the further components 27 a, d-f can be reset.

[0087] In this way, a single central tamper mitigation device can be responsible for (i.e., repair software tampering of) multiple components (e.g., controllers in different domains) that are remote from it within the in-vehicle network.

[0088] The preceding section mentioned software reset of components as an exemplary further measure introduced by a central device and implemented in the in-vehicle network to mitigate tampering.

[0089] In some examples, the central device for tamper mitigation may alternatively or additionally introduce other further measures implemented in the in-vehicle network. In some examples, the further countermeasure against tampering may include blocking the first component 27c (whose software has been tampered with) from communicating over the in-vehicle network. Blocking communications can prevent the tampered software of the first component 27c from causing damage over the in-vehicle network. On the other hand, the tampered software can still perform the functions of the first component 27c (e.g., for a certain period of time). For this reason, in some cases, blocking the first component 27c's communications over the in-vehicle network may be preferable to resetting the software of the first component 27c (e.g., in a context where failure of the first component 27c is unacceptable or undesirable, at least in the short term). The further countermeasure of resetting the software of the first component 27c can be introduced and implemented subsequent to the further countermeasure of blocking the communications of the first component 27c (e.g., in a modified context).

[0090] Alternatively or additionally, further countermeasures against tampering may include blocking the communication of a group of components, including the first component 27c, via the in-vehicle network. In the example of FIG. 3, the first component 27c may be included in the first domain 26a together with further components 27a, b. Blocking the communication of a group of components via the in-vehicle network is similar to blocking individual components as described above. Again, this prevents the group of components from causing damage in the in-vehicle network. Blocking the communication of a group of components via the in-vehicle network can also be implemented by introducing a further countermeasure of resetting the software of the first component 27c (e.g., with a changed context) at a later point in time.

[0091] In the preceding sections, the techniques of the present disclosure have often been described in terms of respective methods. The present disclosure also relates to systems designed to perform the methods of the present disclosure. The systems may include (e.g., be integrated into) one or more components of an in-vehicle network of a vehicle. The in-vehicle network may also include devices that are only temporarily included in the in-vehicle network (e.g., mobile devices that are in the vehicle and integrated into the in-vehicle network). In other examples, the systems may also include remote systems.

[0092] As mentioned above, the central device for mitigating software tampering may be a standalone device (i.e., a dedicated module with its own hardware and software resources that is part of the in-vehicle network and can communicate with other components of the in-vehicle network). However, in other cases, the central device for mitigating software tampering is integrated into another (existing) component of the in-vehicle network. In this case, the central device for mitigating software tampering may be configured as a software module (a module inserted into the software of the component). In other cases, the central device for mitigating software tampering may comprise at least some dedicated hardware components (together with other hardware components of the component in which it is integrated). As also mentioned, the other component may be a central communication interface of the in-vehicle network, a central computer ("vehicle computer"), or another component with relatively high-performance hardware.

[0093] In some examples, an existing component of the in-vehicle network (e.g., a central communication interface for the vehicle or vehicle domain, a central computer for the vehicle, or a head unit for an infotainment system) can be configured as a central device for mitigating software tampering through software updates of the components of the in-vehicle network.

[0094] The central device for mitigating software tampering or another component in which it is integrated may include at least one processor (possibly with multiple cores) and a memory containing instructions that, when executed by the processor, perform the steps of the methods of the present disclosure. The present disclosure further relates to an in-vehicle network for a vehicle including at least one central device for mitigating software tampering according to the present disclosure and multiple components of the in-vehicle network. The in-vehicle network may be designed to perform the techniques of the present disclosure (as described above).

[0095] However, the present disclosure also relates to an in-vehicle network for a vehicle including at least one central device for mitigating software tampering according to the present disclosure and multiple components of the in-vehicle network, which may be designed to perform the methods of the present disclosure, and which may include devices that are only temporarily included in the in-vehicle network (e.g., mobile devices that are in the vehicle and integrated into the in-vehicle network).

[0096] The present disclosure further relates to a vehicle that includes or is part of a system according to the present disclosure and / or that includes an in-vehicle network according to the present disclosure. The present disclosure further relates to computer programs designed to carry out the methods of the present disclosure.

[0097] The present disclosure further relates to a computer readable medium (eg, a DVD or solid state memory) containing the computer program of the present disclosure. The present disclosure further relates to signals (eg, electromagnetic signals according to wireless or wired communication protocols) encoding the computer programs of the present disclosure. [Explanation of symbols]

[0098] 20 vehicles 21, 22 Communication Interface 23 Central Control Unit 21-24, 27a-f Multiple components 25 Central Device for Mitigating Software Tampering 26a~n domain 27a~f Control device 30 Remote Systems 31 Software bundles or software containers 32a, 32c~n software update information 41 Persistent Memory 42a, 42c~n Software Components 52c Software Components / Software 53a, 53b Part of software component 52c 61b Detection Device 71 Software Components 81a Detection Device 81a, 81b Part of software component 71 91 memory 93 Security Module 94 processors 95 Multiple Interfaces 96 Transmission path for in-vehicle network 402 Another Component 403 Main Unit

Claims

1. 1. A computer-implemented method comprising: analyzing communications secured by one or more cryptographic methods between a first component (27c) of a plurality of components (27a-f) of an in-vehicle network of a vehicle (20) and a central device (25) for mitigating software tampering, the communications comprising: said central device for tamper mitigation (25) being part of said in-vehicle network and designed for software mitigation in each of said plurality of components (27a-f) of said in-vehicle network; - recognizing (101) in a central device (25) for mitigating software tampering based on said analysis of said communication a possible tampering of said software of said first component (27c); - implementing (103) measures to mitigate said tampering of said software of said first component (27c) by a central device (25) for mitigating said tampering; A method comprising:

2. The communication of the first component (27c) originates from a security module (93) of the first component (27c), Optionally, said security module (93) is a hardware security module of said first component (27c). The method of claim 1.

3. 3. The method of claim 2, wherein the security module (93) of the first component (27c) is further designed to detect possible tampering.

4. 3. The method of claim 2, wherein the security module (93) of the first component (27c) has direct access to a transmission path (95) of the in-vehicle network, optionally via a bus interface of the first component (27c).

5. 2. The method of claim 1, wherein the communication includes a message from the first component indicating the possibility of tampering with the software.

6. The method of claim 1 , wherein the analyzing includes verifying the absence of a message from the first component (27c).

7. 2. The method of claim 1, wherein the first component (27c) and the central device for mitigating software tampering (25) are designed to repeatedly exchange messages.

8. The method of claim 1 , wherein the countermeasure against the tampering includes resetting the software of the first component (27c).

9. A system designed to carry out the method according to any one of claims 1 to 8.

10. A central device (25) for mitigating software tampering of a plurality of components (27a-f) of an on-board network of a vehicle (20), the central device (25) being designed to perform the method according to any one of claims 1 to 8.

11. An in-vehicle network for a vehicle (20), comprising: A central device (25) for mitigating software tampering according to claim 10; a plurality of components (27a-f) of the in-vehicle network; In-vehicle networks, including:

12. A vehicle (20) including a system according to claim 9.

13. A computer program for causing a system to carry out the method according to any one of claims 1 to 8.

14. A computer-readable recording medium having the computer program according to claim 13 recorded thereon.

Images