Reduction in manipulation of vehicle software

Abstract

To reduce manipulation of vehicle software.SOLUTION: A first general aspect of the present disclosure relates to a computer-implemented method. The method includes a step of recognizing the possibility of manipulation of software of a first component of a plurality of components for an on-vehicle network of a vehicle, 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. The measures include activating write and / or read lock of a memory of the first component. In some examples, the recognition and introduction may be executed in a central device for reducing manipulation of software, and the central device for reducing manipulation 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.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] Relates to vehicle software.

Background Art

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

[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., restoring it so that a defined (safe) state is achieved) involves considerable effort and thus time delays. 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 the tampering and reducing the tampering. 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, improved techniques for reducing software tampering are desirable.

Means for Solving the Problems

[0005] A first general aspect of this disclosure relates to a computer implementation method. This method includes the steps of: recognizing the possibility of software tampering in a first component of a plurality of components of an in-vehicle network of a vehicle; introducing measures to mitigate the software tampering in the first component; and implementing measures to mitigate the software tampering in the first component. The measures include activating write and / or read locks on the memory of the first component. In some examples, recognition and introduction may be performed in a central device for software tampering mitigation, which 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.

[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 optionally 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: In some cases, activating a write and / or read lock on the memory of the (first) component (e.g., a hardware write and / or read lock on the memory) can prevent an attacker from repeatedly tampering with the component. For example, tampering with an embedded system in a vehicle (e.g., a control unit) can first be repaired by resetting the embedded system's memory. However, the vulnerability that allowed the attacker to tamper with the embedded system may still exist. Therefore, there is a risk that the attacker (or another attacker) could exploit the same vulnerability again to tamper with the component (and the contents of the component's memory could be changed again). Activating a write and / or read lock on the memory can prevent this in some situations and ensure that the component continues to perform its intended functionality, at least at the time of the initial tampering. After closing the vulnerability, the write and / or read lock on the memory can then be deactivated to allow updates to the contents of the memory (e.g., during a software update of the component). In another example, activated write and / or read locks can prevent tampered memory contents from being read.

[0009] Secondly, the techniques of the present disclosure can, in some cases, access existing write and / or read locks on the memory of a component. For example, some microcontrollers used in control devices already have (hardware) write and / or read locks for specific memory. Thus, in some cases, the techniques of the present disclosure can be implemented without significant expense and / or retrofitted to existing systems without replacing components (for example, by updating the software of the components).

[0010] Thirdly, in some cases, a central device for mitigating software tampering can implement tamper-mitigation measures across multiple components of a vehicle. This can, in some cases, shorten the time it takes to mitigate tampering and / or allow for easier scaling and / or retrofitting. For example, a central device for mitigating tampering can be modified relatively easily to "monitor" additional components. In some cases, this requires little to no modification of the "monitored" components, making it easier to use in older vehicles. In some cases, the central device for mitigating tampering itself can 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 the (additional) functionality of the central device for mitigating tampering through a software update.

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

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

[0013] 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).

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

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

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

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

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

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

[0020] [Figure 1] A flowchart showing the techniques of the present disclosure. [Figure 2] A diagram showing components of an in-vehicle network of a vehicle in which the techniques of the present disclosure can be used. [Figure 3] A diagram showing exemplary components of an in-vehicle network. [Figure 4a] A diagram showing a flowchart of an exemplary method of the present disclosure. [Figure 4b] A diagram showing a flowchart of an exemplary method of the present disclosure. [Figure 4c] A diagram showing a flowchart of an exemplary method of the present disclosure. [Figure 5] A diagram showing the in-vehicle network according to FIG. 2 in which the first component has been tampered with. [Figure 6] A diagram showing the in-vehicle network according to FIG. 2 in which the tampering of the first component has been repaired.

Embodiments for Carrying Out the Invention

[0021] First, referring to FIGS. 1 to 3, vehicles 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 FIGS. 4a to 4c, examples of the techniques of the present disclosure will be discussed. Based on FIGS. 5 and 6, further aspects of the central device for reducing software tampering will be described.

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

