Reduction in manipulation of vehicle software

Abstract

To reduce manipulation of vehicle software.SOLUTION: A method includes a step of, in a central device for reducing manipulation of software, recognizing the possibility of manipulation of software of a first component of a plurality of components for an on-vehicle network of a vehicle. The central device is a part of the on-vehicle network and is designed to reduce manipulation of software in each of the plurality of components for the on-vehicle network. The method further includes a step of introducing measures for reducing manipulation of the software of the first component, and a step of executing the measures for reducing manipulation of the software of the first component. The measures include changing the functionality of the first component, and transferring at least part of the functionality of the first component to one or more other components of the plurality of components.SELECTED DRAWING: Figure 4

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, while 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 an even more diverse manner.

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

Summary of the Invention

Problems to be Solved by the Invention

[0004] In some ways of the current state of the art, detecting tampering and especially reducing it (i.e., repair such that a defined (safe) state is achieved) involves a significant amount of labor and thus a time delay. For example, in the framework of factory maintenance, the tampered software of a component (e.g., a control device) can be reset and thus the tampering can be repaired. In other techniques, a remote computer system can request the software, and by this technique, the tampered software of a component (e.g., a control device) is reset and thus the tampering is repaired. In either case, there can be a significant period between detecting tampering and reducing it. Depending on the situation, the operation of the vehicle is hindered during this period (e.g., a predetermined 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. The method includes the step of recognizing the possibility of software tampering in a first component of a plurality of components of a vehicle's in-vehicle network in a central device for mitigating software tampering. The central device for mitigating tampering is part of the in-vehicle network and is designed to mitigate software tampering in each of the plurality of components of the in-vehicle network. The method further includes the steps of introducing measures to mitigate software tampering in the first component and implementing measures to mitigate software tampering in the first component. The measures include changing the functionality of the first component and migrating the functionality of the first component to one or more other components of the plurality of components, at least partially. The in-vehicle network is also designed to perform changes in functionality and at least partial migrations in the event of a violation of one or more operational state-related criteria of the first component and / or the vehicle.

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

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

[0008] The techniques of the first to fourth general aspects of this disclosure may, in some cases, have one or more of the following advantages: Firstly, by modifying the functionality of the first component and transferring the functionality of the first component to one or more other components among a plurality of components, it may be ensured that, in some circumstances, certain functionality of the vehicle is still provided after tampering and / or that the functionality is not impaired by a new attack on the first component. For example, the first component can provide the braking functionality of the vehicle (and, for example, access the corresponding actuator in the form of a brake booster). Tampering with the first component may allow an attacker to attempt to cause over-braking of the vehicle. Here, the techniques of the present disclosure can ensure that, after the tampering is recognized, the first component is not used to provide the braking functionality, or is used only to a limited extent (i.e., the functionality of the first component is modified). In this way, an attack can be prevented from intentionally exploiting the first component. In addition, further components may (at least partially) provide the braking functionality within the vehicle (i.e., the braking functionality is at least partially transferred to further components, such as an ESC control unit). This ensures that the vehicle retains braking functionality (according to the requirements profile) even after software tampering. In addition, the functional transition can, in some cases, prevent an attacker from again attacking the vehicle's braking functionality by tampering with the software of the first component.

[0009] Secondly (and as a result of the first advantage), means already implemented in the vehicle for the purpose of being performed when one or more operational state-related criteria of the first component and / or vehicle are violated can be "adapted." Thus, in some cases, the technique of the Disclosure can be implemented at a relatively low cost. In the above example, the transition of brake functionality may already be provided for cases where braking of the vehicle by the first component (e.g., brake booster) is impossible. For example, there may be a defect in the brake booster. This operational state may be detected in the vehicle, and the brake functionality may be transferred to a further component (ESC control unit). Here, the technique of the Disclosure can also be used when software tampering is detected. Therefore, in some situations, the costly implementation of a transition mechanism can be avoided.

[0010] Some terms are used in this disclosure as follows: In other words, a “component” (of an in-vehicle network) in this disclosure comprises its own hardware resources, including at least one processor for executing instructions and memory for storing at least one software component. The term “processor” also includes a multi-core processor or a group of separate components that undertake (and possibly share tasks with) a central processing unit of an electronic device. Components can independently perform tasks (e.g., measurement tasks, monitoring tasks, control tasks, communication tasks, and / or other operational tasks). However, in some examples, components can also be controlled by other components. Components may be physically isolated (e.g., using their own housing) or integrated into a higher-level system. Components may be vehicle control devices or communication devices. Components may be embedded systems. Components may include one or more microcontrollers.

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

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

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

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

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

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

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

[0018] The phrase "recognition of the possibility of..." means that certain events (e.g., a signal, or the absence of a signal) are interpreted according to predetermined rules in order to recognize a state in which software tampering may occur.

[0019] In this disclosure, "functionality" refers to the ability of each component to perform a specific task within a vehicle. For example, a task could be the operation of one or more systems in the vehicle (e.g., engine, transmission, assistance systems, sensors, air conditioning, infotainment, communication interfaces, etc.). In other examples, or additionally, a task could be the performance of driving operations (or parts of driving operations), which may be performed autonomously or with assistance (these may vary in complexity, for example, braking, steering, driving along a specific route, or parking). In yet another example, a task could be the provision of data (e.g., sensor data) (which may be used for other tasks).

[0020] "Operating state" includes state information relating to the vehicle and / or its components and / or the vehicle's environment. The operating state may be defined by one or more state parameters of the vehicle and / or its components and / or its environment. State parameters may be measured or calculated parameters of the vehicle and / or its components, and / or variables derived from these parameters (e.g., the temperature of a component, or a derived variable indicating the state of the vehicle and / or its components). The operating state may be determined by monitoring the vehicle and / or its components (e.g., monitoring whether the vehicle and / or its components are behaving according to specific specifications). [Brief explanation of the drawing]

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

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

[0023] 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 the in-vehicle network.

[0024] In FIG. 1, in the central column, steps that can be performed by a central device (but also by other components in other examples) in some examples to reduce software tampering are shown. In the right column, steps executed 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, steps performed by a remote system (i.e., outside the vehicle) are shown.

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

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

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

[0028] In some examples, recognition may include receiving a signal indicating software tampering in a first component 27c 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.

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

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

[0031] In response to the recognition of the possibility of software tampering in the first component 27c of the vehicle's in-vehicle network (for example, the recognition of signal reception or signal absence), measures to mitigate tampering with the first component are introduced and implemented.

[0032] This measure includes modifying the functionality of the first component 27c 115, and transferring at least partially the functionality of the first component 27c to one or more other components from among the multiple components 27a, b, d to f 103.

[0033] In some examples, the modification 115 of the functionality of the first component 27c may include turning off the functionality of the first component 27c, that is, the first component 27c no longer provides functionality. To that end, the first component 27c may be deactivated and / or shut down.

[0034] In other examples, the functionality modification 115 may include restricting the functionality of the first component 27c. For example, the first component 27c may be designed to provide specific functionality at multiple qualitative or quantitative levels (e.g., with predetermined qualitative or quantitative characteristics, alone or in combination with further components, under various operating conditions, etc.). The restriction may include switching the first component 27c from providing functionality at a first level to providing functionality at a second level.

[0035] The transfer of functionality from the first component 27c to one or more other components from among the multiple components 27a, b, d-f 103 may include one or more other components 27a, b, d-f from among the multiple components taking on at least temporarily the tasks (or parts thereof) of the first component 27c. In some examples, the functionality from the first component 27c may be transferred entirely to one or more other components from among the multiple components 27a, b, d-f (i.e., the first component 27c is no longer involved in providing functionality, and the functionality is fully provided by the other components 27a, b, d-f).

[0036] In the techniques of this disclosure, the in-vehicle network is designed to perform changes in functionality and at least partial transitions if one or more operational state-related criteria of the first component 27c and / or the vehicle 20 are violated. The operational state-related criteria can determine whether and / or to what extent the first component 27c and / or the vehicle 20 are operating according to a given specification (i.e., when the operational state-related criteria are violated, the first component 27c and / or the vehicle 20 are not operating according to the given specification). In some examples, checking the operational state-related criteria may include evaluating one or more state parameters of the vehicle 20 and / or its components and / or its environment (e.g., generated by monitoring the vehicle 20 and / or its components and / or its environment). Checking the operational state-related criteria may include, for example, checking whether the vehicle 20 and / or its components are operating normally or abnormally (e.g., whether driving operations are being performed according to specification). As an addition or alternative, checks of operating state-related criteria may include, for example, checking whether one or more state parameters of the vehicle 20, the environment of the vehicle 20, and / or components of the vehicle 20 are within a predetermined range (e.g., whether the temperature of a component or the field of view of a sensor is within a specific range). Thus, the techniques of the present disclosure allow for changes and at least partial transitions in functionality to be performed even after the detection of software tampering (i.e., intrusion) and in the presence of a specific operating state of the vehicle (e.g., operation of the vehicle 20 and / or its components outside of a predetermined specification).

[0037] In some examples, one or more operational state-related criteria may be operational safety criteria for the first component 27c and / or vehicle 20 (operational safety is also called "functional safety" or "Safety" in English). Operational safety criteria and their checks may be performed as described above. For example, operational safety criteria may determine whether and / or to what extent the first component 27c and / or vehicle 20 are operating according to a given (safety) specification (i.e., if one operational safety criterion is violated, the first component 27c and / or vehicle 20 are considered not to be operating according to a given (safety) specification and are therefore unsafe). In the case of functionality critical to operational safety (e.g., functionality related to driving operations), it is likely that the in-vehicle network is designed to facilitate at least partial migration of functionality anyway (i.e., the in-vehicle network is designed to be at least partially redundant with respect to functionality). However, the techniques of this disclosure are not limited to functionality critical to operational safety. In other words, even for functionalities that are not critical to operational safety (e.g., air conditioning or infotainment functions), the possibility of at least partial transfer of functionality to other components may be considered.

[0038] In some examples, the mitigation central device 25 can coordinate the transfer of at least a partial functionality of the first component 27c to one or more other components 27a, b, d-f (i.e., the mitigation central device 25 introduces the transfer steps and / or possibly instructs the other components). To this end, the mitigation central device 25 can instruct one or more other components 27a, b, d-f to at least partially assume the functionality of the first component 27c. In some examples, the coordination may also include ensuring that functionality within the vehicle 20 is provided in accordance with the current requirements profile (i.e., according to predetermined specifications in each state of the vehicle and / or its environment). In some examples, this may also include ensuring that functionality within the vehicle 20 is provided by components. As an addition or alternative, the coordination may also include ensuring that a particular functionality is not provided (simultaneously) by multiple components (which may, in some cases, lead to the requirements profile being "over-achieved" and therefore similarly malfunctioning). Using a central device 25 to mitigate tampering, coordinating at least partial migration of the functionality of the first component 27c to one or more other components 27a, b, d-f can, in some circumstances, prevent an attacker from tampering with the software of the first component 27c and thus hindering countermeasures using the techniques of this disclosure.

[0039] In some examples, communication for at least partially transferring the functionality of the first component 27c to one or more other components from among the multiple components 27a, b, d-f may be protected by one or more encryption methods. In some examples, communication may take place between the first component 27c and a tamper-resistant central device 25, and / or between the tamper-resistant central device 25 and one or more other components from among the multiple components 27a, b, d-f. For example, communication may be encrypted. Additionally or alternatively, communication may be performed using digital signatures (to authenticate the participants, e.g., the source of requests to activate and / or deactivate write locks). Further additionally or alternatively, communication may be hidden within the vehicle's data stream using obfuscation methods. Further additionally or alternatively, communication may be protected by timestamps that can be evaluated by the participants in the communication to check the communication (e.g., participants in the communication reject messages older than a predetermined threshold age). In some examples, the first component 27c, the central device 25 for mitigating tampering, and / or security modules of one or more other components 27a, b, d-f 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; a further explanation of security modules is provided below in relation to Figure 3).

[0040] Herein, with reference to Figure 3, embodiments of the first component 27c will be further described (other components of the present disclosure may similarly have the structures described). The first component 27c comprises memory 91. For example, memory 91 may be non-volatile memory (e.g., EPROM memory or flash memory). Memory 91 may be designed to store at least one software component for the first component 27c (e.g., for controlling the first component 27c). 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.

[0041] The first component 27c may have a security module 93. The security module 93 may be separate in hardware and / or software from the rest of the modules of the first component 27c (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, for example, which can 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 in addition to the functions described herein (e.g., changing and / or migrating functionality) (e.g., managing cryptographic keys and / or signatures, encrypting or decrypting data, and one or more of the other cryptographic functions). 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 a Hardware Security Module (HSM). In the example in Figure 3, the security module 93 is the internal security module of component 27c. In other examples, the security module may be an external security module for component 27c (for example, an external security module included in another component of the vehicle 20, e.g., a central device 25 for mitigating software tampering).

[0042] In some cases, changes to the functionality of the first component 27c may be performed by the security module 93 of the first component 27c. For example, the security module may send instructions (e.g., to the processor of the first component 27c) to change the functionality of the first component (e.g., to turn off at least part of the first component). The security module 93 may be configured to enforce the change in functionality (e.g., to override other modules of the first component 27c). In this way, in some situations, tampering with the software of the first component 27c by an attacker may also be prevented from interfering with the implementation of measures to change the functionality of the first component 27c. Tampering with the security module 93 can be (considerably) more difficult than tampering with other modules of the first component. In addition, since an existing security module is reused, in some cases the security improvements described can be achieved without significant changes to the component's hardware.

[0043] In some cases, the transfer of functionality of the first component 27c to one or more other components 27a, b, d-f may be coordinated by the security module 93 (rather than by the central device 25 for mitigating software tampering, as described above). To this end, the security module 93 may send corresponding instructions to one or more other components 27a, b, d-f and / or other components of the in-vehicle network.

[0044] 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 of a central processing unit of an electronic device. In some examples, component 27c may include one or more interfaces 95 designed to communicate over 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 may have direct access to one or more interfaces 95 to communicate over the transmission path 96 of the in-vehicle network (direct access to one or more interfaces 95 may be advantageous when the security module coordinates functional transitions). The transmission path may be a transmission path of a bus system (e.g., CAN, LIN, MOST, FlexRay, or Ethernet).

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

[0046] At a certain point in time, the software of the first component 27c (or main unit 403) may be tampered with 410, as shown in Figure 4. The tampering can be detected by the security module 93 of the first component 27c 415. The security module 93 can then change the functionality of the first component 27c. For example, it can shut down the main unit 403 417. Alternatively or additionally, the security module 93 can put the main unit 403 into a state where the tampered software can be reset (e.g., reprogramming mode). The first component 27c can no longer (or only to a limited extent) provide functionality.

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

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

[0049] In either case, after the functional changes and transitions have been implemented, the vehicle may be in a safe state (in accordance with the prescribed safety standards). The tampering can be corrected (for example, by resetting the software of the first component 27c 418, as further described below).

[0050] The following sections describe embodiments of the central device 25 for mitigating software tampering. An example of the central device 25 for mitigating software tampering is shown in Figure 2. In some cases, the vehicle may have 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 that can repair software tampering, or a subset of these components), in particular to coordinate the transition of component functionality. In other examples, the vehicle may have multiple central devices for mitigating software tampering, which are part of an in-vehicle network, each assigned to multiple components of the in-vehicle network (i.e., capable of repairing software tampering in the assigned component). However, in both cases, the central device for mitigating software tampering is isolated from the assigned component. In some cases, the central device 25 for mitigating software tampering may also be designed to mitigate its own software and / or the software of the component into which the central device 25 for mitigating software tampering is integrated.

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

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

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

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

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

[0056] Countermeasures against tampering may include, in addition to changes and migrations in functionality, a software reset of the component in which the software tampering is recognized (also referred to in this disclosure as the “first component”) (for example, using software components 42a, 42c~n stored in the central persistent memory 41 for each component). Further embodiments of these further countermeasures will be discussed below with reference to Figures 5 and 6.

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

[0058] Software update information 32a, 32c~n can be received via interface 21 of the vehicle 20. Interface 21 may be a wireless interface (as illustrated in Figure 2), but in other examples it may also 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, 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, 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).

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

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

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

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

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

