Reduction in manipulation of vehicle software

Abstract

To reduce manipulation of vehicle software.SOLUTION: A method includes a step of, in a central device for reducing manipulation of software, recognizing the possibility of manipulation of software of a first component of a plurality of components for an on-vehicle network of a vehicle. The central device is a part of the on-vehicle network and is designed to reduce manipulation of software in each of the plurality of components for the on-vehicle network. The method further includes a step of introducing measures for reducing manipulation of the software of the first component, and a step of executing the measures for reducing manipulation of the software of the first component, by the central device for reducing manipulation. The measures for manipulation include resetting the software of the first component using a security module of the first component and / or an invariant module of the first component.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] It relates to vehicle software.

Background Art

[0002] In recent years, vehicles are increasingly being incorporated into open contexts (i.e., a vehicle has one or more interfaces through which data is received and / or transmitted during operation, and in turn they are used for the operation of the vehicle). Furthermore, the complexity of vehicle components, particularly their software, continues to increase. Also, vehicle software is updated during operation in an even more diverse manner.

[0003] As a result, the possibilities for tampering with the software of vehicle components become more diverse.

Summary of the Invention

Problems to be Solved by the Invention

[0004] In some ways of the current state of the art, detecting tampering and especially reducing it (i.e., repair such that a defined (safe) state is achieved) involves a significant amount of effort and thus a time delay. For example, within the framework of factory maintenance, the tampered software of a component (e.g., a control device) can be reset and thus the tampering can be repaired. In other techniques, a remote computer system can request the software, and by this technique, the tampered software of a component (e.g., a control device) is reset and thus the tampering is repaired. In either case, there can be a significant period between detecting tampering and reducing it. Depending on the situation, the operation of the vehicle is hindered during this period (e.g., a given safety standard is no longer met). In some cases, the vehicle may become inoperable or its functionality may be significantly impaired. Therefore, an improved technique for reducing software tampering is desirable.

Means for Solving the Problems

[0005] A first general aspect of this disclosure relates to a computer implementation method. The method includes the step of recognizing the possibility of software tampering in a first component of a plurality of components of a vehicle's in-vehicle network in a central device for mitigating software tampering. The central device for mitigating tampering is part of the in-vehicle network and is designed to mitigate software tampering in each of the plurality of components of the in-vehicle network. The method further includes the steps of the central device for mitigating tampering introducing measures to mitigate software tampering in the first component, and implementing measures to mitigate software tampering in the first component. The measures against tampering include resetting the software of the first component using the security module and / or immutability module of the first component.

[0006] A second general aspect of this disclosure relates to a system designed to perform the method according to the first general aspect. A third general aspect of this disclosure relates to an in-vehicle network for a vehicle. The in-vehicle network includes a plurality of components, including a first component, and a central device for mitigating software tampering. The in-vehicle network is designed to perform the method according to the first general aspect.

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

[0008] The techniques of the first to fourth general aspects of this disclosure may, in some cases, have one or more of the following advantages: First, in some situations, it may be possible to safely reset the tampered software of a component (for example, by replacing it with an untampered software component). The use of security modules and / or immutability modules of the first component during reset can, in some cases, ensure that an intruder cannot (further) compromise the reset process. This is achieved by the techniques of this disclosure by employing modules in the reset process that, in some cases, cannot be compromised very easily (ideally not at all) by an intruder. This characteristic can be provided by both security modules and immutability modules. That is, a security module (e.g., a hardware security module, HSM) may have additional security features compared to other modules of the first component and may therefore be more difficult to tamper with than other modules. An immutability module may, in essence, not allow any changes to its software and / or functionality while in operation. This also makes tampering with this module more difficult, and in the best case, impossible. These modules can be used in various ways in the reset process, for example, by putting a component into a reset mode that allows software resetting. As an addition or alternative, these modules can receive software components for resetting. In either case, each process can be protected from tampering.

[0009] Secondly (and as a result of the first benefit), the techniques of this 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 scale more easily than some techniques of the current technology and / or can be used in older vehicles (vehicles not designed according to the latest standards). For example, a central device for mitigating tampering can be modified relatively easily to "monitor" additional components. In some cases, this requires little or no modification of the components being "monitored," which facilitates use in older vehicles. In some cases, the central device for mitigating tampering itself can also be retrofitted by a software update. For example, an existing component of the vehicle (e.g., the vehicle's central communication interface or the vehicle's central computer) can be given (additional) functionality from the central device for mitigating tampering by a software update.

[0010] Some terms are used in this disclosure as follows: In other words, a “component” (of an in-vehicle network) in this disclosure comprises 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 a group of separate components that undertake (and possibly share tasks with) a central processing unit of an electronic device. Components can independently perform tasks (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other operational tasks). However, in some examples, components can also be controlled by other components. Components may be physically isolated (e.g., using their own housing) or integrated into a higher-level system. Components may be vehicle control devices or communication devices. Components may be embedded systems. Components may include one or more microcontrollers.

[0011] An "embedded system" is a component that is integrated (embedded) into a technical context. Here, the component undertakes measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other operational tasks.

[0012] A "(dedicated) control unit" is a component that controls one (only) function of a vehicle. A control unit can, for example, be responsible for engine control, brake system control, or assist system control. Here, "function" can be defined at various levels of the vehicle (for example, a single sensor or actuator can be used for a function, but also a number of assemblies grouped together into a larger functional unit).