[0023] In Figure 1, the center column shows steps that may be performed by a central device (but also by other components in other examples) to mitigate software tampering in some cases. The right column shows steps performed by specific components (or groups of components) of the in-vehicle network (excluding the central device for mitigating software tampering). The left column shows steps performed by a remote system (i.e., outside the vehicle).

[0024] The technique of the present disclosure includes step 101 of recognizing the possibility of software tampering in a first component 27c of a plurality of components of the in-vehicle network of a vehicle 20. A vehicle 20 is schematically shown in Figure 2, and an exemplary first component 27c is shown in Figure 3. The vehicle 20 is equipped with an in-vehicle network that includes a plurality of components 21-24, 25, 27a-f of the vehicle 20 and connects them (the in-vehicle network can be configured as described above).

[0025] The vehicle 20 may have 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 may be designed to mitigate software tampering in each of the multiple components 21-24, 27a-f of the in-vehicle network.

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

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

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

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

[0030] In response to the recognition of the possibility of software tampering in a first component 27c of multiple components of the vehicle's in-vehicle network (e.g., recognition of signal reception or signal absence), a central device 25 (or another component) for mitigating software tampering introduces measures to mitigate tampering in the first component 103. The measures are then implemented 119. These measures include activating a write and / or read lock on the memory of the first component 27c.

[0031] In some examples, countermeasures against tampering may also include resetting the software of the first component 27c 105. The reset may be performed before activating the write and / or read locks on the memory of the first component 27c. Further embodiments of the reset will be discussed further below. The reset first allows the first component 27c to be in a secure state (i.e., securely according to a predetermined security standard). For example, the component may be reverted to a specific version of its software (e.g., the latest version at the time the tampering is recognized). As already stated, the first component 27c can then provide at least one further specific functionality. Subsequent activation of the write and / or read locks may have the effect of preventing further tampering of the component or the contents of its memory, and / or reducing the risks arising from the tampered component (e.g., by making it impossible to read the tampered contents of the memory). Therefore, the security of component 27c and / or the in-vehicle network can be improved without completely abandoning the functionality of component 27c (which could occur, for example, after the component is switched off).

[0032] 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, or a combination of both). 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). 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.

[0033] Memory 91 is equipped with a write and / or read lock 92. In some examples, component 27c may include a (pure) write lock. After its activation, all or certain write operations into memory 91 may be prohibited. In some examples, activating the write lock 92 may make the contents of memory 92 immutable. In other examples, activating the write lock 92 may allow only a subset of the changes to the contents of memory 92 that would be possible when the write lock is deactivated. For example, activating the write lock 92 may make a software component stored in memory immutable (while it can be updated within an update framework when the write lock 92 is deactivated).

[0034] Alternatively, component 27c may include a (pure) read lock. After its activation, all or specific read operations from memory 91 may be prohibited.

[0035] In another example, component 27c includes a (combined) write and / or read lock. After its activation, all or specific write and read operations to and from memory 91 may be prohibited. The lock may have one or more activation states. In an example where the lock has multiple activation states, each activation state may prohibit different combinations of read and / or write operations (for example, read operations only or write operations only may be prohibited; or read and / or write operations of a first group may be prohibited in the first activation state, or read and / or write operations of a second group, including different or additional read and / or write operations compared to the first group, may be prohibited in the second activation state).

[0036] The write and / or read lock 92 can be activated and deactivated (for example, by a corresponding external or internal signal). In some examples, the write and / or read lock may be a hardware write and / or read lock (i.e., a function implemented in the hardware of the first component that prohibits modification of the contents of memory 91). For example, some hardware environments (e.g., integrated circuits such as microprocessors) may provide the possibility of activating (and possibly deactivating with another key) the write and / or read lock using a key. Again, in other examples, a memory protection unit may provide a write and / or read lock (for example, to lock a specific memory region in operation for a particular purpose).

[0037] In some examples, write and / or read locks 92 may already be included in component 27c (for example, to activate and deactivate programmable states). In this case, with respect to the techniques of the Disclosure, existing write and / or read locks may only be activated on an event basis (i.e., after detection of tampering). In other examples, the component may be extended to include write and / or read locks for memory in order to perform the techniques of the Disclosure. Write and / or read locks or parts thereof may also be located in components other than the first component 27c.