[0064] In some examples, the techniques of the present disclosure may include selecting one further action (in addition to changes and transitions in functionality; hereinafter simply referred to as the “further action”) from among several further actions 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.

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

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

[0067] 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 the software update information 32b for the central device 25 for mitigating software tampering, or as part of the software update information 32b for the component on which the central device 25 for mitigating software tampering is located).

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

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

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

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

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

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

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

[0075] 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 introduce and implement mitigation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0090] 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 (for example, for a certain period of time). For this reason, in some cases, blocking communication of the first component 27c over the in-vehicle network may be preferable to resetting the software of the first component 27c (for example, in a context where failure of the first component 27c is unacceptable or undesirable, at least in the short term). 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 (for example, in a modified context).

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

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

[0093] This disclosure further relates to an in-vehicle network for a vehicle, which includes a central device for mitigating software tampering by at least one of the disclosures, and several components of the in-vehicle network. The in-vehicle network may be designed to perform the techniques of the 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 a vehicle and integrated into the in-vehicle network).

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

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

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

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

Claims

1. 1. A computer-implemented method comprising: A step (101) of recognizing, in a central device (25) for software tampering mitigation, a possibility of software tampering of a first component (27c) of a plurality of components (27a-f) of an in-vehicle network of a vehicle (20), comprising: a step (101) in which the central device for tampering (25) is part of the in-vehicle network and is designed to mitigate software tampering in each of the plurality of components (27a-f) of the in-vehicle network; Implementing (103) countermeasures to mitigate said tampering of said software of said first component (27c); implementing the measures to mitigate the tampering of the software of the first component (27c); Including, the measures include modifying the functionality of the first component (27c) and at least partially migrating the functionality of the first component (27c) to one or more other components of the plurality of components (27a, b, d-f); the in-vehicle network is also designed to perform a change in functionality and at least a partial transition if one or more operational state-related criteria of the first component (27c) and / or the vehicle (20) are violated. method.

2. The method of claim 1 , wherein the one or more operational condition-related criteria are operational safety criteria of the first component (27c) and / or the vehicle (20).

3. 2. The method of claim 1, wherein the modification of the functionality of the first component is performed by a security module of the first component, and optionally the security module is a hardware security module of the first component.

4. 2. The method of claim 1, wherein the central device for tamper mitigation (25) coordinates the transfer of the functionality of the first component (27c) to the one or more other components (27a, b, d-f).

5. The method of claim 4, wherein the adjustment comprises ensuring that the functionality within the vehicle (20) is provided in accordance with a current requirements profile.

6. 2. The method of claim 1, wherein the modifying the functionality of the first component (27c) comprises turning off the functionality of the first component (27c) or limiting the functionality of the first component (27c).

7. 2. The method of claim 1, wherein communications for at least partially transferring the functionality of the first component (27c) to the one or more other components of the plurality of components (27a, b, d-f) are protected by one or more encryption methods.

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

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

10. A vehicle (20) including a system according to claim 8.

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

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

Images