Mitigation of vehicle software manipulation

Abstract

To provide mitigation of vehicle software manipulation.SOLUTION: A computer-implemented method includes a step (101) of identifying the possibility of manipulation of software of a first component of a plurality of components of an on-board network of a vehicle in a central device for mitigating software manipulation. The central device for mitigating manipulation is designed to mitigate software manipulation in each of the plurality of components in the on-board network. The method includes a step of initiating a countermeasure for mitigating manipulation of the first component by the central device for detecting and mitigating manipulation.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to reducing tampering of 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 the data is further used for the operation of the vehicle). Further, the complexity of vehicle components, particularly their software, continues to increase.

[0003] As a result, the opportunities for tampering with the software of vehicle components become more diverse. In some prior art methods, detecting tampering and especially reducing it (i.e., repairing so that a defined (safe) state is achieved) is associated with a significant amount of effort and the resulting time delay. For example, when deposited in a maintenance yard, the tampered software of a component (e.g., a control device) can be reset, thereby repairing the tampering. In other techniques, software can be requested from a remote computer system and the tampered software of a component (e.g., a control device) is reset using that software, 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, a malfunction may occur in the operation of the vehicle during this period (e.g., a predetermined safety standard is not met). In some cases, the vehicle may lose its driving ability or its function may be significantly impaired. Therefore, improved techniques for reducing software tampering are desired.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Provide reduction of tampering of vehicle software.

Means for Solving the Problems

[0005] A first general aspect of this disclosure relates to a computer implementation method, comprising the step of a central device for software tamper mitigation recognizing the possibility of software tampering in a first component of a plurality of components of an in-vehicle network of a vehicle. The central device for tamper mitigation 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 step of the central device for tamper mitigation initiating measures to mitigate software tampering in the first component.

[0006] A second general aspect of this disclosure relates to a central device for mitigating software tampering of multiple components of a vehicle's in-vehicle network. A third general aspect of this disclosure relates to an in-vehicle network for a vehicle, including a central device for mitigating software tampering as described in the second general aspect, and a plurality of components of the in-vehicle network.

[0007] A fourth general aspect of this disclosure relates to a vehicle including an in-vehicle network according to the third general aspect. The techniques of the first to fourth general aspects of this disclosure may, in some cases, have one or more of the following advantages:

[0008] Firstly, in some cases, the time required to mitigate tampering can be shortened (and in some situations significantly) compared to conventional techniques. The central device for mitigating tampering, as part of the in-vehicle network, can initiate the mitigation method immediately (e.g., within 5 minutes or 1 minute) (e.g., without the assistance of systems substantially outside the vehicle). In some cases, the central device for mitigating tampering can not only initiate the countermeasure but also implement it. In other cases, other components of the in-vehicle network can also participate in implementing the countermeasure. As a result, the mitigation method can be implemented immediately (e.g., within 5 minutes or 1 minute), and the vehicle can be brought to a specified state (e.g., a safe state according to specified safety standards).

[0009] Secondly, the techniques of this disclosure may be more resource-efficient than other methods. Therefore, a central device for mitigating tampering can be replaced with multiple devices, each corresponding to only a portion of the components. Furthermore, in some cases, existing components can be reused for the techniques of this disclosure. For example, persistent memory used to update the software of multiple components of a vehicle (e.g., to store large update packets) can be "reused" to reset the component's software, thereby correcting the tampering. Therefore, in some cases, new memory does not need to be provided for this purpose. The need to retain software for resetting each of multiple components significantly increased the structural cost of these components (e.g., control devices).

