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 of an on-vehicle network for a vehicle. The central device for reducing manipulation is a part of the on-vehicle network and is designed to reduce manipulation of software in each of the plurality of components of the on-vehicle network. The method further includes a step of introducing measures for reducing manipulation of the software of the first component, and a step of executing the measures for reducing manipulation of the software of the first component, by the central device for reducing manipulation. The measures for reducing manipulation include means for preventing recurrence of manipulation that is selected based on analysis of information on data traffic occurring in the on-vehicle network before the recognition of the possibility of manipulation.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] Regarding vehicle software. [Background technology]

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

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

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

[0005] A first general aspect of the present disclosure relates to a computer-implemented method, the method including: recognizing, at a central device for software tampering mitigation, possible software tampering of a first component among a plurality of components of an in-vehicle network of a vehicle. The central device for tampering 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 installing, by the central device for tampering mitigation, a countermeasure for tampering with the software of the first component; and implementing the countermeasure for tampering with the software of the first component. The countermeasure for tampering mitigation includes means for preventing recurrence of the tampering, the countermeasure being selected based on an analysis of information about data traffic that occurred in the in-vehicle network prior to the recognition of the possible tampering.

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

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

[0008] The techniques of the first through fourth general aspects of the present disclosure may, in some cases, have one or more of the following advantages. First, the techniques of this disclosure can protect the in-vehicle network of one vehicle and possibly additional vehicles from (repeated) tampering. Thus, in some situations, tampering with a vehicle's in-vehicle network can be reliably repaired by countermeasures. For example, first, resetting the tampered software can secure the in-vehicle network. Nevertheless, in some situations, vulnerabilities in the in-vehicle network may remain that an intruder can exploit for new attacks. For example, an insufficiently secured in-vehicle network interface may create a vulnerability that an intruder could exploit to insert tampered software. The techniques of this disclosure can address this issue in some situations by implementing measures to prevent the recurrence of recognized tampering. Here, these measures are selected based on an analysis of information about data traffic in the in-vehicle network that occurred before the possible tampering was recognized. This information about the data traffic can enable the intruder to deduce which channel was used to tamper with the software. Here, the countermeasures can be specifically related to the identified channel. For example, the (suspected) interface through which data was transmitted before the component's software was tampered with can be disabled, thus preventing repeated exploitation of vulnerabilities by intruders.

[0009] Second, by selecting the correct measures to prevent the recurrence of tampering, in some situations the functionality of the in-vehicle network can be maintained to a greater extent than if other measures were implemented. For example, for the safe operation of the vehicle, it may be sufficient to disable a specific interface in which several components of the in-vehicle network have been tampered with. If this interface is closed, several components can in some cases continue to operate (possibly after a software reset of the components or after further measures). This allows for a greater availability of the vehicle's functionality compared to, for example, a situation in which the affected components are disabled.

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

[0011] An "embedded system" is a component that is embedded in a technological context, where the component assumes monitoring, control, or regulation functions and / or is responsible for some form of data or signal processing.

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

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

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

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

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

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

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

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

[0020] First, a vehicle in which the techniques of the present disclosure can be implemented and basic aspects of the techniques of the present disclosure will be discussed with reference to Figures 1 to 3. Further aspects of a central device for mitigating software tampering will be described with reference to Figures 4 and 5.

[0021] Figure 1 is a flowchart illustrating the techniques of the present disclosure, Figure 2 illustrates components of a vehicle's in-vehicle network that can use the techniques of the present disclosure, and Figure 3 illustrates various vulnerabilities of a vehicle's in-vehicle network.

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

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

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

[0025] In some examples, the central device for mitigating software tampering 25 is integrated into a central communication interface of the vehicle 20. The central communication interface may be designed to act as a data distributor for communication within the vehicle 20 and / or with the outside world via the communication interfaces 21, 22. Here, the central communication interface may support different communication protocols (for communication in 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) or designed as a standalone component.

[0026] The recognition may, in some examples, include receiving a signal indicative of software tampering of a first component 27c of the components of the in-vehicle network of the vehicle 20. The signal may be generated at the central device 25 itself and / or at another device for mitigating software tampering.

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

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