[0013] The terms “software” or “software component” can essentially refer to any part of the software of a component of this disclosure (e.g., a control device). In particular, a software component may also be a firmware component of a component of this disclosure. Firmware is software embedded in a (electronic) component that performs its basic functions therein. Firmware is functionally closely connected to each piece of hardware of the component (such that one is unavailable without the other). Firmware may be stored in non-volatile memory such as flash memory or EEPROM.

[0014] The terms “update information” or “software update information” include all data that forms the software component of the component according to this disclosure, either directly or after the corresponding processing step. The update information may include executable code or code that has not yet been compiled (code stored in the memory of the corresponding component).

[0015] The term “tampering” in this disclosure includes any change to the software of a vehicle component. Such changes may result from an attack (i.e., intentional exercise of influence by a third party), but may also result from unintentional or unintended consequences.

[0016] The term "vehicle" includes any device that transports occupants and / or cargo. A vehicle may be an automobile (e.g., a passenger car or truck), but may also be a railway vehicle. However, levitation devices and flying devices may also be vehicles. A vehicle may be at least partially autonomous, or may be assisted.

[0017] An "in-vehicle network" can be any internal network within a vehicle through which the vehicle's components communicate. In some examples, an in-vehicle network is a short-range network. An in-vehicle network can use one or more short-range communication protocols (e.g., two or more short-range communication protocols). A short-range communication protocol may be a wireless or wired communication protocol. A short-range communication protocol may include a bus protocol (e.g., CAN, LIN, MOST, FlexRay, or Ethernet). A short-range communication protocol may include a Bluetooth® protocol (e.g., Bluetooth 5 or later) or a WLAN protocol (e.g., a protocol from the IEEE 802.11 family, e.g., 802.11h or later). An in-vehicle network may include an interface for communicating with systems outside the vehicle and can therefore be incorporated into other networks. However, systems outside the vehicle and other networks are not part of the in-vehicle network.

[0018] The phrase "recognition of 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 may occur. [Brief explanation of the drawing]

[0019] [Figure 1] This is a flowchart of the techniques used in this disclosure. [Figure 2] This figure shows the components of an in-vehicle network in a vehicle in which the techniques of this disclosure can be used. [Figure 3] This diagram shows exemplary components of an in-vehicle network. [Figure 4] This figure shows a flowchart illustrating an exemplary method of the present disclosure. [Figure 5] This figure shows the in-vehicle network as shown in Figure 2, where the first component has been tampered with. [Figure 6]FIG. 2 shows an in-vehicle network in which tampering of the first component has been repaired. DETAILED DESCRIPTION OF THE INVENTION

[0020] First, referring to FIGS. 1 - 3, a vehicle and components in which the techniques of the present disclosure can be implemented, as well as basic aspects of the techniques of the present disclosure, will be discussed. Referring to FIG. 4, an example of the techniques of the present disclosure will be discussed. Based on FIGS. 5 and 6, further aspects of the central device for reducing tampering of software will be described.

[0021] FIG. 1 is a flowchart showing the techniques of the present disclosure. FIG. 2 shows components of an in-vehicle network of a vehicle in which the techniques of the present disclosure can be used. FIG. 3 shows exemplary components of an in-vehicle network.

[0022] In FIG. 1, steps performed by a central device for reducing tampering of software are shown in the central column. Steps performed by specific components (or groups of components) of the in-vehicle network (excluding the central device for reducing tampering of software) are shown in the right column. Steps performed by a remote system (i.e., outside the vehicle) are shown in the left column.

[0023] The technique of the present disclosure includes step 101 of recognizing the possibility of tampering of software of a first component 27c among a plurality of components of an in-vehicle network of vehicle 20. Vehicle 20 is schematically shown in FIG. 2. The vehicle is equipped with an in-vehicle network connecting a plurality of components 21 - 24, 25, 27a - f of vehicle 20 (the in-vehicle network can be configured as described above).

[0024] Vehicle 20 has a central device 25 for mitigating software tampering, which recognizes the possibility of tampering. Therefore, it is part of the in-vehicle network (i.e., it is also part of the vehicle and moves with the vehicle). The central device 25 for mitigating software tampering is designed to mitigate software tampering in each of the multiple components 21-24, 27a-f of the in-vehicle network.

[0025] In some examples, a central device 25 for mitigating software tampering is integrated into the vehicle's central communication interface. 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 communication interfaces 21, 22. Here, the central communication interface can support different communication protocols (for communication on the in-vehicle network or with external systems) and / or implement security features. In other examples, the central device for mitigating software tampering may be integrated into other components (further examples follow below) or designed as a standalone component.

[0026] In some examples, recognition may include receiving a signal indicating software tampering in a first component of a multi-component network in the vehicle 20. The signal may be generated by the central device 25 itself and / or another device to mitigate the software tampering.

[0027] As an addition or alternative, recognition may include recognition of the absence of a (expected) signal (e.g., a signal from a first component or a component monitoring a first component). The in-vehicle network may be designed so that multiple components 21-24, 25, 27a-f or other components transmit signals (e.g., periodically or when a specific event occurs, such as a component being activated) indicating that there has been no software tampering with each of the multiple components 21-24, 25, 27a-f.

[0028] Additionally or alternatively, the recognition may include processing other status information of the in-vehicle network to recognize the possibility of tampering with the software of the first component.

[0029] In response to the recognition of the possibility of software tampering in a first component among multiple components of the vehicle's in-vehicle network (e.g., recognition of signal reception or signal absence), the central device 25 for mitigating software tampering introduces measures to mitigate tampering in the first component 103. Subsequently, the measures to mitigate tampering in the first component are implemented 123.