[0010] Thirdly (and more in part as a result of the first embodiment), a central device for mitigating tampering as part of the in-vehicle network may perform contextual selection of appropriate countermeasures (i.e., taking into account the vehicle's current operating state and / or prescribed rules). For example, information regarding the vehicle's operating state may be considered when selecting countermeasures. This can further contribute to shortening the time it takes for the vehicle to be in a specified state and for the tampering to be corrected. For example, a first countermeasure may be provided when the vehicle is moving, and a second different countermeasure may be provided when the vehicle is stationary.

[0011] Fourth, compared to some techniques of the prior art, the techniques of this disclosure are easier to scale and / or can be used in older vehicles (not designed according to the latest standards). For example, a central device for mitigating tampering can be relatively easily modified to "take responsibility" for additional components. In some cases, the component "takes responsibility" does not need to be modified much, or not at all, which facilitates 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 provided with (additional) functionality for the central device for mitigating tampering by a software update.

[0012] This disclosure uses several terms as follows: In this disclosure, a “component” (of an in-vehicle network) holds its own hardware resources, including at least one processor for executing instructions and memory for storing at least one software component. The term “processor” also includes a multi-core processor or multiple separate components that take on (and possibly share) tasks of a central processing unit of an electronic device. A component can perform tasks (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other operational tasks) independently. However, in some examples, a component may be controlled by other components. A component may be physically defined (e.g., using its own housing) or integrated into a higher-level system. A component may be a vehicle control device or a communication device. A component may be an embedded system.

[0013] An "embedded system" is a component that is incorporated (embedded) within a technical context. Here, the component assumes monitoring, control, or regulating functions, and / or governs the format of data or signal processing.

[0014] A "(dedicated) control device" is a component that controls only one function of a vehicle. A control device could, for example, control the engine, the brake system, or an assist system. Here, "function" can be defined at various levels of the vehicle (for example, a single sensor or actuator may be used for one function, or multiple assemblies combined as a larger functional unit may be used).

[0015] The terms “software” or “software component” can, in principle, refer to any part of the software of a component of this disclosure (e.g., a control device). In particular, a software component can 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 linked to each hardware component (i.e., neither can be used without the other). Firmware may be stored in non-volatile memory such as flash memory or EEPROM.

[0016] The terms “update information” or “software update information” include any data that forms the software component of the component according to this disclosure, either directly or after a corresponding processing step. Update information may include executable code or code that has not yet been compiled.

[0017] The term “tampering” in this disclosure includes any modification of the software of a vehicle component. Such modifications may result from an attack (i.e., intentional influence by a third party), but may also result from accidental or unintended influence.

[0018] The term "vehicle" includes any device that transports passengers and / or cargo. A vehicle may be an automobile (e.g., a passenger car or truck), but it may also be a railway vehicle. However, maritime devices and flying devices may also be vehicles. A vehicle may be at least semi-autonomous or may be driver-assisted.

[0019] "In-vehicle network" can be any internal network of a vehicle for components of the vehicle to communicate. In some examples, the in-vehicle network is a short-range communication network. The in-vehicle network can use one or more short-range communication protocols (for example, two or more short-range communication protocols). The short-range communication protocol can be a wireless or wired communication protocol. The short-range communication protocol can include bus protocols (such as CAN, LIN, MOST, FlexRay, or Ethernet). The short-range communication protocol can include Bluetooth protocol (such as Bluetooth 5 and later) or WLAN protocol (such as protocols of the IEEE-802.11 family, such as protocols after 802.11h). The in-vehicle network can contain an interface for communicating with systems outside the vehicle, and thus may be integrated into other networks. However, systems outside the vehicle and other networks are not part of the in-vehicle network.

[0020] The expression "recognize the possibility of..." means that specific events (such as signals or their absence) are interpreted according to predetermined rules to recognize a state where software tampering may have occurred.

Brief Description of the Drawings

[0021] [Figure 1] It is a flowchart showing the techniques of the present disclosure. [Figure 2] It is a diagram showing components of an in-vehicle network of a vehicle in which the techniques of the present disclosure may be used. [Figure 3] It is a diagram showing the in-vehicle network according to FIG. 2 in which the first component has been tampered with. [Figure 4] It is a diagram showing the in-vehicle network according to FIG. 2 in which the tampering of the first component has been repaired.

Modes for Carrying Out the Invention

[0022] First, with respect to FIGS. 1 and 2, a vehicle in which the techniques of the present disclosure can be implemented and the basic aspects of the techniques of the present disclosure are discussed. Subsequently, further aspects of the present disclosure are described based on FIGS. 3 and 4.

[0023] FIG. 1 is a flowchart showing the techniques of the present disclosure. FIG. 2 shows the components of an in-vehicle network of a vehicle in which the techniques of the present disclosure may be used. In FIG. 1, the steps performed by a central device for reducing software tampering are shown in the central column. In the right column, the steps performed by specific components (or groups of components) of the in-vehicle network (excluding the central device for reducing software tampering) are shown. In the left column, the steps performed by a remote system (i.e., outside the vehicle) are shown.

[0024] The technique of the present disclosure includes a step 101 of recognizing the possibility of software tampering of a first component among a plurality of components of the 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 may be constructed as described above).