[0029] In response to recognizing possible software tampering of a first component 27c of the plurality of components of the in-vehicle network of the vehicle 20 (e.g., recognizing receipt of a signal or absence of a signal), a countermeasure for mitigating tampering of the first component is introduced by a central device for mitigating software tampering 103. A countermeasure for mitigating software tampering of the first component 27c is then implemented 105 (e.g., by the central device for mitigating software tampering and / or another component of the in-vehicle network). The countermeasure includes means for preventing recurrence of the tampering, selected based on analysis of information about data traffic on the in-vehicle network that occurred before the recognition of the possible tampering.

[0030] The analysis and / or selection may be performed by the central device 25 for mitigating software tampering. In other examples, the analysis and / or selection may be performed by one or more other components of the vehicle. Again, in other examples, the analysis and / or selection may be performed by the remote system 30. In either case, the analysis and / or selection may be performed automatically (i.e., without user involvement). To that end, the components capable of performing the analysis and / or selection may be equipped with corresponding functionality (e.g., defined in software). The analysis and / or selection function may be implemented in every conceivable form. For example, a rule-based algorithm may be implemented. In other examples, a machine learning module may perform the analysis and / or selection. The analysis and selection may be performed within a predetermined time (e.g., less than five minutes) after the recognition of tampering.

[0031] In some examples, the analysis may include discovering vulnerabilities in the in-vehicle network of vehicle 20, where the vulnerabilities may be portions of the in-vehicle network (e.g., one or more components of the in-vehicle network) through which the recognized tampering may have been performed.

[0032] In some examples, the analysis may include evaluating the content of data traffic generated before the recognition of possible tampering. Thus, for example, it may be possible to identify which portions of the data traffic contained data for programming processes (e.g., software components or other content for programming components, e.g., signatures typical of such data). Additionally or alternatively, the analysis may include the discovery of programming processes within data traffic generated before the recognition of possible tampering. Additionally or alternatively, it may be possible to identify which portions of the data traffic contained content that differs from known and / or expected content. For example, a particular portion of the data traffic may have included a broader range of data types than expected and / or different data types than expected. Additionally or alternatively, the data traffic may have occurred in a portion of the in-vehicle network where data traffic could not have been expected at a particular time. These evaluations may allow a conclusion to be drawn that the identified data traffic was data traffic in which the software of the first component was tampered with.

[0033] Additionally or alternatively, the analysis may include identifying a type of tampering that has been recognized. In some examples, identifying a type of tampering may include identifying a vehicle interface through which data traffic (e.g., data traffic containing specific content, as described above) occurred prior to the recognition of possible tampering. Additionally or alternatively, identifying a type of tampering that has been recognized may include identifying a path of the data traffic to the tampered first component 27c and / or identifying a source of the data traffic.

[0034] Aspects of identifying the type of recognized tampering are further described below with reference to Figure 3. Figure 3 illustrates various vulnerabilities in the in-vehicle network of vehicle 20 that may be exploited by an intruder for various types of tampering.

[0035] In some examples, it can be determined that the recognized tampering was preceded by data traffic through a particular interface 21, 22 of the vehicle 20 (represented in FIG. 3 by arrows extending to the interfaces 21, 22). The particular interface may be the wireless interface 21, but in other examples may also be a wired interface 22 (e.g., an interface for on-board diagnostics). An on-board network may have multiple wireless and / or wired interfaces. Information about the identified interface can be used to select measures to prevent recurrence.

[0036] Additionally or alternatively, it may be recognized that data traffic of a particular component of the in-vehicle network occurred before the recognized tampering (also represented in FIG. 3 by arrows ending near the respective component). This component may be, for example, the central communication interface 25 of the in-vehicle network. In another example, the component may be the central control unit 24 of the vehicle. Again, in another example, the component may be the head unit (in English, Head Unit) of the infotainment system of the vehicle 20. Again, in another example, the component may be the central computer ("vehicle computer") of the in-vehicle network (which may include multiple central computers ("vehicle computers")). The central computer ("vehicle computer") is (significantly) more powerful than the dedicated controllers of the in-vehicle network and may take over the tasks of multiple controllers (possibly in some of the domains described below).