[0030] Countermeasures against tampering include resetting the software of the first component 27c in which the possibility of tampering has been recognized. The software reset of the first component 27c is performed using the security module and / or immutability module of the first component 27c. The security module and immutability module are discussed in more detail below with reference to Figure 3. In some examples, only the security module or only the immutability module can be used for the reset. In other examples, both the security module and the immutability module can be used for the reset (in some examples, the security module may also be the immutability module). The implementation may include messages and / or instructions from the central device 25 to mitigate software tampering to the security module or the immutability module. After receiving the messages and / or instructions, the security module or the immutability module can perform the corresponding steps. Alternatively, the implementation may include ceasing the transmission of messages from the central device 25 to mitigate software tampering (e.g., messages of the type that are periodically sent from the central device 25 to mitigate software tampering unless the possibility of tampering is detected).

[0031] A reset may involve multiple steps, one or more of which are performed using security modules and / or immutability modules. The use of each module may include one or more means of coordinating a reset, or one or more steps of the reset (for example, a step of sending instructions to other modules of the first component to execute one or more steps of the reset). Alternatively or additionally, the use may include sending and / or receiving data within the framework of a reset.

[0032] In some examples, a software reset may include step 115, which restarts the processor of the first component (the processor being the central processing unit of the component). In some examples, step 115, which restarts, may include shutting down the processor and then starting it up. As an addition or alternative, the restart step may include powering off the processor and then powering it on (e.g., by interrupting and reapplying the processor's power supply voltage). However, in other examples, the restart step may also include resetting the processor to a specific configuration and / or resetting specific parts of the processor (e.g., its registers). In some examples, after the restart, the component's program can be restarted from the beginning.

[0033] A restart can be initiated in various ways. In some cases, the restart step may be initiated by a security module. For example, a security module can force a restart of the processor of the first component 27c. The security module may be specifically designed for this purpose. In some cases, the security module may already have this functionality (to initiate a restart in other situations).

[0034] Alternatively or additionally, the step of restarting the processor of the first component 27c may be initiated by the power supply unit of the vehicle 20. In some examples, the power supply unit may be designed to selectively supply energy to multiple components 27a-f (or groups from those components) of the in-vehicle network. The power supply unit can, for example, selectively turn on or off multiple components 27a-f (or groups from those components) of the in-vehicle network.

[0035] Alternatively or additionally, the step of restarting the processor of the first component 27c may be initiated by the activation of a vehicle's central operating function (e.g., ignition of vehicle 20 or other central operating function).

[0036] In all of the above cases, the reboot can be initiated without using the portion of the first component 27c that may have been compromised by tampering. This reduces the possibility of an intruder interfering with the reset process.

[0037] In some examples, the reset includes step 117, which puts the first component 27c into reset mode (for example, after or during step 115 to reboot) by the security module and / or immutability module of the first component 27c. The reset mode may allow for subsequent software resets. The reset mode may also be, for example, a programming mode for the first component 27c, in which the software of the first component 27c can be modified (this is not possible in the operating mode).

[0038] In some examples, the reset includes the steps of receiving a software component for resetting the software of the first component 27c (for example, after putting the first component 27c into reset mode) 119, and storing the received software component in the memory of the first component 27c. This allows for the replacement of the tampered software component (and the repair of the tampering). The tampered software component may be part of the software of the first component. Alternatively or additionally, the received software component may include configuration information for resetting the software of the first component 27c. The configuration information can be used to change the configuration of the software of the first component 27c. The software component for resetting the software may be transmitted from a central device 25 for mitigating tampering (for example, by techniques further described below) 121.

[0039] As will be further described below, in some examples, the software component for resetting the software of the first component 27c may be stored in the vehicle as part of a software bundle or software container 31 containing software update information for multiple components (for example, stored in the persistent memory 41 of the central device 25 for tamper mitigation). In these examples (but also generally), the software component for resetting the software of the first component 27c can be verified before the reset. This can be done in various ways (and these ways can be combined). In some examples, the software component for resetting the software of the first component 27c can be authenticated. For example, one or more reference authentication elements may be assigned to the software component for resetting the software of the first component 27c (the one or more reference authentication elements may, optionally, be stored in a list along with corresponding reference authentication elements for other software components for resetting the software of other components of the vehicle, and may be stored, for example, in the first component 27c or in another memory of the vehicle). In some examples, one or more reference authentication elements are identified (and, for example, stored in a list) in the vehicle when a software component for resetting the software of the first component 27c, such as a software bundle or software container 31, is received. These reference authentication elements are then used for subsequent comparisons to verify the software component. To verify the software component for resetting the software of the first component 27c (or another software component), the corresponding reference authentication element can be compared before the reset with an authentication element determined in the vehicle with respect to the software component for resetting the software of the first component 27c.Based on the comparison, if the software component for resetting the software of the first component 27c stored in the vehicle is authenticated (for example, the reference authentication element matches the determined authentication element), the software component for resetting the software of the first component 27c can be used. Based on the comparison, if the software component for resetting the software of the first component 27c stored in the vehicle is not authenticated (for example, the reference authentication element does not match the determined authentication element), the reset process can be interrupted. The reference authentication element (and therefore the corresponding determined authentication element) may be configured in various forms. In some examples, the (reference) authentication element may be a hash value (in which case the hash value relating to the genuine software component for resetting the software of the first component 27c is determined and stored in the vehicle as the reference authentication element). In other examples, the (reference) authentication element may be a digital signature (in which case the digital signature relating to the genuine software component for resetting the software of the first component 27c is received and stored in the vehicle as the reference authentication element). In yet another example, the reference authentication element could be a MAC element ("Message Authentication Code") (in which case a MAC element relating to a genuine software component for resetting the software of the first component 27c is received and stored in the vehicle as the reference authentication element). Verification of the software component for resetting the software of the first component 27c can prevent, in some situations, a software component stored in the vehicle that has been tampered with by an intruder within the vehicle after being received from being used to reset the first component 27c. Without verification, if the software component to be used to reset the software is retained within the vehicle (for example, for a longer period, e.g., longer than a day), this retained software component could be tampered with locally within the vehicle and then used to reset the component.

[0040] In some examples, the steps of receiving a software component for resetting the software and storing the received software component may be performed by a security module. Alternatively or additionally, the steps of receiving a software component for resetting the software and storing the received software component may be performed by an immutability module. As mentioned above, in some examples, the software component may be a firmware component. On the other hand, in both cases, the portion of the first component 27c that may be compromised by tampering is not used. In both cases, this makes it more difficult for an intruder to interfere with the process of resetting the software and / or to infiltrate tampered software.

[0041] Herein, with reference to Figure 3, embodiments of the first component 27c will be further described (other components of the present disclosure may similarly have the structures described). The first component 27c comprises memory 91. For example, memory 91 may be non-volatile memory (e.g., EPROM memory or flash memory). 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) (e.g., in the framework of a reset as described above). Memory 91 may be the program memory of the first component 27c. Memory 91 may contain only a portion of the total memory of the first component 27c. Alternatively or additionally, memory 91 may be distributed across multiple hardware modules and / or logical segments.