[0038] The write and / or read lock 92 can be activated (and deactivated) in various ways. In some examples, the activation (and / or deactivation) of the write and / or read lock 92 of the memory 91 of the first component 27c may be performed by the security module 93 of the first component 27c. That is, the security module 93 generates a signal for the write and / or read lock 92 (and is connected to the write and / or read lock 92 for this purpose) in order to activate the write and / or read lock 92.

[0039] The security module 93 may be separate from the remaining modules of the first component 27c in terms of its hardware and / or software (i.e., it may be 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 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 (e.g., one or more cores of a multicore processor) is isolated from the other elements (e.g., the circuitry is physically isolated). In some examples, the security module 93 may be designed to perform one or more cryptographic functions (e.g., one or more functions from managing cryptographic keys and / or signatures, encrypting or decrypting data, and other cryptographic functions) in addition to activating (and deactivating) write and / or read locks 92 of memory 91. As an addition or alternative, the security module 93 may include a (tampering) detection device for recognizing tampering (as described in more detail below). In some examples, the security module 93 is an external or internal 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).

[0040] The use of security module 93 to activate (and optionally deactivate) the write and / or read lock 92 can further enhance the security of the technique of this disclosure. Thus, in some cases, an attacker who can access and tamper with the software of the first component through a vulnerability can be prevented from also circumventing the write and / or read lock 92. Tampering with security module 93 can be (considerably) more difficult than tampering with other modules of component 27c. In addition, since an existing security module is reused, in some cases the aforementioned security improvements can be achieved without significantly modifying the component's hardware.

[0041] Component 27c also includes a processor 94 for executing instructions (for example, as part of the main unit). As mentioned above, the term “processor” also includes a multi-core processor, or multiple separate components that take on (and possibly share tasks with) a central processing unit of an electronic device. In some examples, component 27c may include one or more interfaces 95 designed to communicate over a transmission path 96 of an in-vehicle network. As seen in Figure 3, the processor 94, the security module 93, or both of them can directly access 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).

[0042] In some examples, the techniques of the present disclosure further include deactivating write and / or read locks in response to a change in the vehicle in order to close a security hole in the in-vehicle network 117. In some examples, the change may include receiving an updated software component (closing the security hole) in the vehicle 20 109. The updated software component may be received by a remote system 30 in the vehicle 20 (for example, by a wirelessly transmitted update or in the framework of factory maintenance).

[0043] In some examples, requests to activate and / or deactivate write and / or read locks on the contents of the memory of the first component 27c originate from the tamper-mitigating central device 25. For example, the security module 93 of the first component 27c can receive a request from the tamper-mitigating central device 25 and then activate the write and / or read lock 92 on the memory 91 of the first component 27c. Similarly, in some examples, the security module 93 of the first component 27c can receive a request from the tamper-mitigating central device 25 and then deactivate the write and / or read lock 92 on the memory 91 of the first component 27c. In some examples, the security module 93 can also activate and / or deactivate the write and / or read lock 92 independently (for example, when a specific event is recognized by the security module 93, such as the execution of a signed instruction or update).

[0044] In some examples, communications for activating and / or deactivating write and / or read locks 92 may be protected by one or more encryption methods. For example, communications may be encrypted. Additional or alternative, communications may be made using digital signatures (to authenticate the participants, e.g., the source of requests to activate and / or deactivate write and / or read locks). Further additional or alternative, communications may be obfuscated within the vehicle's data stream (e.g., by steganography methods, by methods that prevent message length analysis of communications, such as message padding, by methods that prevent analysis of the time of communications, such as random transmission of messages, or by countermeasures against side-channel attacks). Further additional or alternative, communications may be protected by timestamps that participants in communications can evaluate to check communications (e.g., participants in communications can reject messages older than a given threshold age). In some examples, the security module 93 of the first component 27c may be used to implement one or more encryption methods (further modules may be used on the side of the first component 27c to implement one or more encryption methods, as may be the case). Communication for activating and / or deactivating the write and / or read lock 92 may include requests to activate and / or deactivate the write and / or read lock of the memory contents of the first component 27c, instructions to the write and / or read lock 92 to trigger the activation and / or deactivation, and / or to confirm the implementation of the activation and / or deactivation.