[0037] Again, in other examples, the vehicle may be divided into multiple functional domains and / or local domains of the vehicle 20. A functional domain may include various vehicle components involved in providing a particular function of the vehicle (e.g., engine control, powertrain control, infotainment, climate control, etc.). A local domain may include various vehicle components physically located within a particular region of the vehicle (e.g., “right rear,” “left front,” “interior front,” etc.). A domain may include a component 27a, 27d that serves as a central communication node for and / or assumes control functions for the respective domain 26a-n. The central communication node for a domain may also be identified as the component from which data traffic originated prior to the recognized tampering. In some examples, a component (e.g., one of the components listed above) may be identified as the source of the data traffic inserted by a software component to tamper with the first component 27c. Information regarding the identified component may be used to select measures to prevent recurrence.

[0038] Additionally or alternatively, it may be recognized that data traffic to the vehicle occurred from an external source prior to the recognized tampering. In some examples, the analysis may include determining the temporal relationship between particular data traffic and the recognition of possible tampering. For example, the data traffic may have occurred less than a predetermined time (e.g., less than five minutes) before the recognition of tampering with the software of the first component 27.

[0039] When the type of perceived tampering is identified, appropriate measures to prevent recurrence can be selected. In some examples, the measures include prohibiting or restricting certain types of data traffic in vehicle 20. In some examples, the prohibition or restriction may include blocking certain components from communicating over the in-vehicle network (e.g., communications originating from a certain component). The certain component may be, for example, one of the components described above. Alternatively, the prohibition or restriction may include blocking certain types of communications of a certain component. For example, a certain component may be prohibited from transmitting data for a programming process. Alternatively or additionally, receiving data may be prohibited or restricted while still being allowed (or vice versa). Further alternatively or additionally, communications via a first protocol may be prohibited or restricted while communications via a second protocol remain permitted. Further alternatively or additionally, data traffic of a certain component may be limited to certain content. Further additionally or additionally, the prohibition or restriction may relate to certain external sources transmitting data to the vehicle. Thus, communications with one or more external sources may be limited or prohibited.

[0040] Alternatively or additionally, the measures may include turning off or limiting a particular component of the vehicle 20. In some examples, the particular component is an interface of the vehicle 20's in-vehicle network (e.g., wireless interface 21 or wired interface 22). In other examples, the particular component is a component in the in-vehicle network (e.g., one of the components described above). Limiting the functionality of the particular component may include turning off (some of) one or more functions of the particular component. For example, the particular component may continue to perform control functions while communication functions are turned off. The turned-off functions of the particular component may be assumed by another component in the in-vehicle network.

[0041] In all of the above examples, the means for preventing recurrence of tampering can intervene precisely in the in-vehicle network, thus reducing the risk of recurrence of tampering without requiring potentially extensive intervention in the operation of the vehicle in some cases.

[0042] In some examples, measures to prevent recurrence of tampering may be implemented not only in the vehicle in which possible tampering was identified, but also in other vehicles (even if the software in the other vehicle has not been tampered with or the possible tampering has not been identified, and thus, in this case, it is not necessarily a recurrence of tampering in the same vehicle, but a recurrence of (that type of) tampering in another vehicle). In other words, recognition of possible tampering of the software of a first component in a (first) vehicle 20 can trigger the implementation of measures in one or more other vehicles (e.g., vehicles in which a component corresponding to the first component is present, e.g., vehicles of the same type). In some examples, this occurs regardless of whether possible tampering of the software of the first component was identified in one or more other vehicles. In this way, multiple vehicles (e.g., vehicles in a particular geographic area and / or vehicles of a particular type) may be protected from a particular tampering. Measures to prevent recurrence of tampering may be deployed by a central tamper mitigation device in other vehicles as well. In some examples, another vehicle may be requested to implement the measures (e.g., via a remote system). In other examples, a (first) vehicle 20 may engage in vehicle-to-vehicle communication to notify another vehicle of its awareness of possible software tampering in a first component 27c of the plurality of components 27a-f of the vehicle's in-vehicle network. The measures may then be similarly implemented in the other vehicle.