[0042] The first component 27c may have a security module 93. The security module 93 may be separate from the rest of the first component 27c in terms of its hardware and / or software (for example, it may be a separate physical module or a standalone peripheral module). The security module may include one or more dedicated processors (for example, at least one cryptographic accelerator). In other examples, the security module 93 may include one or more cores of a multicore processor, or other elements of a higher-level component (elements statically or dynamically assigned to the security module, which may constitute one or more cores of a multicore processor for the security module). In this case, the security module (for example, one or more cores of a multicore processor) is isolated from the other elements (for example, the circuit is physically isolated). In some examples, the security module 93 may be designed to perform one or more cryptographic functions (for example, the cryptographic functions further described above) to cryptographically protect communication with the central device 25 to mitigate software tampering. In some examples, as described above, the security module 93 can be used in the reset process of the first component 27c. As an addition or alternative, the security module 93 of the first component 27c may be designed to detect potential tampering (for example, including a detection device 81a, which is further described below).

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

[0044] The first component may also include an immutable module 99. As described above, the immutable module 99 (or its software and / or functionality) may be made immutable during the normal operation of the first component 27c. In some examples, the immutable module 99 includes a boot loader configured to run a (minimal) program for starting the first component. In some examples, the immutable module 99 has read-only or write-protected memory. In some examples, as described above, the immutable module 99 may be used in the reset process of the first component 27c.

[0045] Component 27c also includes a processor 94 for executing instructions. As stated above, the term “processor” can also include a multi-core processor, or multiple separate components that take on (and possibly share) tasks with the central processing unit of the component. In some examples, component 27c may include one or more interfaces 95 designed to communicate over a transmission path 96 of the in-vehicle network. As seen in Figure 3, the processor 94, the security module 93, or both can have direct access to one or more interfaces 95 to communicate over the transmission path 96 of the in-vehicle network. The transmission path may be a transmission path of a bus system (e.g., CAN, LIN, MOST, FlexRay, or Ethernet). Direct access of the security module 93 to one or more interfaces 95 can allow the security module to (securely) receive software components for a reset process (without the involvement of the potentially compromised module of the first component).

[0046] Based on Figure 4, we will now discuss an exemplary flow of the method described herein. Figure 4 shows, in each column, the actions of a specific component (or one of its modules) or system. Arrows between columns represent communication between the respective units. The leftmost column shows a specific component (the first component 27c of this disclosure) (e.g., an embedded system in a vehicle 20, e.g., a control unit). Component 27c may have two modules, a main unit 403 (which may include, for example, a processor 94) and a security module 93. The main unit 403 may be designed to provide functionality for components within the vehicle (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other work tasks). The middle column shows one of the other components 402 of the in-vehicle network. The rightmost column shows the operation of a central device 25 for mitigating software tampering.

[0047] At a specific point in time, software tampering 410 may occur in the first component 27c (or main unit 403), as shown in Figure 4. The tampering may be detected by the security module 93 of the first component 27c 404. The security module 93 can then coordinate a software reset of the first component. For example, the main unit 403 (e.g., the processor) may be restarted 405. Alternatively or additionally, the security module 93 may put the main unit 403 into reset mode, in which the tampered software can be reset (e.g., reprogramming mode). Confirmation 422 that the first component 27c has been put into reset mode may be sent from the security module 93 to the central device 25 for mitigating the software tampering.

[0048] In some cases, a signal received by the security module 93 (for example, from a central device 25 for mitigating software tampering) can trigger a signal to trigger a software reset of the first component 27c. Alternatively or additionally, the security module 93 can use the scheduled absence of a signal 411, which is normally received periodically (for example, from a central device 25 for mitigating software tampering), as a trigger condition for resetting the software of the first component 27c.