[0045] Based on Figures 4a to 4c, we will now discuss an exemplary flow of the method described herein. Figures 4a to 4c show, in each column, the actions of a specific component (or one of its modules) or system. Arrows between columns represent actions and / or communications between the respective units. On the far left is the remote system 30. The remote system 30 may be connected to the vehicle via a wireless or wired interface. Further components / modules on the right, namely the vehicle's central processing unit 401, a central device 25 for mitigating software tampering, and specific components 27c (e.g., embedded systems in the vehicle 20, e.g., control devices) are located within the vehicle. Component 27c may have three modules: a main unit 403 (which may include, for example, a processor 94), a security module 93, and a write and / or read lock 92 for the memory of component 27c. The main unit 403 may be designed to provide the functions of component 27c within the vehicle (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other work tasks).

[0046] Here, at a certain point in time, software tampering 410 may occur in component 27c (or main unit 403), as shown in Figure 4a. This tampering can be detected and corrected (for example, by resetting the software of component 402, as further described below). After the tampering is corrected, the central device 25 for mitigating software tampering can send a request 412 to the security module 93 to activate a write and / or read lock 92 (this request 412 may be protected by one or more cryptographic methods). The security module 93 receives the request 412 and, in response, can activate the write and / or read lock 92 414. As a result, the contents of the memory of component 27c can no longer be changed, or can only be changed with restrictions, or the memory 92 can no longer be read, or can only be read with restrictions. In some examples, the write and / or read lock 92 can send a confirmation 416 to the security module 93. In some cases, the security module 93 can forward an acknowledgment 416 to a central device 25 to mitigate software tampering (this acknowledgment may be protected by one or more encryption methods).

[0047] In some cases, the central device 25 for mitigating software tampering may also transmit information 413 about the tampering (e.g., information about communications within and to the vehicle 20 before the tampering was discovered, as well as status information about the vehicle 20 or its components, as well as information about the tampered software of component 27c) to a remote system 30 (possibly via the central processing unit 401 of the vehicle 20). This communication may also be protected by one or more encryption methods.

[0048] As shown in Figure 4b, the remote system 30 can identify a vulnerability in the vehicle's in-vehicle network (for example, based on received information 414 regarding tampering) 420. This vulnerability could have been a gateway for tampering with the software of the first component 27c. The remote system 30 can transmit software update information 422 to the vehicle (for example, via a wireless or wired interface). The software update information 422 may be received within the vehicle 20 and forwarded (for example, by the vehicle 20's central processing unit 401) to a central device 25 for mitigating software tampering. After receiving the software update information 422, a request 424 to deactivate the write and / or read lock 92 may be generated. In the example in Figure 4b, the request 424 to deactivate the write and / or read lock 92 is sent from the central device 25 for mitigating software tampering to the security module 93 (the request 424 may be protected by one or more encryption methods). Subsequently, the security module 93 may deactivate the write and / or read lock 92 426. From this point onward, the contents of the memory of component 402 may be modified again or read from memory 91. As shown in Figure 4c, the write and / or read lock 92 may send a deactivation confirmation 423 to the security module 93. The security module 93 may forward the deactivation confirmation 423 to the central device 25 for mitigating software tampering.

[0049] Next, update information 424 is sent to the component, allowing the vulnerability to be closed. The following sections describe embodiments of a central device 25 for software tamper mitigation, in some examples, that introduce the activation of write and / or read locks 92 on a first component 27c (and possibly further components 27). An example of a central device 25 for software tamper mitigation is shown in Figure 2. In some cases, a vehicle may have only one central device 25 for software tamper mitigation, specifically designed to introduce the activation (and deactivation) of write and / or read locks to mitigate tampering on multiple components 21-24, 27a-f (e.g., all or a subset of these components of the vehicle that can recover software tampering). In other examples, a vehicle may have multiple central devices for software tamper mitigation, which are part of an in-vehicle network, each assigned to multiple components of the in-vehicle network (i.e., capable of recovering software tampering on the assigned component). However, in both cases, the central devices for software tamper mitigation are isolated from the assigned components. In some cases, the central device 25 for mitigating software tampering may also be designed to mitigate tampering with its own software and / or the software of the component into which the central device 25 for mitigating software tampering is integrated.

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