[0025] Vehicle 20 includes a central device 25 for reducing software tampering that recognizes the possibility of tampering. Thus, the central device 25 is part of the in-vehicle network (i.e., also part of the vehicle and is moved with the vehicle). The central device 25 for reducing software tampering is designed to reduce software tampering in each of the plurality of 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 for communication with the outside world via communication interfaces 21, 22. Here, the central communication interface can support various communication protocols (for communication within the in-vehicle network or with external systems) and / or implement security functions. In other examples, the central device for mitigating software tampering may be integrated into other components (further examples are given below) or designed as a standalone component.

[0027] In some examples, recognition may involve receiving a signal indicating software tampering in a first component of a group of components in the vehicle's in-vehicle network. The signal may be generated in the central device 25 itself and / or other devices 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 signal from a component monitoring the 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 when a component starts up) indicating that the software of each of the multiple components 21-24, 25, 27a-f has not been tampered with.

[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 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 initiates measures to mitigate the tampering of the first component.

[0031] In the example in Figure 2, a central device 25 for mitigating software tampering is shown. In some cases, a vehicle may contain only one central device 25 for mitigating software tampering, which is designed to mitigate tampering to multiple components 21-24, 27a-f (e.g., all components of the vehicle whose software tampering can be repaired, 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 and assigned to multiple components of the in-vehicle network, respectively (i.e., capable of repairing software tampering in the assigned component). However, in any case, the central device for mitigating software tampering is separate from the assigned component. In some cases, the central device 25 for mitigating software tampering may be designed to mitigate its own software tampering and / or software tampering to the component into which the central device 25 for mitigating software tampering is integrated.

[0032] In the example shown in Figure 2, the multiple components whose software tampering can be repaired using the technique of the Disclosure include multiple control devices 27a-f. As already stated, the technique of the Disclosure is not limited to control devices and, in principle, can be used on any component of the vehicle's in-vehicle network 20. However, since control devices 27a-f in a vehicle typically have limited hardware resources and / or functionality, the technique of the Disclosure may be particularly advantageous for control devices in some cases.

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

[0034] Domains 26a-n may further contain components 27a, 27d, which function as a central communication node for each of the domains 26a-n and / or assume control functions for each of the domains 26a-n. In some examples, the central device for software tamper mitigation may be part of components 27a, 27d that function as a central communication node for each of the domains 26a-n and / or assume control functions for each of the domains 26a-n. This central device for software tamper mitigation may be provided in addition to further central devices for software tamper mitigation (e.g., a central device for software tamper mitigation as part of a central communication interface for an in-vehicle network) or as the sole central device for software tamper mitigation (see description above). Further alternatives or additions, the central device for software tamper mitigation may be designed as part of the vehicle's central control unit 23. Further alternatives or additions, the central device for software tamper mitigation 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 contain multiple central computers, i.e., "vehicle computers"). The central computer ("vehicle computer") may be (considerably) more powerful than the dedicated control devices of the in-vehicle network and may take on the tasks of multiple control devices (in some cases in some of the domains described above).

[0035] Vehicle 20 may further include central persistent memory 41 (i.e., memory that permanently stores information in the vehicle for longer than, for example, a day or a week, and / or while the vehicle is idle). In some examples, persistent memory 41 may include flash memory. In the example in Figure 2, persistent memory 41 is located on or directly connected to the central communication interface of vehicle 20. As described above, a central device 25 for software tamper mitigation may be located on the central communication interface of vehicle 20. Even when the central device for software tamper mitigation is located on another component (as an addition or replacement), persistent memory may be located on the same component as well, as an addition or replacement. In this way, data stored in persistent memory can be used by the central device for software tamper mitigation for tamper mitigation. In other examples, the central device for software tamper mitigation and persistent memory may be located on different components of the in-vehicle network (the central device for software tamper mitigation can access persistent memory via the network).

[0036] 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 with a storage capacity exceeding 256 MB (preferably exceeding 5 GB).

[0037] Countermeasures against tampering may include resetting the software of the component in which software tampering has been detected (also referred to in this disclosure as the “first component”) using software components 42a, 42c~n stored in the central persistent memory 41 for each component. Further embodiments of this countermeasure will be discussed below with reference to Figures 3 and 4.

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

[0039] 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 may also be a wired interface (not shown in Figure 2) in other examples. 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 related to the vehicle) during vehicle operation.

[0040] In some cases, 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 as a bundle). The software bundle or software container 31 (often quite large) 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, the software update information 32a, 32c-n obtained from the remote system 30 may undergo one or more preparation steps (e.g., unpacking and signature verification).