[0043] In some examples, the results of the analysis of information about data traffic on the in-vehicle network may be logged, and the logged results may be used for tamper recognition (e.g., by one or more tamper detection devices on the vehicle, such as those described further below, which may be located on the vehicle or on external systems 30). The tamper detection devices may use the information in future detection processes. In this way, the likelihood of recurring tampering of a particular type being recognized may be increased (in the event that the techniques for preventing recurring tampering of the present disclosure fail).

[0044] In some examples, the methods of the present disclosure may further include disabling the means in response to an update of the on-board network of vehicle 20. For example, at a certain point in time (e.g., during factory maintenance or via a wireless interface), the source of the vulnerability may be eliminated (e.g., by updating the software of the component that creates the vulnerability). Thereafter, for example, the turning off or limiting of the component or the prohibition or restriction of certain types of data traffic within vehicle 20 may be lifted.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0070] The (tamper) 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), which can then be processed as described above to introduce the mitigation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0085] In some instances, the central tamper mitigation device may alternatively or additionally implement other further measures, which are also implemented in the in-vehicle network.

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

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

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

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

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

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

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

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

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

[0095] 20 vehicles 21, 22 Communication Interface 24 Central Control Unit 21-24, 25, 27a-f Multiple components 25 Central device / vehicle network central communication interface to mitigate software tampering 26a~n domain 27a-f Components / Control Devices 30 Remote Systems / Vehicles or External Systems 31 Software bundles or software containers 32a, 32c~n software update information 41 Persistent Memory 42a, 42c~n Software Components 52c Software Components / Software 53a, 53b Part of software component 52c 61b Detection Device 71 Software Components 81a Detection Device 81a, 81b Part of software component 71

Claims

1. 1. A computer-implemented method comprising: A step (101) of recognizing, in a central device (25) for software tampering mitigation, a possibility of software tampering of a first component (27c) of a plurality of components (27a-f) of an in-vehicle network of a vehicle (20), comprising: a step (101) in which the central device for tampering (25) is part of the in-vehicle network and is designed to mitigate software tampering in each of the plurality of components (27a-f) of the in-vehicle network; - implementing (103) measures to mitigate said tampering of said software of said first component (27c) by a central device (25) for mitigating said tampering; implementing the measures to mitigate the tampering of the software of the first component (27c); Including, the measures to mitigate the tampering are selected based on an analysis of information about data traffic that occurred on the in-vehicle network prior to the recognition of possible tampering, including means for preventing the recurrence of the tampering. method.

2. The method of claim 1 , wherein the analysis includes identifying a type of tampering.

3. The method of claim 1 , wherein the analysis includes discovering vulnerabilities in the in-vehicle network of the vehicle (20).

4. 3. The method according to claim 2, wherein the identification of the type of tampering comprises the identification of the interfaces (21; 22) of the vehicle (20) through which data traffic occurred before the recognition of the possibility of tampering.

5. The method of claim 1 , wherein the analysis includes discovering programming processes within the data traffic that occurred prior to recognition of possible tampering.

6. The method of claim 1 , wherein the analysis includes determining a temporal relationship between particular data traffic and the perception of possible tampering.

7. The means comprises: prohibiting or limiting certain types of data traffic within the vehicle (20); and Turning off or limiting certain components (21-27) of the vehicle (20) The method of claim 1 , comprising one or more of:

8. 8. The method according to claim 7, wherein the component is an interface (21; 22) of the in-vehicle network of the vehicle (20).

9. logging the results of the analysis of information about the data traffic of the in-vehicle network; providing the logged results for tamper detection; The method of claim 1 further comprising:

10. and deactivating said means in response to updating said in-vehicle network of said vehicle (20). The method of claim 1 further comprising:

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

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

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

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

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

Images