[0049] In addition, it is possible to communicate to the central device 25 for software tamper mitigation that tampering has been detected. In the example in Figure 4, this is done by the failure to transmit a signal 411 that would normally (periodically) be transmitted from the first component 27c at the scheduled time. The central device 25 for software tamper mitigation can recognize the absence of the signal, and therefore the possibility of software tampering in the first component 27c 412. Subsequently, the central device 25 for software tamper mitigation can coordinate the transfer of functionality to another component 402. For example, it may send a functionality transfer command 413 to the other component 402. The other component can then provide functionality (and, if applicable, send an acknowledgment 414 to the central device 25 for software tamper mitigation).

[0050] Figure 4 shows that the change in functionality of the first component 27c is completed after the transition of functionality to another component 402 in time. In other examples, both actions can be performed in reverse order or simultaneously (e.g., within 1 second).

[0051] Here, the tampering can be repaired by resetting the software of the first component 27c. In the example of Figure 4, for this purpose, a software component is sent from the central device 25 to the main unit 403 to mitigate the software tampering 416. In other examples, as described above, the security module 93 may receive the software component.

[0052] The following sections describe embodiments of the central device 25 for mitigating software tampering. An example of the central device 25 for mitigating software tampering is shown in Figure 2. In some cases, a vehicle may have only one central device 25 for mitigating software tampering, designed to mitigate tampering to multiple components 21-24, 27a-f (e.g., all components of the vehicle that can repair software tampering, or a subset of these components). In other examples, a vehicle may have multiple central devices for mitigating software tampering, which are part of an in-vehicle network, each assigned to multiple components of the in-vehicle network (i.e., capable of repairing software tampering in the assigned component). However, in both cases, the central device for mitigating software tampering is isolated from the assigned component. In some cases, the central device 25 for mitigating software tampering may also be designed to mitigate its own software and / or the software of the component into which the central device 25 for mitigating software tampering is integrated.

[0053] In the example shown in Figure 2, the multiple components whose software tampering can be repaired using the techniques of the present disclosure include multiple control devices 27a to f. As already stated, the techniques of the present disclosure are not limited to control devices and are basically applicable to each component of the in-vehicle network of the vehicle 20. However, since the control devices 27a to f in the vehicle basically have limited hardware resources and / or functionality, the techniques of the present disclosure may be particularly advantageous for control devices in some cases.

[0054] In Figure 2, the control devices 27a-f are divided into several domains 26a-n. The domains may be functional domains and / or local domains of the vehicle 20. Functional domains may include various components of the vehicle involved in providing specific functions of the vehicle (e.g., engine control, powertrain control, infotainment, air conditioning, etc.). Local domains may include various components of the vehicle physically located in specific areas of the vehicle (e.g., "right rear," "left front," "interior front," etc.).

[0055] On the other hand, domains 26a to n may include components 27a, 27d that function as a central communication node for each of the domains 26a to n and / or assume control functions for each of the domains 26a to n. In some examples, the central device for mitigating software tampering may be part of components 27a, 27d that function as a central communication node for each of the domains 26a to n and / or assume control functions for each of the domains 26a to n. This central device for mitigating software tampering may be provided in addition to, or as the sole, central device for mitigating software tampering (e.g., a central device for mitigating software tampering as part of a central communication interface for an in-vehicle network) (see further description above). Further alternatives or additions, the central device for mitigating software tampering may be designed as part of the vehicle's central control unit 23. Further alternatives or additions, the central device for mitigating software tampering may be located as part of the head unit of the vehicle's infotainment system (not shown in Figure 2). As an alternative or addition, a central device for mitigating software tampering may be located as part of the central computer of the in-vehicle network ("vehicle computer") (the in-vehicle network may include multiple central computers, or "vehicle computers"). The central computer ("vehicle computer") is (considerably) more powerful than the dedicated control units of the in-vehicle network and can take on the tasks of multiple control units (in some of the domains described above, depending on the circumstances).

[0056] Vehicle 20 may further include a central persistent memory 41 (i.e., memory that permanently stores its information in the vehicle, for example, for longer than one day or longer than one week, and / or stores it while the vehicle is idling). In some examples, the persistent memory 41 may include flash memory. In the example in Figure 2, the persistent memory 41 is located in or directly connected to the central communication interface of vehicle 20. As described above, a central device 25 for software tamper mitigation may also be located in the central communication interface of vehicle 20. When the central device for software tamper mitigation is located in a different component (as an addition or replacement), the persistent memory may be located in the same component as an addition or replacement. In this way, the data stored in the persistent memory can be used by the central device for software tamper mitigation for tamper mitigation. However, in other examples, the central device for software tamper mitigation and the 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 via the network).

[0057] The persistent memory 41 may be designed to simultaneously store software components 42a, 42c, and n for each of the multiple components 27a to f. 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).

[0058] Countermeasures against tampering include, as described above, resetting the software of the component (also referred to in this disclosure as the “first component”) whose software tampering has been detected. This can be done using the software components 42a, 42c~n for each component, which are stored in the central persistent memory 41. Further embodiments of this countermeasure will be discussed below with reference to Figures 5 and 6.

[0059] In some examples, software components 42a, 42c~n contained in central persistent memory 41 may be based on software update information 32a, 32c~n for each of a plurality of components 27a~n (for example, generated from them as software update information 32a, 32c~n, or corresponding to them).