[0041] Additionally or alternatively, software update information 32a, 32c~n (e.g., in a software bundle or software container) may be received via the wired interface 22.

[0042] The software update information 32a, 32c~n may be stored in persistent memory 41 as software components 42a, 42c~n relating to the multiple components 27a, c~n before or after the preparation step (for example, before being used to update the software of components 27a, c~n). The stored software components 42a, 42c~n relating to the multiple components 27a, c~n are then made available to the central device 25 for software tamper mitigation in order 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, within the period until further software update information 32a, 32c~n is received).

[0043] In this way, the techniques of the present disclosure can, in some examples, utilize components already present in the vehicle, such as persistent memory 41 used in the software update process of the vehicle 20. In some cases, this can result in significant component savings (as described above, the memory required to store the software bundle or software container 31 of software update information 32a, 32c~n can be quite large). Additionally or alternatively, it can be avoided to provide additional resources (e.g., memory) to individual components, which can reduce complexity, and therefore error and / or cost. Further additional or alternatively, the information in persistent memory 41 is available quickly in many situations, regardless of the availability of the vehicle's communication channels. This can improve the response time of the tamper-mitigation method.

[0044] In the techniques of this disclosure, mitigation measures can be implemented essentially without the assistance of external systems (e.g., remote systems 30) of the vehicle 20. For example, the measures can be initiated 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 may communicate with external systems of the vehicle 20 for other purposes). Additionally or alternatively, the central device 25 for mitigating software tampering (or other components of the in-vehicle network) can implement measures without requiring communication with external systems of the vehicle 20.

[0045] In some examples (see step 105 in Figure 1), the techniques of the present disclosure may include selecting one of several measures 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.

[0046] The operating state may include not only the vehicle's driving state (e.g., high-speed driving, low-speed driving, performance of specific driving operations, etc.) but also the operating state when the vehicle is not in motion. Alternatively or additionally, contextual information about the vehicle 20 may include environmental information and / or status information of the vehicle's components.

[0047] The rules for operating vehicle 20 may include certain safety standards (which may depend on the operating state of vehicle 20, for example, determining when and under what dependencies measures for a particular component may be initiated).

[0048] Contextual information may be stored, at least partially, 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, part of the contextual information that includes information about predetermined rules for operating the vehicle 20). In some examples, the contextual information may be updated from outside the vehicle 20 (e.g., as part of software update information 32b about the central device 25 for mitigating software tampering, or the component on which the central device 25 for mitigating software tampering is located).

[0049] In some cases, various countermeasures may be available to mitigate specific software tampering in components 27a, c-n (the possible countermeasures are described further below). Here, context information can be used to select one of the available countermeasures. In some cases, from among several available countermeasures, a countermeasure may be selected that allows the component to be restored to its target state as much as possible (i.e., to repair the tampering as much as possible). On the other hand, in some situations, available countermeasures may be excluded based on rules contained in the context information (for example, when certain security standards are violated).