[0051] 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.).

[0052] 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).

[0053] 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).

[0054] 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).

[0055] Countermeasures against tampering may include, in addition to activating write and / or read locks, resetting the software of the component whose software has been tampered with (also referred to in this disclosure as the “first component”) using software components 42a, 42c~n for each component, which are stored in the central persistent memory 41. Further embodiments of these further countermeasures will be discussed further below with reference to Figures 5 and 6.

[0056] 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).

[0057] Software update information 32a, 32c~n can be received via interfaces 21 and 22 of the vehicle 20. Interface 21 may be a wireless interface (shown in Figure 2), but in other examples it may be a wired interface 22 (e.g., an interface for on-board diagnostics). The vehicle may be designed to receive software update information 32a, 32c~n from a remote system 30 via one of interfaces 21 and 22. As shown in Figure 1, the remote system 30 can select software update information 32a, 32c~n for a corresponding vehicle and transmit it to the vehicle 20 via one of interfaces 21 and 22. 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 during vehicle operation (e.g., monitoring and / or control functions for the vehicle 20).

[0058] 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 multiple components 27a-f. For this purpose, one or more preparation steps (e.g., deployment, signature verification, etc.) can be applied to the software update information 32a, 32c-n obtained from the remote system 30. Additionally or alternatively, the software update information can be used to remediate vulnerabilities in the vehicle's in-vehicle network.

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

[0060] 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).

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

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

[0063] In some examples, the techniques of the present disclosure may include selecting one additional measure from among several additional measures (in addition to activating the write and / or read lock, in particular before activating the write and / or read lock; hereinafter simply referred to as the “additional measure”) based on contextual information relating to the vehicle. The contextual information may include information relating to the operating state of the vehicle 20 and / or information relating to predetermined rules for the operation of the vehicle 20.

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

[0065] 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 further measures may be introduced regarding a particular component).

[0066] 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 further 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 software update information 32b for the central device 25 for mitigating software tampering, or for the component in which the central device 25 for mitigating software tampering is located).

[0067] In some cases, various additional measures can be used to mitigate specific software tampering in components 27a, c-n (the possible additional measures are described in more detail below). Here, contextual information can be used to select one of the available additional measures. In some cases, from among several available additional measures, 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 tampering). On the other hand, in some situations, available additional measures can be excluded based on rules contained in the contextual information (for example, when they would violate certain security standards).

[0068] For example, the first further measure may enable broader mitigation of tampering than the second further measure, 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 further measure may enable less broad mitigation of tampering compared to the first further measure, but on the other hand, it may also result in less serious intervention to the vehicle's components. In this case, the first further measure can be selected in the first context (represented by contextual information), and the second further measure 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 further measure in the first situation but permit it in the second situation.

[0069] In some examples, further measures may include the step of immediately resetting the software of components 27a, c, f, where tampering is detected, using software components 42a, c, f, n stored in central persistent memory 41 (e.g., generated based on received software update information), and the step of later resetting the software of components 27a, c, f, n, respectively, using software components 42a, c, f, 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, a later reset could be performed within the time period before the next startup process of each component 27a, c, f.

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

[0071] First, several embodiments 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 may include recognition of the possibility of software tampering in one of several components of an in-vehicle network, which in some examples includes receiving a signal. This signal can be generated in various forms.

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

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

[0074] The (tampering) detection device 81a of the control unit 27c 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.

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

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

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

[0078] 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).

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

[0080] Referring here to Figures 5 and 6, we discuss further embodiments of further measures for software reset of the first component 27c, using a software component 42c for the first component 27c, which is stored in the central persistent memory 41. The software reset of the first component 27c may be performed before the activation of the write and / or read lock.

[0081] The central device 25 for mitigating tampering can select further measures based on the detection of tampering in the first component 27c. In the examples of Figures 5 and 6, a software reset of the first component 27c is selected as a further measure. The reset may include returning 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 a connection to the in-vehicle network) 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.

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

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