[0060] Software update information 32a, 32c~n can be received via interface 21 of the vehicle 20. Interface 21 may be a wireless interface (as shown in Figure 2), but in other examples it may also be a wired interface (not shown in Figure 2). The vehicle may be designed to receive software update information 32a, 32c~n from a remote system 30 via interface 21. As shown in Figure 1, the remote system 30 may select software update information 32a, 32c~n for the corresponding vehicle 107 and transmit it to the vehicle 20 via interface 21 109. The remote system 30 may be any system suitable for providing software update information 32a, 32c~n (e.g., cloud storage and / or distributed systems). In addition to providing software update information 32a, 32c~n, the remote system 30 may undertake additional functions (e.g., monitoring and / or control functions for the vehicle) during vehicle operation.

[0061] In some examples, software update information 32a, 32c-n for multiple components (e.g., control devices 27a, c-n) is contained in a software bundle or software container 31 (i.e., the software update information is provided in a bundle). The software bundle or software container 31 (often of considerable size) is transmitted to the vehicle 20 at a specific time. As described above, in the vehicle 20, the transmitted software update information 32a, 32c-n is used to update the software of the multiple components 27a-f. For this purpose, one or more preparation steps (e.g., deployment, signature verification, etc.) can be performed on the software update information 32a, 32c-n obtained from the remote system 30.

[0062] As an addition or alternative, software update information 32a, 32c~n (e.g., in a software bundle or software container) can also be received via the wired interface 22.

[0063] The software update information 32a, 32c~n can be stored in persistent memory 41 as software components 42a, 42c~n for multiple components 27a, c~n, either before or after a possible preparation step (for example, before being used to update the software of components 27a, c~n). At this time, the stored software components 42a, 42c~n for multiple components 27a, c~n are available to the central device 25 for software tamper mitigation to mitigate tampering in the multiple components 27a, c~n. This mitigation may be performed after the completion of software updates for each of the multiple components 27a, c~n (for example, during the period until further software update information 32a, 32c~n is received).

[0064] In this way, the techniques of the present disclosure can, in some examples, handle components already present in a vehicle, such as persistent memory 41 used in the software update process of the vehicle 20. In some cases, this can lead to considerable savings in components (as mentioned above, the memory required to store the software bundle or software container 31 of software update information 32a, 32c~n can occupy a considerable amount). In addition, or alternatively, it is possible to avoid providing individual components with additional resources (e.g., memory), thereby reducing complexity and thus the likelihood of errors and / or costs. Further additionally or alternatively, the information in persistent memory 41 is available in many situations quickly and independently of the availability of the vehicle's communication channels. This can improve the response time of the tamper-mitigation method.

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

[0066] In some examples, the techniques of the present disclosure may include selecting a measure from among several measures based on contextual information relating to a vehicle. The contextual information may include information about the operating state of the vehicle 20 and / or information about predetermined rules for the operation of the vehicle 20.

[0067] The operating state may be the vehicle's driving state (e.g., high-speed driving, low-speed driving, performing a specific driving operation), or it may be the operating state when the vehicle is not in motion. Alternatively or additionally, contextual information about the vehicle 20 may include ambient information and / or status information of the vehicle's components.

[0068] The rules for the operation of vehicle 20 may include prescribed safety standards (which, on the other hand, may depend on the operating state of vehicle 20, for example, determining when and in what dependencies countermeasures for specific components may be introduced).

[0069] Context information may be stored, at least in part, in the memory of the central device 25 for mitigating software tampering (e.g., central persistent memory 41) for use in selecting countermeasures (in particular, in part of the context information including information about predetermined rules for the operation of the vehicle 20). In some examples, the context information can be updated from outside the vehicle 20 (e.g., as part of the software update information 32b for the central device 25 for mitigating software tampering, or as part of the software update information 32b for the component on which the central device 25 for mitigating software tampering is located).

[0070] In some cases, various countermeasures can be used to mitigate specific software modifications in components 27a, c-n (the possible countermeasures are described in more detail below). Here, contextual information can be used to select one of the available countermeasures. In some cases, from among several available countermeasures, one can be selected that allows for the most extensive restoration of the component's target state (i.e., the most extensive repair of the modifications). On the other hand, in some situations, available countermeasures can be excluded based on rules contained in the contextual information (for example, when they would violate certain security standards).

[0071] For example, the first countermeasure may enable broader mitigation of tampering than the second countermeasure, but on the other hand, it may result in more serious intervention to the vehicle's components (and therefore a greater risk of interference caused by the mitigation process itself). The second countermeasure may enable less broad mitigation of tampering compared to the first countermeasure, but on the other hand, it may also result in less serious intervention to the vehicle's components. In this case, the first countermeasure can be selected in the first context (represented by contextual information), and the second countermeasure can be selected in the second context (represented by contextual information). In an exemplary 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 contextual information may include security standards that, by complying with those security standards, prohibit the implementation of the first countermeasure in the first situation but permit it in the second situation.

[0072] In some examples, the countermeasures may include the steps of immediately (e.g., within 5 minutes or 1 minute) resetting the software of a first component 27a, c~f with respect to the component 27a, c~f whose tampering has been detected, using software components 42a, c~n stored in central persistent memory 41 (e.g., generated based on received software update information), and later resetting the software of components 27a, c~f using software components 42a, c~n for each component 27a, c~f. On the other hand, immediate resets may be excluded in certain contexts (e.g., by security standards). For example, the later reset can be performed within the period until the next startup process of each component 27a, c~f.

[0073] Next, further embodiments of the techniques of this disclosure will be described with reference to Figures 5 and 6. Figure 5 shows the in-vehicle network according to Figure 2, in which the first component 27c has been tampered with. Figure 6 shows the in-vehicle network according to Figure 2, in which the tampering with the first component 27c has been repaired.