[0050] For example, the first countermeasure may mitigate tampering more effectively than the second countermeasure, but may require deeper intervention in the vehicle's components (and thus increase the risk of disturbances that may be caused by the mitigation process itself). The second countermeasure may mitigate tampering less effectively than the first countermeasure, but may also require less deep intervention in the vehicle's components. In this case, the first countermeasure may be selected in the first context (represented by contextual information), and the second countermeasure may be selected in the second context (represented by contextual information). For 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 safety standards, and compliance with these safety standards may prohibit the implementation of the first countermeasure in the first situation, but permit it in the second situation.

[0051] In some cases, countermeasures may include immediately resetting the software of the first component 27a, c~f (e.g., within 5 minutes or 1 minute) using software components 42a, c~n (e.g., generated based on received software update information) stored in the central persistent memory 41 for the components 27a, c~f whose tampering has been detected, and later resetting the software of components 27a, c~f using the software components 42a, c~n for each component 27a, c~f. Again, immediate resets may be excluded in certain contexts (e.g., by safety criteria). For example, a later reset may occur within the period before the next startup process of each component 27a, c~f.

[0052] Further aspects of the technique of this disclosure will be described below with reference to Figures 3 and 4. Figure 3 shows the in-vehicle network according to Figure 2 with the first component 27c tampered with. Figure 4 shows the in-vehicle network according to Figure 2 with the tampering with the first component 27c restored.

[0053] First, several embodiments for 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, and this recognition involves, in some examples, the reception of a signal. This signal may be generated in a variety of ways.

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

[0055] In Figure 3, the software of one control device 27c (referred to as "the first component" in some examples of this disclosure) has been tampered with. The tampered software component 71 has been introduced.

[0056] The (tampering) detection device 81a of the control device 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 is then processed as described above, and mitigation can be initiated.