[0084] 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).

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

[0086] 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, as well as the implementation and execution of countermeasures, can proceed as described above. For example, the tampered software components of the further components 27a, d-f can be reset.

[0087] 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).

[0088] The preceding section described component software resets as an exemplary further measure implemented by a central device to mitigate tampering and carried out within the in-vehicle network.

[0089] In some cases, a central device designed to mitigate tampering may, as an alternative or addition, introduce other further measures implemented within the in-vehicle network. In some cases, further measures 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 (e.g., 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 (e.g., in a context where failure of the first component 27c is unacceptable or undesirable, at least in the short term). Further measures to reset the software of the first component 27c may be introduced and implemented following further measures to block communication of the first component 27c (e.g., in a modified context). After the software reset, write and / or read locks may be activated.

[0090] Alternatively or additionally, further countermeasures against tampering may include blocking communication of a group of components over an 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 an 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 an in-vehicle network. Even when blocking communication of a group of components over an in-vehicle network, further countermeasures can be introduced and implemented at a later point in time to reset the software of the first component 27c (for example, in the modified context). After the software reset, write and / or read locks can be activated.

[0091] As an alternative or addition, further countermeasures against tampering may include modifying the functionality of the first component 27c in which the tampering is 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). Write and / or read locks may then be activated.

[0092] 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, further countermeasures may be introduced and implemented at a later point in time to reset the software of the first component 27c (e.g., in the modified context). After the software reset, write and / or read locks may be activated.

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

[0094] This disclosure also relates to a central device for mitigating software tampering of multiple components of a vehicle's in-vehicle network, which is designed to perform the methods of this disclosure. As stated 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). In other cases, however, the central device for mitigating software tampering may be 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 have 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.

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

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

[0097] This disclosure further relates to an in-vehicle network for a vehicle, optionally including at least one central device for mitigating software tampering by this disclosure, and a plurality of components of the in-vehicle network. The in-vehicle network may be designed to perform the techniques of this disclosure (as described above). 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] 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.

[0099] 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]

[0100] 20 vehicles 21, 22 Communication Interfaces 23 Central Control Unit 21-24 Multiple components 25. Central devices / components to mitigate software tampering. 26a~n domains 27a~f Control devices / components 30 Remote Systems 31 Software Containers 32a, 32c~n Software Update Information 41 Central persistent memory 42a, 42c~n Software Components 52c Software Components / Software 53a, 53b Part of the software components 61b Detection device 71 Software Components 81a Part of the detection device / software component 81b Part of the software component 91 memory 93 Security Modules 94 processors 95 Multiple Interfaces 96 Transmission paths for in-vehicle networks 401 Central Processing Unit 402 Component 403 Main Unit

Claims

1. 1. A computer-implemented method comprising: Recognizing (101) a possible software tampering of a first component (27c) of a plurality of components (27a-f) of an in-vehicle network of a vehicle (20); Implementing (103) countermeasures to mitigate said tampering of said software of said first component (27c); implementing (119) the measures to mitigate the tampering of the software of the first component (27c); Including, the measures include activating a write and / or read lock (92) of a memory (91) of the first component (27c), method.

2. said recognition and / or said introduction being performed in a central device (25) for mitigating software tampering, the central device (25) for tamper mitigation 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; The method of claim 1.

3. 2. The method of claim 1, wherein the countermeasure against tampering comprises a reset of the software of the first component, the reset being performed before the activation of the write and / or read lock of the memory of the first component.

4. 2. The method of claim 1, wherein the activation of the write and / or read lock of the memory of the first component is performed by a security module of the first component.

5. deactivating the write and / or read lock (92) in response to a change in the vehicle (20) to close a security hole in the in-vehicle network. The method of claim 1 further comprising:

6. 2. The method of claim 1, wherein a request to activate and / or deactivate the write and / or read lock (92) of the memory (91) of the first component (27c) originates from a central device (25) for tamper mitigation.

7. The method of claim 1 , wherein the write and / or read lock (92) is a hardware write and / or read lock.

8. The method of claim 1 , wherein the activation and / or deactivation communications are secured with one or more encryption methods.

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

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

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

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

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

Images