[0074] First, several aspects of detecting software tampering in components 27a, c-f of the vehicle 20 will be described in more detail. As described above, the techniques of the present disclosure involve recognizing the possibility of software tampering in one of several components of an in-vehicle network, which in some examples involves receiving a signal. This signal can be generated in various forms.

[0075] First, software tampering in components 27a, c-f can be detected. This detection can be performed locally by the corresponding (tampering) detection device for the corresponding component.

[0076] In Figure 5, the software of one of the control devices 27c (referred to as the "first component" in some examples of this disclosure) was tampered with. The tampered software component 71 was introduced.

[0077] The (tampering) detection device 81a of the control unit 27c (e.g., part of the security module) can recognize this tampering and generate a corresponding signal for the central device 25 to mitigate the software tampering (see also steps 111 and 113 in Figure 1). This signal can then be processed as described above to implement mitigation.

[0078] In other examples, or as an addition, a (tampering) detection device 61b on the vehicle 20's central communication interface can (remotely) detect tampering with the control unit 27c and generate a signal for a central device 25 for software tampering mitigation (similarly located on the vehicle 20's central communication interface in the example of Figure 3). Thus, in some examples, the central device 25 for software tampering mitigation is also designed for central detection of software tampering in multiple components 27a, c~f of the in-vehicle network.

[0079] In other examples, or as an addition, a detection device in the remote system 30 may (remotely) detect tampering with the control unit 27c and generate a signal for the central device 25 to mitigate the software tampering. In this example, the signal may be received via the vehicle interface. However, if the tampering detection is also performed within the vehicle, in some cases the time to mitigate the tampering can be shortened.

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

[0081] Tampering detection can be carried out in various ways. For example, software can be checked at startup ("Secure Boot") and / or during operation ("Runtime Tampering Detection") by one or more methods for checking the truthfulness and / or authenticity of the software (e.g., using one or more digital signatures).

[0082] In another example, a signal that indicates potential tampering when it is not present can be generated by a component described in a preceding section. For example, the (tampering) detection device 81a of the control unit 27c can generate a signal (e.g., periodically or when a specific event occurs) whose absence can indicate tampering with the software of the control unit 27c.

[0083] Here, with reference to Figures 5 and 6, we discuss further embodiments of software reset measures for the first component 27c, which use a software component 42c for the first component 27c stored in the central persistent memory 41.

[0084] The central device 25 for mitigating tampering can select countermeasures based on the detection of tampering in the first component 27c. The examples in Figures 5 and 6 describe a software reset of the first component 27c. 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., the control unit). 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 25 for mitigating tampering. In this way, the tampering can be repaired by replacing the tampered software component 71 or parts 81a, 81b with genuine (i.e., untampered) software component 52c or parts 53a, 53b.

[0085] Authentic (i.e., unmodified) software 52c can be called from persistent memory 41. As described above, persistent memory 41 can store software components 42c in a form that is directly usable, or in a form that can only be used after one or more processing steps to reset a tampered software component 71 or the first component 27c.

[0086] In some cases, the tamper-resistant central device 25 can implement measures to ensure the reliability of software components 42a, c~n used to reset the component's software. For example, a reliability check can be performed before using software components 42a, c~n (e.g., based on a digital signature or another security feature). For reliability checks, the tamper-resistant central device 25 can utilize the functionality of the component into which the tamper-resistant central device 25 is integrated.

[0087] In some examples, persistent memory 41 may contain multiple versions of software components for specific components of the in-vehicle network. In this case, a central device 25 for mitigating tampering can select one of those versions (e.g., the latest version of the software component).

[0088] In the preceding sections, with reference to Figures 5 and 6, measures to mitigate tampering with the first component 27c of the in-vehicle network were mentioned. However, the central device 25 for mitigating tampering is configured to implement measures against software tampering of one or more of the multiple components 27a, d to f at a different time or simultaneously with the tampering mitigation of the software of the first component 27c.

[0089] In some cases, the central device 25 for mitigating tampering is designed to recognize the potential for software tampering in further components 27a, d-f of the in-vehicle network and to implement further measures to mitigate tampering in those components 27a, d-f. Tampering detection, implementation of countermeasures, and enforcement can proceed as described above. For example, the tampered software components of the further components 27a, d-f can be reset.

[0090] In this way, a single central device for mitigating tampering can be responsible for multiple components located far apart within the in-vehicle network (e.g., control devices in various domains) (i.e., repairing software tampering in multiple components).

[0091] In the preceding section, we described the resetting of component software as a measure implemented by a central device to mitigate tampering and carried out within the in-vehicle network.

[0092] In some cases, a central device to mitigate tampering can be implemented to introduce additional measures, which are then taken into action. In some cases, further countermeasures against tampering may include blocking communication of the first component 27c (whose software has been tampered with) over the in-vehicle network. Blocking communication 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 (for example, for a certain period of time). For this reason, in some cases, blocking communication of the first component 27c over the in-vehicle network may be preferable to resetting the software of the first component 27c (for example, in a context where failure of the first component 27c is unacceptable or undesirable, at least in the short term). A measure to reset the software of the first component 27c may be introduced and implemented following a measure to block communication of the first component 27c (for example, in a modified context).

[0093] Alternatively or additionally, further countermeasures against tampering may include blocking communication of a group of components over the in-vehicle network, including the first component 27c. In the example in Figure 3, the first component 27c may be included in the first domain 26a along with further components 27a and 27b. Blocking communication of a group of components over the in-vehicle network is similar to blocking individual components as described above. Here again, damage can be prevented from being caused by a group of components over the in-vehicle network. Even when blocking communication of a group of components over the in-vehicle network, countermeasures can be implemented at a later point in time to reset the software of the first component 27c (for example, in the modified context).