[0057] 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 device 27c and generate a signal for a central device 25 (also located on the vehicle 20's central communication interface in the example of Figure 3) to mitigate software tampering. Thus, in some examples, the central device 25 for mitigating software tampering is also designed to centrally detect software tampering in multiple components 27a, c-f of the in-vehicle network.

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

[0059] Various detection devices 81a, 61b (in particular, detection devices 81a, 61b located inside the vehicle) may be detection devices already present in the (in-vehicle) network. As mentioned above, software tampering can be detected by several known methods.

[0060] Tampering detection can be carried out in any conceivable way. For example, software may be checked at startup ("Secure Boot") and / or during operation ("Runtime Tampering Detection") by one or more methods to check the authenticity and / or integrity of the software (e.g., using one or more digital signatures).

[0061] In other examples, a signal that indicates potential tampering in the absence of that signal may be generated by the component described in the previous section. For example, the (tampering) detection device 81a of the control device 27c may generate a signal (e.g., periodically or when a specific event occurs) and the absence of that signal may indicate tampering with the software of the control device 27c.

[0062] Next, with respect to Figures 3 and 4, further embodiments of measures to reset the software of the first component 27c using the software component 42c stored in the central persistent memory 41 relating to the first component 27c will be discussed.

[0063] The central device 25 for mitigating tampering can select countermeasures based on the detection of tampering in the first component 27c. In the examples of Figures 3 and 4, a software reset of the first component 27c is selected as the countermeasure. The reset may include restoring the software to its last authenticated state. This may include deleting and / or overwriting part or all of the software of the first component 27c (e.g., a control device). The deletion and / or overwriting of part or all of the software of the first component 27c may 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 tampered software component 71 or parts thereof 81a, 81b may be replaced with genuine (i.e., untampered) software component 52c or parts thereof 53a, 53b to repair the tampering.

[0064] The genuine (i.e., unmodified) software 52c can be called from persistent memory 41. As already stated, persistent memory 41 may contain the software component 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 the tampered software component 71 of the first component 27c.

[0065] In some cases, the tamper-mitigating central device 25 can implement measures to ensure the authenticity of software components 42a, c~n used for resetting the component's software. For example, an authenticity check may be performed before the use of software components 42a, c~n (e.g., based on a digital signature or other security feature). For authenticity checks, the tamper-mitigating central device 25 may rely on the functionality of the component into which the tamper-mitigating central device 25 is integrated.

[0066] In some examples, persistent memory 41 may contain multiple versions of a software component relating to a specific component of the in-vehicle network. In this case, a central device 25 for mitigating tampering may select one of the versions (for example, the current version of the software component).

[0067] In the previous section, with reference to Figures 3 and 4, measures to mitigate tampering with the first component 27c of the in-vehicle network were described. However, the central device 25 for mitigating tampering is configured to initiate measures against software tampering of one or more of the components 27a, d to f at a time separate from, or simultaneously with, the mitigation of software tampering of the first component 27c.

[0068] In some examples, 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 initiate further measures to mitigate the tampering of those components 27a, d-f. Tampering detection and initiation of countermeasures can be carried out in the same manner as described above. For example, the tampered software components of the further components 27a, d-f may be reset.

[0069] In this way, a single central device for mitigating tampering can maintain multiple components located remotely from the central device within the in-vehicle network (e.g., control devices in different domains) (i.e., repair software tampering on multiple components).

[0070] In the previous section, a component software reset was described as an exemplary measure initiated by a central device to mitigate tampering (and further implemented in some examples).

[0071] In some cases, a central device designed to mitigate tampering may initiate (and in some cases implement) other measures as alternatives or additions. In some cases, 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 (e.g., for a certain period of time). For this reason, in some cases (e.g., in a context where failure of the first component 27c is unacceptable or undesirable, at least in the short term), blocking communication of the first component 27c over the in-vehicle network may be preferable to resetting the software of the first component 27c. Countermeasures to reset the software of the first component 27c may be initiated following countermeasures to block communication of the first component 27c (e.g., in the modified context).

[0072] Alternatively or additionally, countermeasures against tampering may include blocking communication of the component group containing the first component 27c via the in-vehicle network. In the example of Figure 3, the first component 27c may be contained in the first domain 26a together with further components 27a,b. Blocking communication of the component group via the in-vehicle network is similar to blocking individual components as described above. Here again, damage can be prevented from being caused by the component group within the in-vehicle network. Even in the case of blocking communication of the component group via the in-vehicle network, countermeasures to reset the software of the first component 27c may be initiated at a later point in time (e.g., in the modified context).

[0073] As an alternative or additional measure, countermeasures against tampering may include modifying the functionality of the first component 27c in which the tampering was detected. For example, the functionality may be restricted according to a predetermined pattern (e.g., to functionality required with respect to specific safety-related aspects in any given context).

[0074] As an alternative or additional measure, countermeasures against tampering may include shifting the functionality of the first component 27c, where the tampering is detected, to one or more other components of the multiple components 27a, b, d-f. For example, one or more other components of 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 may then be deactivated and / or blocked. In this case as well, countermeasures to reset the software of the first component 27c may be initiated at a later point in time (e.g., in the modified context).

[0075] In the previous section, the techniques of this disclosure were often described on a basis of the respective methods. However, 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 implement the steps of the methods of this disclosure. As mentioned above, the central device for mitigating software tampering may be a standalone device (i.e., a dedicated module that is part of the in-vehicle network and has its own hardware and software resources that can communicate with other components of the in-vehicle network). However, in other cases, the central device for mitigating software tampering is integrated into other (existing) components of the in-vehicle network, where the central device for mitigating software tampering may be configured as a software module (inserted into the component's software). In other cases, the central device for mitigating software tampering may comprise at least several dedicated hardware components (while the central device shares other hardware components of the component into which it is integrated). As also mentioned above, the other components may be the central communication interface of the in-vehicle network, a central computer ("vehicle computer"), or other components with relatively high-performance hardware.

[0076] In some cases, existing components of the in-vehicle network (e.g., the vehicle's central communication interface or vehicle domain, the vehicle's central computer, or the infotainment system's head unit) can be configured as a central device to mitigate software tampering through software updates of the in-vehicle network components.

[0077] A central device for mitigating software tampering, or any other component in which it is integrated, includes at least one processor (possibly with multiple cores) and memory containing instructions, the instructions performing a step of the method of the present disclosure when executed by the processor.

[0078] This disclosure further relates to an in-vehicle network for a vehicle, comprising at least one central device for mitigating software tampering by this disclosure and a plurality of components of the in-vehicle network. The central device for mitigating software tampering can, in some cases, detect software tampering in the plurality of components and initiate countermeasures (as described above).

[0079] This disclosure further relates to vehicles, including in-vehicle networks, as a result of this disclosure. This disclosure further relates to a computer program designed to perform the methods described herein.

[0080] This disclosure further relates to a computer-readable medium (e.g., a DVD or solid-state memory) containing the computer program 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]

[0081] 20 vehicles 25. Central device to mitigate software tampering 26a Group of components 27a~f Components 30 External Systems 32a~n Software Update Information 41 Central persistent memory 42a, c~n Software Components 61b Tamper detection device

Claims

1. A computer-implemented method, comprising: a step (101) of recognizing, by a central device (25) for reducing software tampering, a possibility of software tampering of a first component (27c) among a plurality of components (27a-f) of an in-vehicle network of a vehicle (20), wherein the central device (25) for reducing the tampering is a part of the in-vehicle network and is designed to reduce the software tampering in each of the plurality of components (27a-f) of the in-vehicle network; a step (103) of starting, by the central device (25) for reducing the tampering, a countermeasure for reducing the software tampering of the first component (27c); and a method comprising the above.

2. The countermeasure against the tampering includes resetting the software of the first component (27c) using a software component (42c) stored in a central persistent memory (41) related to the first component (27c), wherein the central persistent memory (41) is designed to simultaneously store software components (42a, c-n) related to each of the plurality of components (27a-f); The method according to claim 1.

3. a step of receiving software update information (32a-n) for each of the plurality of components (27a-f) in the vehicle (20); a step of updating the software of each of the plurality of components (27a-f) using the software update information (32a-f); and after completion of the software update of each of the plurality of components (27a-f), a step of storing the software update information (32a-f) in the persistent memory (41) for use by the device (25) for reducing the tampering, and forming the software components (42a, c-n) related to each of the plurality of components (27a-f); The method according to claim 2, further comprising the above.

4. The method according to claim 1, wherein the countermeasure for the reduction is implemented substantially without the assistance of a system (30) external to the vehicle (20).

5. Further including a step (105) of selecting the countermeasure from a plurality of countermeasures based on context information regarding the vehicle (20), and optionally, the context information contains information regarding the operating state of the vehicle (20) and / or information regarding a predetermined rule for the operation of the vehicle (20). The method according to claim 1.

6. The method according to claim 5, wherein the countermeasure includes immediately resetting the software of the first component (27c) using a software component (42c) stored in a central persistent memory (41) regarding the first component (27c), and resetting the software of the first component (27c) later using a software component (42c) regarding the first component (27c).

7. The countermeasure against the tampering is cutting off the communication of the first component (27c) via the in-vehicle network, cutting off the communication of a group (26a) of components including the first component (27c) via the in-vehicle network, and changing the function of the first component (27c) and / or shifting the function of the first component (27c) to one or more other components among the plurality of components (27a, b, d - f). The method according to claim 1, including one or more of the above.

8. Optionally, a step of recognizing the tampering of the software of the first component (27c) by a further component (27a) of the central device (25) or the in-vehicle network's tampering detection device (61b) for reducing the tampering; generating a signal indicating the tampering of the software of the first component (27c) among the plurality of components of the in-vehicle network; further including the recognition (101) of the possibility of tampering being performed based on a signal indicating the tampering of the software of the first component (27c) among the plurality of components of the in-vehicle network. The method according to claim 1.

9. The method according to claim 1, wherein the plurality of components (27a - f) of the in-vehicle network include one or more control devices, and / or the first component (27c) is a control device.

10. A central device (25) for reducing software tampering of a plurality of components (27a-f) of an in-vehicle network of a vehicle (20), the central device (25) being designed to perform the steps according to any one of claims 1 to 9.

11. An in-vehicle network for a vehicle (20), a central device (25) for reducing software tampering according to claim 10, and a plurality of components (27a-f) of the in-vehicle network An in-vehicle network including the same.

12. A vehicle (20) including the in-vehicle network according to claim 11.

13. A computer program designed to perform the method according to any one of claims 1 to 9.

14. A computer-readable medium or signal containing or encoding the computer program according to claim 13.

Images