[0094] As an alternative or addition, further measures against tampering may include modifying the functionality of the first component 27c in which the tampering was detected. For example, functionality may be restricted according to a predetermined pattern (e.g., for functionality required for specific security-related aspects in each context).

[0095] As an alternative or addition, further countermeasures against tampering may include transferring the functionality of the first component 27c, which has been detected as tampered with, to one or more other components from among the multiple components 27a, b, d-f. For example, one or more other components from among the multiple components 27a, b, d-f may at least temporarily take over the tasks (or part thereof) of the first component 27c. The first component 27c can then be shut down and / or blocked. In this case as well, at a later point in time, a countermeasure may be introduced and implemented to reset the software of the first component 27c (for example, in the modified context).

[0096] In many cases, the techniques of this disclosure have been described based on their respective methods. This disclosure also relates to systems designed to perform the methods of this disclosure. A system may include (for example, be integrated with) one or more components of a vehicle's in-vehicle network. The in-vehicle network may also include devices that are only temporarily included in the in-vehicle network (for example, mobile devices located in the vehicle and integrated with the in-vehicle network). In other examples, a system may also include a remote system.

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

[0098] As described 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 several dedicated hardware components (while utilizing other hardware components of the component into which the central device is integrated). As similarly stated, the other component may be the central communication interface of the in-vehicle network, a central computer ("vehicle computer"), or another component with relatively high-performance hardware.

[0099] In some cases, existing components of an in-vehicle network (e.g., a central communication interface for the vehicle or a vehicle domain, a central computer for the vehicle, or the head unit of an infotainment system) can be configured as a central device to mitigate software tampering by updating the software of the in-vehicle network components.

[0100] A central device for mitigating software tampering, or another component into which it is integrated, may include at least one processor (possibly having multiple cores) and memory containing instructions that, when executed by the processor, perform the method of the present disclosure.

[0101] This disclosure further relates to vehicles that include, or are part of, the systems provided by this disclosure, and / or vehicles that include the in-vehicle networks provided by this disclosure. This disclosure further relates to a computer program designed to perform the methods described herein.

[0102] This disclosure further relates to computer-readable media (e.g., DVDs or solid memory) containing the computer programs of this disclosure. This disclosure further relates to signals (e.g., electromagnetic signals via wireless or wired communication protocols) that encode the computer programs of this disclosure. [Explanation of Symbols]

[0103] 20 vehicles 21, 22 Communication Interfaces 23 Central Control Unit 21-24 Multiple components 25. Central device to mitigate software tampering. 26a~n domains 27a~f Control device 30 Remote Systems 31 Software Bundles 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 81 detection devices 91 memory 93 Security Modules 94 processors 95 Multiple Interfaces 96 Transmission paths for in-vehicle networks 99 Invariant Modules 402 Other Components 403 Main Unit

Claims

1. 1. A computer-implemented method comprising: A step (101) of recognizing, in a central device (25) for software tampering mitigation, a possibility of software tampering of a first component (27c) of a plurality of components (27a-f) of an in-vehicle network of a vehicle (20), comprising: a step (101) in which the central device for tampering (25) is part of the in-vehicle network and is designed to mitigate software tampering in each of the plurality of components (27a-f) of the in-vehicle network; - implementing (103) measures to mitigate said tampering of said software of said first component (27c) by a central device (25) for mitigating said tampering; Implementing the countermeasures to mitigate the tampering of the software of the first component (27c), the countermeasure against tampering comprises resetting the software of the first component (27c) using a security module (93) of the first component (27c) and / or an immutable module (99) of the first component (27c); A method comprising:

2. said resetting of said software of said first component (27c) placing said first component (27c) in a reset mode by a security module (93) of said first component (27c) and / or an immutable module (99) of said first component (27c); The method of claim 1 , comprising:

3. said resetting of said software of said first component (27c) restarting a processor of the first component (27c) before placing the first component (27c) in the reset mode; receiving a software component for resetting the software after the step of placing the first component (27c) in a reset mode; and storing the received software components in a memory of the first component (27c); The method of claim 2 further comprising:

4. The method of claim 3 , wherein the step of restarting the processor of the first component is initiated by the security module.

5. 4. The method of claim 3, wherein the step of restarting the processor of the first component is initiated by a power supply unit of the vehicle, the power supply unit being designed to selectively supply energy to the plurality of components of the in-vehicle network.

6. 4. The method of claim 3, wherein the step of restarting the processor of the first component (27c) is initiated by activation of a central actuation function of the vehicle (20).

7. The method of claim 1 , wherein the immutable module of the first component (27c) is a boot loader.

8. The method of claim 1 , wherein the software component for resetting the software is transmitted from a central device for mitigating tampering (25).

9. 4. The method of claim 3, wherein the steps of receiving the software component for resetting the software and storing the received software component are performed by the security module (93).

10. 4. The method of claim 3, wherein the steps of receiving the software component for resetting the software and storing the received software component are performed by the immutable module (99).

11. A system designed to carry out the method according to any one of claims 1 to 10.

12. An in-vehicle network for a vehicle (20), comprising: a central device (25) for mitigating software tampering; a plurality of components (27a-f) of the in-vehicle network including a first component (27c); Designed to carry out the method according to any one of claims 1 to 10, In-vehicle network.

13. A vehicle (20) including a system according to claim 11.

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

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

Images