WO2021197822A1

WO2021197822A1 - Method for handling an anomaly in data, in particular in a motor vehicle

Info

Publication number: WO2021197822A1
Application number: PCT/EP2021/056539
Authority: WO
Inventors: Manuel Jauss; Roland Steffen; Mustafa Kartal
Original assignee: Robert Bosch Gmbh
Priority date: 2020-03-28
Filing date: 2021-03-15
Publication date: 2021-10-07
Also published as: JP2023519910A; DE102020204059A1; JP7467670B2; CN115398427A

Abstract

The invention relates to a method for handling an anomaly in data, in particular in a motor vehicle, wherein at least one sensor (24, 26, 28) for anomaly detection obtains data (211), wherein the sensor (24, 26, 28) examines the obtained data (211) for anomalies, generates an event (220, 221) if an anomaly is identified according to the associated data (211), and forwards said event to an event manager (30), wherein at least one trusted zone (Z2) and a non-trusted zone (Z1) are provided, wherein at least one sensor (24,26, 28; 40, 60) and the event manager (30) are associated with the trusted zone (Z2).

Description

description

Method of dealing with an anomaly in data, in particular in a

Motor vehicle

Technical area

The invention relates to a method for handling an anomaly in data, in particular in a motor vehicle.

State of the art

A device and a method for treating an anomaly in a communication network, in particular a motor vehicle, are already known from DE 102018209407 A1. At least one detector analyzes a data stream in the communication network, the at least one detector recognizing at least one anomaly by a rule-based anomaly detection method when at least one parameter for a data packet of the data stream deviates from a target value, the at least one detector providing information about at least one detected anomaly via the Communication network sends.

The automatic creation of a protocol, history or report (logging), in particular when anomalies or events are detected, should take place in the event of high event rates and / or long-lasting attacks without overload and rejection of corresponding services. The logging entries or corresponding event reports should be authentic, with integrity and available. If possible, a history of a complete (long-lasting) attack that is not deterministic for the attacker should be created. Manipulation and, in particular, deletion by an attacker should be avoided. Outside of a control unit, the logging entries should be protected against unauthorized analysis. The logger is designed to provide the event reports reliably for example, send via an interface to an external node. After a successful transmission to the external node, the event entries can be deleted locally, particularly preferably after an in particular authenticated confirmation by the receiving entity. The logger should also send a so-called heartbeat signal, which indicates a network connection. The collection of events should be possible in order to reduce the number of logging entries to be processed.

Under normal operating conditions, events are not or barely triggered, for example on the order of one event per hour. In the worst case, an attacker has full control over an interface, in particular an Ethernet interface. With a full bandwidth of 100 Mbit, for example, an attacker could send a maximum of 128,000 UDP (User Datagram Protocol, a network protocol) frames per second. Each such frame could possibly trigger an event (detected anomaly in a data stream). Such an attack is assumed to have a frequency of one attack over the life of a vehicle. The permitted number of so-called write cycles of a memory, in particular a flash memory, is limited and must be taken into account. The number of active operating hours is also limited. The availability of the higher-level external data logger is also limited. Therefore, the corresponding logging events or event reports must be cached. All logging entries or event reports should be able to be transferred to the higher-level data logger at least once a day.

For conventional IDS or IDPS systems (Intrusion Detection System, intrusion detection, a system for the automated detection of attacks on computer networks or computer interfaces; or IDPS: Intrusion Detection Prevention System, if an intrusion attempt is detected, the corresponding data is not forwarded and thus the intrusion attempt prevented), deterministic behavior and the limited resources of the embedded systems are often problematic. In contrast, it is desirable to specify an improved method for anomaly detection. This object is achieved by the features of the independent claim.

Disclosure of the invention

This is achieved by the method according to the independent claim.

Because at least one trustworthy zone and one untrustworthy zone are provided, with at least one sensor and the event manager being assigned to the trustworthy zone, the manipulation protection can be further increased with the aid of a 2-stage security concept. In particular, the arrangement of the sensor and / or event manager in the trustworthy zone as a trustworthy entity makes access to sensitive data and manipulation possibilities more difficult.

In an expedient development it is provided that at least one communication adapter is arranged in the same zone as the event manager, the communication adapter serving to communicate an event report at least partially created by the event manager. In this way, the communication adapter can check a data transfer to the other zone, while it can communicate with the event manager and / or sensor within the security-relevant zone.

In an expedient development it is provided that the communication adapter is also assigned to an untrustworthy zone. This part is used to communicate with the higher-level IDS instance, which are generally untrustworthy instances.

In an expedient development it is provided that the sensor in the trustworthy zone contains at least data, in particular defragmented data, from a sensor which is arranged in the untrustworthy zone, the sensor in the trustworthy zone checking the received data for anomalies and at If an anomaly is present, an event is generated and / or the sensor in the untrustworthy zone receives the Checks data for anomalies and generates an event if there is an anomaly. This means that only data that is absolutely necessary for further processing in the event manager gets into the trustworthy zone. The possibilities of manipulation are thereby further reduced.

In an expedient development it is provided that the event report is sent by the communication adapter in the trustworthy zone bringing the event report to a memory in the untrustworthy zone, which the communication adapter in the untrustworthy zone can access and send. In this way, a secure data transfer from one zone to the other can be ensured.

In an expedient development, it is provided that the event report includes at least one variable that changes for each event report and / or at least one piece of authentication information and / or is encrypted by encryption. This allows the higher-level instance to check whether the data is authentic. To this end, it is particularly expedient to provide that the authentication information is formed by further information contained in the event report.

In an expedient development it is provided that a security module assigned to the trustworthy zone provides a variable for each event report and / or authentication information and / or encryption. This enables a secure, authentic and confidential connection to be established with a higher-level entity.

In an expedient development, it is provided that after the event report has been sent, a confirmation signal is received which is received by the communication adapter of the untrustworthy zone and forwarded to the communication adapter of the trustworthy zone. The correct completion of a transmission of the event report can be checked via the confirmation signal and further measures such as emptying the memory can be initiated In an expedient development it is provided that the confirmation signal comprises at least one variable variable for each confirmation signal and / or at least certain data or patterns and / or at least one piece of authentication information and / or at least one constant length and / or is encrypted with an encryption . Due to the variable size, the confirmation signal always looks significantly different from the attacker, especially after encryption, and is therefore not interpretable. The additional variable signal ensures that it is up-to-date, since an elderly incident report cannot be used. The authentication information ensures that the confirmation signal comes from a real higher-level entity and was not generated by an attacker. This means that the local event report can be deleted in a trustworthy manner.

In an expedient development it is provided that the communication adapter of the trustworthy zone decrypts and / or authenticates the received confirmation signal using a security module arranged in the security-relevant zone. The further verification in the trusted zone further improves the security of the communication. To this end, it is particularly expedient to provide for the received confirmation signal to be decrypted and / or authenticated by checking whether the variable size of the event report sent is contained in the confirmation signal. Thus, no new variable variable has to be generated for the confirmation signal either, but the variable variable generated in particular by a security module in the trustworthy zone, which was sent as part of the event report, can also be used for the confirmation signal.

In an expedient development, it is provided that when data is transmitted from one zone to the other zone, the sensor checks the data before use, in particular whether an event has occurred and / or that, in the event that no event was detected, the Data are released for use in the other zone. This further reduces the possibilities for manipulation. For this purpose, it is particularly expedient that, when an event occurs, the data are not entered into the other zone can be transferred and / or the sensor forwards the event to the event manager.

In an expedient development it is provided that the event manager and / or the communication adapter of the trustworthy zone and / or the sensor of the trustworthy zone and / or the security module are implemented on a computer core. This means that all security-relevant functions can be implemented on one computer core, which further increases security.

In an expedient development, it is provided that at least one computing device is assigned certain executable application programs to one of the at least two zones, the zones characterizing resources of the computing device that can be used for executing a relevant application program, optionally executing at least one of the application programs as a function the zone assigned to it. The above-mentioned assignments between zones and functions can be used to ensure that only security-relevant functions are carried out in the trustworthy zone. This can preferably also be done in that the method steps have the following: exchanging first data between different zones via a buffer memory, in particular working memory, wherein in particular exchanging the first data between the first zone and the second zone has the following steps: d1) copying the first data into a first buffer memory area assigned to the first zone, d2) checking the copied first data, and, in particular depending on the check, d3) copying the first data from the first buffer memory area assigned to the first zone into a second buffer memory area assigned to the second zone. This ensures that secure data exchange between the zones is preferred.

Further advantageous configurations emerge from the following description and the drawing. In the drawing shows

In the drawing shows: Fig. 1 schematically components of an intrusion detection,

2 shows an exemplary structure or interaction of received data, the event derived therefrom, the structure of the associated selected event and an event report,

3 schematically shows a simplified block diagram of aspects according to a further preferred embodiment,

Fig. 4 schematically shows a simplified block diagram of aspects according to a further preferred embodiment;

Fig. 5-10 different communication processes between

Event manager, communication adapter, further IDS instance and backend.

In connection with aspects of the following statements, deviations from normal behavior, which for various reasons can occur in real operation in data 211 (for example data of a communication system or system data) of a networked system in particular, are referred to as anomalies. Causes for this can be, for example, the following types: Defective or completely failed sensors provide incorrect or no data at all, components of the system are damaged, the system has been manipulated by external as well as local or physical attacks (e.g. a hacker attack).

The detection of anomalies in data 211 is implemented by means of what is known as an intrusion detection system, IDS or IDPS. In the following, IDS denotes a system which monitors data 211 for anomalies. This can be, for example, data 211 in the data connection in a communication network via which the control device 20, such as a gateway, communicates on different communication channels (for example via bus systems such as 25 or Internet 27). However, other data 211, for example system data within a control device (or host 29 or microcontroller or processor arranged therein, or within a chip) should also be checked for anomalies by this IDS system. Anomalies in the data 211 are detected by suitable means Sensors 24, 26, 28. The sensors 24, 26, 28 are adapted to the respective source of the data 211 (in the exemplary embodiment bus systems 25, 27 or host 29).

According to FIG. 1, a control device such as a gateway 20 is arranged in a vehicle 18. The control device or the gateway 20 comprises processor (s), memory, main memory (for example as part of a host system 29) and interfaces for communication via a communication network. The gateway 20 processes, for example, instructions for the data connection. The communication produces data 211 in the form of data packets. Data 211, for example system data, also arise during the operation of the host 29. In a normal state, setpoint values are maintained, for example with regard to recipient and destination address, compliance with the correct program sequence (for example for host 29), time stamp, frequency of occurrence or frequency of data 211 of specific data packets. The data 211 of the data packets are exchanged between further control devices or components in the vehicle 18 (not shown in detail) in order to fulfill the specific tasks. The gateway 20 is used to couple several communication systems or interfaces such as a CAN bus 25, an Ethernet connection 27 and a data connection to the host system 29, which is part of the control device 20 or the gateway. However, other communication systems (for example further wired bus systems such as LIN, CAN-FD etc. or wireless networks (for example WLAN or Bluetooth) can be coupled to one another for the purpose of data exchange through the gateway 20. In general, an intrusion detection IDS or anomaly detection is used in one Control device to monitor all data 211 (data 211 received by communication system as well as data 211 generated within control device 20 by host 29) for corresponding anomalies The functionality of the anomaly detection or intrusion detection IDS described above can be implemented in any control device or any electronic components Communication modules in the Internet (IOT Internet of Things) or be equipped with the functions described in networked production systems.

A communication component such as the control device or the gateway 20 comprises at least one anomaly detection 22. The anomaly detection 22 extends over at least one untrustworthy zone Z1 and over at least one trustworthy zone Z2. In particular, a communication adapter 32 is located both in the trustworthy zone Z2 and in the untrustworthy zone Z1. At least one sensor 24, 26, 28 is located in the trustworthy zone Z2. The event manager 30 is also located in the trustworthy zone.

The data 211 incoming via the interfaces of the respective communication systems 25, 27, 29 are each conducted via so-called sensors 24, 26, 28 for anomaly detection or intruder detection, IDS sensors for short. Corresponding sensors 24, 26, 28 are arranged in gateway 20. Such sensors 24, 26, 28 serve to detect whether the data 211 received represents an anomaly. For this purpose, corresponding filter algorithms or rule sets are stored in the sensors 24, 26, 28, which serve to detect and classify anomalies. If an anomaly is detected by a sensor 24, 26, 28, the corresponding data packet of the data 211 is classified as an event 220 (an attempted intrusion). In general, the sensors 24, 26, 28, depending on the source 25, 27, 29, can classify and recognize different anomalies as events 220 (assignment of the respective event 220 to specific event types 218). Depending on the respective event type 218 (different types of anomalies in the data 211), the sensors 24, 26, 28 compile certain event-dependent metadata 216 as an associated event 220. In addition, the event-dependent metadata 216 can also contain data or data components of the anomalous data 211. The event 220 generated in this way is forwarded to an event manager 30. The sensors 24, 26, 28 are generally designed so that if there is no anomaly, the associated data 211 of a communication system (for example bus systems 25, 27) are forwarded to the destination address. If an anomaly is detected, the sensors 24, 26, 28 could be designed in such a way that the associated data 211 of a communication system (for example bus system 25, 27) cannot be forwarded to the destination address. Alternatively, the sensors 24, 26, 28 can also be used to reduce events 220 (reduced event or pre-reduced event 221). This reduction could reduce the load on the event manager 30, for example by only forwarding a small portion of useful data from data 211 or data packets containing anomalies. This is particularly advantageous with large amounts of data, such as those that occur with Ethernet connections.

For example, IDS CAN sensors 24 are used for anomaly detection in a CAN bus 25, IDS Ethernet sensors 26 in an Ethernet system 27 and IDS host sensors 28 in a host system 29. Depending on the different communication paths and communication protocols, further IDS sensors can also be provided that are able to detect anomalies in the respective sources or anomaly sources and, if necessary, to classify them.

The IDS CAN sensors 24 detect incidents 220 of associated event types 218, such as invalid CAN ^ID's, invalid messages frequencies, invalid message length or the like. The IDS Ethernet sensors 26 detect relevant events 220 of associated event types 218 for the Ethernet 27, such as invalid addresses or MAC addresses, invalid message frequencies, invalid message lengths or the like. The IDS host sensors 28 detect events 220 of associated event types 218 that are relevant for the host system 29, such as, for example, invalid code executions, corruption of programs, batch counters or the like. At least one sensor 24, 26, 28 is arranged in the trustworthy zone Z2.

Subsequent further anomalies can be taken into account as events 220 for further event types 218. For example, these are events 220 or event types 218 that can be assigned to the firewall, such as loss of the frame due to a full buffer memory, filter violation (stateless / stateful), limitation of the transmission rate active or inactive, monitoring mode activated or deactivated, context change. Further anomalies that affect the host system 29 can also be taken into account as events 220 with associated event types 218, for example CPU load too high, memory access violation, error in code execution, ECU reset detected, log entries in the non-volatile memory corrupted, overflow of the logging memory, rejection of an event, MAC address port change, etc.

The event manager 30 is used to further process the incoming events 220 or the event-dependent metadata 215 contained in the respective event 220 Events 220 and / or the storage or persistence or permanent storage of the selected and / or reduced events 220, 221. In particular, the event manager 30 decides which incoming events 220 are to be processed further. Those selected from the incoming events 220 are referred to as selected events 226. The corresponding selection should be made as non-deterministic as possible. Furthermore, the event manager 30 provides the incoming events 220 or the selected events 226 particularly preferably with further generic metadata 217. the associated time stamp or time signal 224 or the like can be added as part of the generic metadata 217. Furthermore, it is ensured that even in the event of a so-called event burst, a sufficient number of meaningful events 220 can be stored as selected events 226. The event manager 30 is arranged in the trustworthy zone Z2.

The event manager 30 exchanges signals with a communication adapter 32 for intrusion or anomaly detection. The communication adapter 32 functions as a communication means for data exchange between the event manager 30 and further components 34, 36 outside the anomaly detection 22 of the control device or gateway 20 of the vehicle 18) and / or a backend 36 (preferably outside of the Vehicle 18). The further IDS instance 34 can only be provided as an option. The communication adapter 32 is arranged in both zones Z1, Z2.

To increase security, the event manager 30 could undertake a random reduction and prioritization of events 220, 221 that is not determininistic and disguised for an attacker. For example, a non-volatile storage of selected events 226 could be carried out randomly, not deterministically for the attacker and in a disguised manner. The randomly controlled selection could, for example, be based on a random number 273 that is individual for a specific control device. The event manager 30 can also store the counter readings 231 of the event counters 204 on a random basis. The event manager 30 also stores the added generic metadata 217 as selected events 226 in a random manner in addition to the event-dependent metadata 216.

In order to increase security, the communication adapter 32 could undertake a random, non-deterministic and disguised uploading or sending of an event report 242 to other IDS instances 34 for an attacker. The randomly controlled upload could, for example, be based on a random number 273 that is individual for a specific control device (or gateway 20). For example, specific events 220 could be transmitted cyclically and in encrypted form within the scope of the event report 242. But even if there are no new events 220, so-called dummy events could be transmitted cyclically and encrypted in the format of an event report 242. This serves to protect against eavesdropping or to conceal the data exchange based on chance between the communication adapter 32 and further IDS entities 34 or the backend 36.

The processed reduced events 221 are forwarded from the sensor 26 to the event manager 30. The event manager 30 thus does not receive complete data streams of these net frames from this sensor 26, but only reduced events 221 with reduced data size. The reduction of the events 221 to be forwarded was described by way of example using an IDS Ethernet sensor 26. In principle, however, this could also be implemented in other IDS sensors 24, 26, 28. Due to the high information content in In an Ethernet frame with high transmission rates, however, such events 220 would quickly lead to an overflow of the buffer memory 206. In the case of IDS CAN sensors 24, corresponding data 211 occurs anyway at a lower data rate and a lower data volume, so that complete events 220 can tend to be passed on and stored here.

In connection with FIG. 2, it is shown by way of example how data 211 from the sensor 24, 26, 28 are further processed in the event of a detected anomaly and sent to the event manager 30 until the latter sends an event report 242 via the communication adapter 32.

As an example, a data packet of data 211 is shown in FIG. 2a as it could occur, for example, in a network frame (for example CAN, Ethernet). The data 211 has a header 214 which includes, for example, the source address and the destination address (for example MACa, MACb). In addition, the data 211 include useful data 213.

As will be explained in more detail below, the sensor 24, 26, 28 could optionally select a useful data area 219 at random, which is forwarded to the event manager 30. The sensor 24, 26, 28 has determined that it is an anomaly according to a certain type of event 218 (event ID or event ID,

ID). The sensor 24, 26, 28 therefore generates event-dependent metadata 216 as shown in FIG. 2b. Depending on the event type 218 (or ID), different information about the anomaly can be stored in the event-dependent metadata 216. In the exemplary embodiment, the source and destination address (MACa, MACb), the event type 218 and the selected useful data area 219, among other things, are used as event-dependent metadata 216.

Alternatively, the event-dependent useful data 213 could also be forwarded to the event manager 30 in full as part of the event 220.

Alternatively, the event 220 could also not include any event-dependent user data 213, for example if the host 29 is used as the source. This can be event types 218 such as information about the loss of the data frame due to a full buffer, activation or deactivation of the monitoring mode, load on the CPU is too high, entries of the non-volatile memory 208 are corrupted, overflow of the logging buffer, event reduction active etc. or the like.

Furthermore, further event-dependent information within the framework of the event-dependent metadata 216 can be part of the event 220 for different event types 218. In the event type 218 “change of context”, the event-dependent metadata 216 could, for example, include the context, for example in the size of 32 bits. In the event type 218 “memory access violation” or “violation when executing a code”, the event-dependent metadata 216 could include, for example, the accessed address (for example 32 bits), the program counter (for example 32 bits), the task ID (for example 8 bits). In the event type 218 “detected reset of a control device”, the event-dependent metadata 216 could include, for example, the reason for the reset (for example 8 bits), for example POR (point of return), software reset, exceptions, etc.

Subsequent Ethernet-related events 220 could be logged as event-dependent metadata 216, such as static / state-dependent filter violations (specific rule ID or ID for specific event type 218 (e.g. 16 bits), an ID of the filter rule that caused event 220 if available, physical port address, physical port ID via which the frame was received, source address (e.g. MAC address, e.g. 48 bit), destination address (e.g. MAC address, e.g. 48 bit), possibly IP address of the source or destination, Determination of the UDP / TCP port (e.g. 16 bit) if available in the frame, optional). Alternatively, static / state-dependent filter violations could also be logged, such as rule ID, physical port, frame (number of bytes), certain number of bytes of the received frame are stored, selected user data area 219 (certain number of bytes) selected user data area 219 of the bytes of the original Frames, user data area 219 - index (for example 16 bits), start byte of the selected user data area 219 in the original frame. Other Ethernet-related events could also be contained in the events 220 transmitted to the event manager 30, such as for the event type 218 "Transmission rate limited (active / inactive)" the rule ID with the associated ID of the filter rule that caused the event 220, for the Event type 218 “Change of context” the context (for example 32 bit), for event type 218 “Address hopping” or “MAC hopping” the old port (physical port ID that was originally assigned to the address), the new port (physical port ID where the address was recently observed), the address, preferably MAC address. However, event types 218 without metadata 216 can also occur, such as "loss of frame due to full buffer" etc.

The forwarding of event-dependent useful data 213 thus depends in particular on the source of the data 211 with the associated event type 218. The metadata 216 is transmitted to the event manager 30 as an event 220 or reduced event 221 (due to the random selection or reduction of the useful data area 219 to be transmitted in the sensor 24, 26, 28).

If the event manager 30 selects this event 220, 221 for further processing (selected event 226) as explained in more detail below, generic metadata 217 are added to the event-dependent metadata 216 so that the metadata 215 shown in FIG. 2c arise. These generic metadata 217 are usually generated in the event manager 30. These are, for example, output signals from event counters 204, that is to say current counter readings 231, how many global event 220 or how many event of a specific event type 218 the current event 220 is. In addition, the generic metadata 217 can include, for example, a time signal 224 indicating when this event 220 occurred. In addition, the metadata 217 could include the length 232 (size of the data) the event-dependent metadata 216 or the complete metadata 215 have. This is advantageous for the later memory management of the buffer memory 206.

The following generic metadata 217 is proposed as an example. This could, for example, be an event type 218 in the context of an event ID (for example 8 bits). This event ID of event type 218 is unique and can, for example, comprise a TLV-based coding (TLV: Type-Length-Value type-length-value). The generic metadata 217 include the length 232, for example between 8 and 16 bits in size. The size of the data (metadata 215) follows the length field in bytes, up to a maximum of 255 bytes. Again, TLV-based coding could be provided. Also included is the time signal 224, a time stamp (for example 64 bits). The time 224 is given, for example, in the form of an absolute time value that has elapsed since a reference point in time such as January 1, 1970 (in milliseconds) for the purpose of specifying a unique time stamp. Furthermore, the generic metadata 217 counter readings 231 or output values 231 of the event type counter 204 (for example 32 bits) and / or the counter reading 231 of the global (event) counter 204 (for example 32 bits), a sum of all counter readings 231 of the event counters 204 for each event type 218.

The event-dependent metadata 216 are adopted as they were formed by the respective sensor 24, 26, 28. This event 220 with the corresponding metadata 215 formed both by the sensor 24, 26, 28 and by the event manager 30 is stored in the buffer memory 206 of the event manager 30. In a similar manner, further events 226 selected or reduced by the event manager 30 (designated as 215_1, 215_8, 215_190 in the exemplary embodiment according to FIG.

From selected events 226 stored in the buffer memory 206 (in the exemplary embodiment according to FIG 226) an event report 242 is now generated. This includes the selected events 226 stored in the buffer memory 206 (in the example 215_ 1, 215_8,

215_190). These selected events 226 are preceded by a variable 254 that is different from each event report 242 (for example random number, time or counter, etc.). The event report 242 also includes authentication information 256. The authentication between communication adapter 32 or event manager 30 and the unit receiving the event report 242 (IDS instance 34, backend 36 or the like) can also take place. The event report 242 has a fixed length 258. To achieve this fixed length 258, the data 254, 215_ 1, 215_8,

215_190, 256 still filled with so-called filler data 255. These filler data 255 do not contain any event-relevant information. Before transmission, the shown data of the event report 242 is encrypted 258 as indicated in FIG. 2d. The event report 242 encrypted in this way by the encryption 258 is sent by the communication adapter 32 and decrypted and authenticated by the further IDS entity 34 or backend 36 as described.

3 schematically shows a computing core 102a of a switch SWT 48 according to further preferred embodiments, which comprises an operating system BS and / or supervisor SV and which is itself assigned to two zones Z1, Z2.

The anomaly detection 22 is based on a 2-zone concept in which certain applications are assigned to an untrustworthy zone Z1 and a trustworthy zone Z2. The anomaly detection 22 can in particular be used, for example, for an embedded system and / or a control device, in particular for a vehicle, in particular a motor vehicle.

Preferred embodiments relate to a method for operating a computing device assigned to anomaly detection 22, which has the following steps: Assignment of one or more application programs AP1, AP2 that can be executed by the computing device to one of at least two zones Z1, Z2, with zones Z1, Z2 Characterize resources of the computing device that can be used for executing a relevant application program AP1, AP2, optionally executing at least one of the application programs AP1, AP2 depending on the zone Z1, Z2 assigned to it, the method further alternatively comprising: using a supervisor SV for assigning of computing time resources for different application programs and / or instances of application programs, the supervisor SV and / or a functionality corresponding to the supervisor SV being implemented at least in part by means of a supervisor instance SVI which is controlled by the at least two zones Z1, Z2 is independent. In further preferred embodiments, for example, trust boundaries can thereby be defined, for example between trustworthy and untrustworthy entities / units / domains. In this way, for example, first application programs for the computing device of an untrustworthy first zone Z1 (English: non-trustworthy zone, NT) and second application programs for the computing device of a trustworthy second zone Z2 (English: trustworthy zone, (T) Z) are assigned. In further preferred embodiments, the supervisor instance SVI can be formed, for example, by a (dedicated) computing core and / or a hardware security module HSM and / or a trusted platform module TPM, or the functionality of the supervisor instance SVI can be implemented using at least one of these elements can be realized.

In further preferred embodiments it is provided that the method for operating the computing device further comprises: controlling, in particular limiting, of at least one of the following elements: a) reading rights on the memory assigned to the computing device, b) writing rights on the memory assigned to the computing device, c) execution rights ("Execution rights") on the memory allocated to the computing device, depending on at least one zone Z1, Z2. This advantageously ensures that only those application programs AP that are assigned to a corresponding zone Z1, Z2 receive access to the memory or memories mentioned. For example, in further preferred embodiments it can be prevented that an application program of an untrustworthy zone Z1 accesses the memory (s) (in particular, for example, access to the memory area assigned to the trustworthy zone Z2 by the untrustworthy zone Z1) Represents a risk of possible manipulation of the memory contents by the application program of the untrustworthy zone Z1.

In further preferred embodiments, the computing device can, for example, execute the following scenario: If a first application program AP1 is to receive data from a, for example, untrustworthy first zone Z1 - for example remote service requests from the Internet - and process or forward this data accordingly within the trustworthy zone Z2 - for example, to execute the corresponding service ("remote service") - the data is received within the first zone Z1 by the Z1 proxy AP1J1 of the application program AP1, with the corresponding Z2-Proxy_l2 carries out the following steps, for example: a data verification of the data classified as untrustworthy by the Z2-Proxy_l2, in particular by default, and - in the case of successful data- Verification - the processing or forwarding of the data now classified as trustworthy (after data verification) within the second zone Z2. In further preferred embodiments it is provided that the method further comprises: exchanging first data between different zones via a buffer memory, in particular working memory, wherein in particular exchanging the first data between the first zone Z1 and the second zone Z2 comprises the following steps: copying the first data into a first buffer memory area assigned to the first zone, checking the copied first data and, in particular depending on the check, copying the first data from the first buffer memory area assigned to the first zone Z1 into a second buffer memory area assigned to the second zone Z2. These briefly outlined functionalities of the 2-zone concept are now implemented for the anomaly detection 22 as described below.

The computing core 102a according to FIG. 3 can be used, for example, for a network switch, for example to send and / or receive Ethernet data packets. Corresponding instances of application programs AP are identified by the reference symbols 11 (receiving Ethernet packets, execution in zone Z1), I2 (receiving Ethernet packets, execution in zone Z2), I3 (sending Ethernet packets, execution in zone Z1), I4 ( Sending Ethernet packets, execution in zone Z2) marked. Another application program AP5, which, for example, carries out management tasks for the network switch 48, runs only in the second zone Z2 defined as trustworthy, but not in the first zone Z1 defined as untrustworthy. Furthermore, Ethernet sensors 38 are arranged in the first zone Z1, which is defined as untrustworthy. Further Ethernet sensors 40 are arranged in the second zone Z2 defined as trustworthy. In addition, host sensors 42 are arranged in the first zone Z1 defined as untrustworthy. The host sensors 43 of the untrustworthy zone Z1 can optionally be provided. Host sensors 45 are arranged in the second zone Z2 defined as trustworthy. Depending on the application, the sensors can therefore be arranged in the trustworthy and / or untrustworthy zone Z1, Z2. A RAM 1030, which in further preferred embodiments can be divided up, is assigned to the computing core 102a. Optionally, a switching engine (eg coupling network) is provided and / or a TCAM (ternary content-addressable memory) module or an ACL (access control list) module. The switching engine SE or the TCAM / ACL module are hardware modules 42. Corresponding filter rules can be configured in the TCAM / ACL module so that the TCAM / ACL module is used as a sensor in order to detect anomalies . The correspondingly configured filter rules in this hardware module 42 correspond to those of the sensors 24, 26, 28 described. If this filter rule detects an anomaly, an event 220 can be generated and / or the anomaly can be blocked. If an event 220 is generated, an interrupt can be triggered by the hardware module 42 so that the anomaly can be logged as an event 220 on the software side. The same applies to CAN hardware transceivers on a main controller, where filter rules for the sensors can be configured in hardware.

Furthermore, an interrupt 44 is indicated, which can be triggered, for example, in terms of software, in terms of hardware, as described, or by a timer. The components mentioned are part of the electronics unit 48 or the switch. Outside the electronics unit 48 or switch, a computing unit 100b (main controller) is provided, which exchanges data with the electronics unit 48 or switch via a communication channel 52. Furthermore, the processing unit 100b is able to communicate with other IDS entities 34. The communication could take place from the processing unit 100 b to other IDS entities 34, for example via CAN or from the computing unit 100 b via the switch 48 to other IDS entities 34. The electronics unit 48 in turn sends Ethernet events 220 from the switch SWT 48 to the Computing unit 100 b.

The inter-zone communication from the untrustworthy zone Z1 to the trustworthy zone Z2 is via the ETH sensors 40 of the trustworthy zone Z2 and / or via the sensors 42 implemented by hardware filter rules and / or by ETH sensors 40 of the untrustworthy ones Zone Z1 and / or the host sensors 45 of the trusted zone Z2 controlled. If the inter-zone communication or the zone transition from Z1 to Z2 takes place on the switch 48, only the necessary minimum of data that is required in the trustworthy zone Z2 is transmitted between the two zones Z1 and Z2.

For this reason, the log is defragmented to the necessary minimum in the untrustworthy zone Z1; plausibility checks are also carried out during the defragmentation (to detect anomalies). This is done via the Z1 Ethernet sensors 38.

After the necessary minimum of data has been transmitted from the untrustworthy zone Z1 to the trustworthy zone Z2, the necessary minimum of data is checked for plausibility by the Z2 Ethernet sensors 40. Before every context change / switching of the Z1 and Z2 task, the host sensors 43, 45 of the BS or SV also check whether there is no invalid zone transition and / or change in the program sequence (e.g. by checking the Return address on the stack) has taken place.

In the event that no anomalies were detected, the ETH sensor 40 enables the trustworthy zone Z2 to use the data in the trustworthy zone Z2. The data are classified as trustworthy data. In the event that anomalies have been detected, the ETH sensor 40 discards the data and / or generates an event 220. In addition, the ETH sensor 40 communicates the anomalies or the associated event 220 to the computing unit 100b of the trustworthy zone Z2 or to the associated event manager 30 of the trusted zone Z2. The sensor logic of the ETH sensor 40 is in the trustworthy zone Z2, since the events must be evaluated by a trustworthy entity.

Communications within zones Z1, Z2 or from the trustworthy zone Z2 to the untrustworthy zone Z1 can take place with the optional use of ETH sensors 38 for the untrustworthy zone Z1. Furthermore, the sensors are optional for inter-zone communication from Z2 to Z1 and intra-zone communication; a reduced sensor set can also be used for this if necessary (e.g. default sensors with little implication on performance). The switch 48 SWT forwards the communication of the processing unit 100b of the untrustworthy zone Z1 via the communication adapter 32 to the further IDS entities 34. The communication adapter 32 is located in the processing unit 100b. It cyclically requests the event report 242 from the event manager 30 and communicates it to the other IDS entities 34. If the communication takes place via Ethernet to the other IDS entities 34 (which is the preferred variant), then this would be from the communication adapter 32 of the main microcontroller or computing unit 100b to the further IDS entities 34 via switch 48.

FIG. 4 schematically shows a simplified block diagram of aspects of a computing device 100b in accordance with further preferred embodiments. In the present case, the computing device 100b has, by way of example, four computing cores K1, K2, K3, K4, of which the first computing core K1 is designed to process communication messages, in particular CAN messages. Therefore, in further preferred embodiments, the first computing core K1 can also be referred to as a “CAN core”. The further computing cores K2, K3 are provided for executing (possibly different instances of) application programs and in further preferred embodiments can therefore also be referred to as “application cores” K2, K3. The fourth computation core K4 is designed to process Ethernet communication messages and can therefore, in further preferred embodiments, also be referred to as the Ethernet core or ETH core or, in English, “ETH core” K4. A first supervisor SV1, in particular a CAN lightweight supervisor, is assigned to the first computing core K1, and a second supervisor SV2, in particular an ETH (Ethernet) lightweight supervisor, is assigned to the fourth computing core K4.

In further preferred embodiments, the first computing core K1 is assigned to two zones Z1, Z2. In further preferred embodiments, the fourth computing core K4 is also assigned to two zones Z1, Z2.

In further preferred embodiments, the first computing core K1 is an application program AP for sending and / or receiving CAN Messages assigned, the reference numeral 11 denoting a first instance of this application program, which first instance 11 is assigned to the first zone Z1 and is designed to receive CAN messages. In contrast, the reference symbol I2 denotes a second instance of this application program which is assigned to the second zone Z2 and is designed to receive CAN messages. The reference symbols I3, I4 denote corresponding entities for sending CAN messages, which are each also assigned to one of the two zones Z1, Z2. Furthermore, the computing core K1 can include CAN sensors 60 which are arranged in the trustworthy zone Z2. Optionally, CAN sensors 62 can also be provided in the untrustworthy zone Z1 in the computing core K1.

In further preferred embodiments, the interrupt requests Rx, timer, SW can be processed by the first computing core K1, for example by executing a corresponding interrupt routine.

In further preferred embodiments, the fourth computing core K4 is assigned an application program for sending and / or receiving Ethernet messages, the reference numeral 11 denoting a first instance of this application program, which first instance 11 is assigned to the first zone Z1 and for receiving Ethernet messages is trained. In contrast, the reference symbol I2 denotes a second instance of this application program which is assigned to the second zone Z2 and is designed to receive Ethernet messages. The reference symbols I3, I4 denote corresponding entities for sending Ethernet messages, which are each also assigned to one of the two zones Z1, Z2.

In further preferred embodiments, the two zones Z1, Z2 are separated within the computing cores K1, K4 using at least one memory protection device SSE1, SSE4.

As already mentioned above, the two application cores K2, K3 are designed to execute application programs, which or their individual instances are indicated as rectangles within the relevant application cores K2, K3. In further preferred embodiments, the second computing core K2 is assigned to the second zone Z2, and the third computing core K3 is assigned to the first zone Z1. In the computing core K2, for example, DPI sensors 64 (deep package inspection for a more detailed payload analysis), event manager 30, communication adapter 32, proxies 70, BSW stack 72 (BSW: basic software), V-CAN 74 (virtual CAN) and V -ETH 76 (virtual Ethernet) provided. In the computing core K3, DPI sensors 84, communication adapters 32, proxies 90, BSW stack 92, V-CAN 94 and V-ETH 96 are provided by way of example. As already described, the communication adapter 32 is located both in the trusted zone Z2 and in the untrusted zone Z1.

In further preferred embodiments, the computing device 100b has a volatile memory, in particular a main memory (RAM) 1030b, which, for example, is divided into different areas in a manner comparable to the illustration according to FIG. whose zones Z1, Z2 are assigned.

For example, a first area B1 of the main memory 1030b of the computing device 100b according to FIG. 13 is assigned to the first computing core K1, a first subarea B1_1 being assigned to the first zone Z1 and a second subarea B1_2 to the second zone Z2. The first sub-area B1_1 is in turn divided into a trustworthy area and an untrustworthy area, separated by a memory protection device SSE. The second sub-area B 1_2 is in turn subdivided into at least one trustworthy area and one untrustworthy area, again separated by a memory protection device SSE. A comparable division into corresponding areas or sub-areas B4, B4_1, B4_2 is also possible for the fourth computation kernel K4 in further preferred embodiments. The first sub-area B4_1 is in turn divided into a trustworthy area Tb1b and an untrustworthy area Tb1a, separated by a memory protection device SSE. The second sub-area B4_2 is in turn divided into at least one trustworthy area Tb2a and one untrustworthy area Tb2b, again separated by a memory protection device SSE.

In further preferred embodiments, further areas B2, B3 of the main memory 1030b are, for example, the application cores K2, K3 assignable. In further preferred embodiments, for example, the area B2 can be further divided into a trustworthy area T and a non-trustworthy area NT. In further preferred embodiments, the same can also apply to the third application core K3.

In further preferred embodiments, one or more further memory protection devices, which are collectively designated with the reference symbol SSE ', can be provided in order to implement a respective separation according to preferred embodiments with regard to, for example, read rights and / or write rights and / or execution rights.

In further preferred embodiments, the computing device 100b can, for example, provide the functionality of a gateway, i.e. a network coupling element that can, for example, couple a CAN bus (cf. CAN Core K1) to an Ethernet network (cf. ETH Core K4) . In further preferred embodiments, for example, the first computing core K1 can assume the function of a so-called high-speed routing engine for CAN messages, and / or the fourth computing core K4 the function of a so-called high-speed engine for Ethernet messages.

The switch SWT 48, in particular an Ethernet switch, transmits Ethernet events to the computing core K4, which is responsible for handling the Ethernet communication. In addition, the computing core K4 communicates with other IDS entities 32.

In the case of communication between the zones, namely from the untrusted zone Z1 to the trusted zone Z2, the data can be shifted from the proxy 90 of the untrusted zone Z1 to an isolated buffer memory in the untrusted area of the zone Z1. The sensor 60 assigned to the trustworthy zone Z2 validates this data before use in the trustworthy zone Z2. If no anomalies are detected, the sensor 60 enables the trustworthy zone Z2 to use this data for the trustworthy zone Z2 (trusted data). If anomalies or unexpected events are detected, the sensor 60, which is assigned to the trustworthy zone Z2, discards the data. In addition, the sensor 60 communicates, the Trusted zone Z2 is assigned, the detected anomalies as event 220 to the event manager of the trustworthy zone Z2. The logic of the sensor 60 is arranged in the trustworthy zone Z2 because the corresponding events must be evaluated by a trustworthy entity. Furthermore, communication can take place between trustworthy zone Z2 and untrustworthy zone Z1. In addition, communication from the trustworthy zone Z2 to the untrustworthy zone Z1 can easily take place. Further sensors 62 can optionally be provided.

Communication from the untrustworthy zone Z1 to the trustworthy zone Z2 can - as already stated - also be monitored by sensors in the untrustworthy zone Z1 and the trustworthy zone Z2. Data that are no longer available after the defragmentation or are not required in the trustworthy zone Z2 are monitored by sensors 38, 62 arranged in the untrustworthy zone Z1. The sensors 40, 60 arranged in the trustworthy zone Z2 then monitor the data which is transmitted after the defragmentation (the necessary minimum of data) from the untrustworthy zone Z1 into the trustworthy zone Z2. If something is already detected by the sensors 38, 62 in the untrustworthy zone Z1, communication between the sensors 38, 62 arranged in the untrustworthy zone Z1 and the event manager 30 arranged in the trustworthy zone Z2, for example events 220 generated in the frame, must also be possible be.

The event manager 30 of the trustworthy zone Z2 aggregates, reduces or prioritizes, formats or persists incoming events 220. The event manager 66 is arranged in the trustworthy zone Z2, since the events must be processed, prioritized and stored by a trustworthy instance.

The communication adapter 32 is partly arranged in the trustworthy zone Z2. The communication adapter 32 controls the communication with the event manager 30, which is also arranged in the trustworthy zone Z2. In addition, the communication adapter 32 takes over the communication to an HSM (Hardware Security Module, which the Authentication and / or encryption) to ensure a secure, authenticated and confidential channel to the higher-level IDS instance 34. The communication adapter 32 is partly arranged in the trustworthy zone Z2 because it also has to communicate with trustworthy entities such as, for example, the event manager 30 of the trustworthy zone Z2 or the HSM.

The communication adapter 32 is intended to take over the communication to other IDS entities 34 such as, for example, infotainment via the switch SWT 48. Since it communicates with untrustworthy entities (infotainment, CCU), it is partially arranged in the untrustworthy zone Z1.

As an example, a communication sequence is decided in which the event report 242 is sent cyclically to the higher-level entity 34. For this purpose, the communication adapter 32 from the trustworthy zone Z2 asks the event manager 30 in the trustworthy zone Z2 to provide selected events 226 in the buffer memory 206 as described by way of example in connection with FIG. The event report 242 contains certain particularly trustworthy information with regard to encryption and / or authentication, in particular the variable variable 254 and / or the authentication information 256 and / or the encryption 258. These variables can be provided by the security module 73, which has already been described above as HSM (Hardware Security Module). The security module 73, for example accommodated in the so-called BSW stack 72, supplies, for example, a corresponding random number 273 or a section of such a random number as a variable variable 254 Event report 242. The event report 242 arrives in plain text again at the security module 73, which carries out the encryption by the key 258 and makes it available to the communication adapter 32 of the trustworthy zone Z2. The event report 242 encrypted in this way now reaches the no longer trustworthy area Z1, that is to say to the core K3, via the communication adapter 32. Accordingly, the event report 242 is put into the buffer written in zone B3. As an example, the event report 242 could, as already stated, be communicated to the higher-level entity 32 via the Ethernet core K4, as indicated by the corresponding arrow. For this purpose, the event report 242 is transferred from the memory in the area B3 to the memory area B4_1, so it is now in the Ethernet core K4. The further communication takes place from K4 via the transmission process I3, for example via the Ethernet switch 48 etc. to the higher-level entity 32 connected via Ethernet.

The following communication sequence describes the receipt of a confirmation signal 408, 416 that was generated by the higher-level entity 34 (as described in more detail below in connection with FIGS. 5-10). The corresponding confirmation signal 408, 416 arrives via the Ethernet switch 48 to the Ethernet core K4 and there into the untrustworthy zone Z1. Via that part of the communication adapter 32 located in the untrustworthy area Z1, the data are first buffered in the area B3, there in the untrustworthy area NT. The communication adapter 32 of the trustworthy zone Z2 has access to the data isolated there. The communication adapter 32 of the trusted zone Z2 recognizes that the data is encrypted. The decryption now takes place in that the communication adapter 32 of the trustworthy zone Z2 sends the data for decryption to the security module 73 or assigns the corresponding security module 73 access to the data.

The signal decrypted by the security module 73 then arrives back in plain text at the communication adapter 32 of the trustworthy zone Z2. The communication adapter 32 then recognizes that further security-relevant information such as the variable variable 254 'and / or authentication information 256' are part of the confirmation signal 408, 416 (see FIG. 5). In a particularly preferred variant, the variable variable 254 'of the confirmation signal 408, 416 was formed by the higher-level entity 34 in such a way that the variable variable 254 as transmitted by the last event report 242 (and also generated by the security module 73) as variable variable 254' for the confirmation signal 408, 416 was used. The security module 73 thus carries out a corresponding check as to whether the variable variable 254 'of the confirmation signal 408, 416 corresponds to the variable size 254, in particular of the last event report 242. If this is the case, corresponding release information for the confirmation signal 408, 416 can be generated. In this context, the communication adapter 32 of the trustworthy zone Z2 sends, for example, a signal 410 to the event manager 30 to delete the events 226 in the buffer memory 206 transmitted as part of the last event report 242. Furthermore, the corresponding authentication information 256 ′ could additionally also be used for a verification or authentication of the received confirmation signal 408, 416 as described.

In the following, the communication processes between event manager 30 and communication adapter 32 within control device or gateway 20, as well as between communication adapter 32 and at least one other IDS instance 34 within vehicle 18 and between additional IDS instance 34 and backend 36 are exemplified on the basis of FIGS. 5-10 described.

The communication from the control device such as the gateway 20 to further IDS instance (s) 34 (for example a central event logger within the vehicle 18) should ensure that the further IDS instance 34 or the event logger have unread entries or events 236 or selected events 226 stored in memory 206 are informed. The control device or the gateway 20 should send an event report 242 on a regular basis to the further IDS instance 34, preferably via a so-called heartbeat signal (cyclical signal which can be used to check a proper connection between the communication participants). The heartbeat signal (including the event report 242) should be encrypted and authentic. The transmitted information should preferably be exchanged authentically (possibly using the authentication information 256) and encrypted, preferably randomly or using a random number 273 between the control device or gateway 20 and the further IDS entity 34. Preferably, the event report 242 should be of a fixed length 257, should be encrypted and authenticated. Each encrypted event report 242 should be different from the previous event reports 242, even if the transmitted status has not changed. The communication from the further IDS instance 34 to the control device or gateway 20 or the associated communication adapter 32 should also be characterized by the following functionalities. The data logger or the IDS instance 34 should record the events 236 or associated event reports 242 as quickly as possible in order to prevent the memory or buffer memory 206 in particular from overflowing. The event reports 242 should be able to be read out via a diagnostic interface, for example on request. Alternatively, the event report 242 could be sent completely cyclically. The event reports 242 should be communicated or read out on a regular basis, preferably authentically and encrypted or camouflaged, even if no new selected events 226 are available in the context of a new event report 242.

The control device or gateway 20 should respond to a read request 240 with a response or an event report 242 with a fixed length, encrypted and authenticated. Each encrypted response or event report 242 is intended to differ from the previous responses or event reports 242, even if the content has not changed. This is done, for example, by the constantly changing size 254, as already described.

According to FIG. 5, the event manager 30 arranged in the trustworthy zone Z2 first selects a first selected event 226.1 and then a second selected event 226.2. These are processed by the event manager 30 as described. The selected events 226.1, 226.2 are therefore stored in the memory 206. The part of the communication adapter 32 located in the trustworthy zone Z2 contains a signal 400, a time-dependent interrupt signal (timer IRQ). The time-dependent signal 400 is preferably formed cyclically, so that the transmission of an event report 242 from the communication adapter 32 to further IDS entities 34 in the vehicle 18 is thereby initiated cyclically. However, even if there are no new events 226.1, 226.2, a signal (in the form of a “normal” event report 242) is sent from the communication adapter 32 to the further IDS instance 34 as described below (compare signal 406). However, it is particularly preferred that the transmission of an event report 242 is not triggered as a function of the receipt of an event 220 or selected event 226, but rather cyclically (by the lapse of the cycle time). This is particularly advantageous, since the transmission to further IDS instances 34 and / or the backend 36 is always carried out cyclically, that is, after a certain time has elapsed. The behavior of the event manager 30 or anomaly detection is thus opaque to an attacker. The attacker never knows whether his attack was detected, what was detected and how the anomaly detection system works.

After the communication adapter 32 has received the signal 400 (timer interrupt), the part of the communication adapter 32 located in the trustworthy zone Z2 requests an event report 242 from the event manager 30, signal 402 selected events 226.1 and / or 226.2 (with respective generic metadata 217 and event-dependent metadata 216) and a changed size 254. Corresponding filler data 255 are also added so that the fixed length 257 of the event report 242 is reached (with knowledge of the length of the authentication information 256 still to be created). Furthermore, for example, the event manager 30 generates authentication information 256 from the changed information 254, the selected events 226.1, 226.2 and the filler data 255 using a specific algorithm. The authentication information 256 formed in this way completes the event report 242. The complete event report 242 is then encrypted with the key 258. The encrypted event report 242 reaches the part of the communication adapter 32 located in the trustworthy zone Z2 as a signal 404 the changed information 254 and / or the key 258) and authentication (formation of the authentication information 256) could be in the event manager 30 and / or in the communication adapter 32 or using the security module 73 (also arranged in the trustworthy zone Z2) as already described take place when the corresponding safety requirements are met.

Alternatively, the communication adapter 32 and / or the security module 73 could encrypt the event report 242, for example as a function of a random number 273. Particularly preferably, a new random number 273 is always formed for encryption, for example by hashing. This makes it difficult Furthermore, the decryption of a transmitted message or the encrypted event report 242. If necessary, the communication adapter 33 takes over the authentication using the authentication information 256 and / or the addition of the variable variable 254 and / or the final encryption of the entire event report 242 with the encryption 258.

A corresponding signal 406 is sent to the timer interrupt (signal 400) even if no new event report 242 is made available by the event manager 30 due to the occurrence of new selected events 226. Then a dummy message with the data format of an event report 242 is used and encrypted by a random number or the constantly changing size 254 (using the key 258) is transmitted to the further IDS entity 34. Dummy messages are also always encrypted by constantly changing sizes 254 or new random numbers, so that even if new selected events 226 do not occur, other or encrypted messages (signal 406) are always transmitted cyclically. As a result of the cyclical transmission, the functioning of a proper communication connection between the communication adapter 32 and the further IDS entity 34 can be checked. As already described, the event report 242 is sent via that part of the communication adapter 32 arranged in the untrustworthy zone Z1.

After the message sent by the communication adapter 32 (signal 406) has been received by the further IDS entity 34, the further IDS entity 34 sends a confirmation signal (408) to the communication adapter 32, in particular to that part of the communication adapter 32 located in the untrustworthy zone Z1 The further procedure has already been explained in more detail in connection with FIG. After receipt of the confirmation signal 408, the part of the communication adapter 32 arranged in the trustworthy zone Z2 generates a request to the event manager 30 to delete or overwrite the temporarily stored, possibly reduced, selected events 226 or associated event reports 242 (signal 410). In an alternative embodiment, the superordinate entity 34 and / or the backend 36 checks the authenticity of the received encrypted event report 242. For this purpose, the superordinate entity 34 and / or the backend 36 decrypts the received message, namely the encrypted event report 242, using the known key 258. Event report 242 is then available in plain text. The event report 242 is authenticated using the corresponding algorithm (which was also used by the event manager 30 or communication adapter 32 to create the authentication information 256) to form the authentication information 256. For this purpose, all the data of the received and decrypted event report 242 (with the exception of the authentication information 256) are used again and a corresponding authentication information 256 'is formed therefrom. The authentication information 256 'formed is then compared with the authentication information 256 received in the context of the event report 242. If there is a match, the received event report 246 is considered authentic. Only after authentication has taken place can further data communication with the instance of the higher or lower level take place in this variant. In this embodiment, the signal 408 (confirmation signal) is only sent to the communication adapter 32 when the authentication is successful, which then sends the signal 410 to the event manager 30 to enable the overwriting of the selected events 226.1, 226.2.

The response or the confirmation signal 408, 416 should preferably also have a fixed length 257 ‘. The confirmation signal 408 should preferably be authenticated and encrypted. Each response or confirmation signal 408 by the higher-level entity 34 and / or the backend 36 should differ, even if the content has not changed.

An example of such a confirmation signal 408, 416 is shown in FIG. The confirmation signal 408, 416 has a similar structure to the event report 242. The confirmation signal 408, 416 comprises a variable variable 254 '. The variable variable 254 'changes for each newly sent confirmation signal 408, 416. The variable variable 254' could again, for example, can be realized by a random number, a counter, a time.

The variable variable 254 of the confirmation signal 408, 416 could particularly preferably be formed in that the variable variable 254 of the event report 242 is transmitted as just above and, if necessary, generated by the security module 73, is used. For this purpose, the higher-level entity 34, 36 is set up to extract the variable variable 254 from the received event report 242 and to insert it into the confirmation signal 408, 416. Authentication of the confirmation signal 408, 416 could thus also take place in a subsequent step by comparing the received variable variable 254 ‘of the confirmation signal 408, 416 with the variable variable 254 of the previously sent event report 242. If there is a match, an authentic confirmation signal 406, 408 is inferred. In addition, the variable variable 254 ‘does not have to be generated in the higher-level instance 34, 36 itself. This can be followed by the release of the memory 206.

The confirmation signal 408, 416 also includes certain data 255, for example in the form of any pattern. The confirmation signal 408, 416 also includes authentication information 256 ‘. The authentication information 256 ‘could be formed similarly to the event report 242 again via a specific algorithm that accesses the remaining data of the confirmation signal 408, 416, namely the variable variable 254‘ and the data 255 ‘. The authentication information 256 formed in this way completes the confirmation signal 408, 416. It has a fixed length 257 ‘. Encryption then takes place using a key 258 ‘. This encryption 258 ‘could optionally also be dispensed with.

The receiving entities (for example the higher-level entity 34, the backend 36) and / or the communication adapter 32 or the event manager 30 are in turn able to decrypt the confirmation signal 408, 412 (using the key 258 ') and to authenticate it. For this purpose, the received data (variable size 254 ', data 255') is again derived from this using a correspondingly known algorithm resulting authentication information 256 'is determined and compared with the received authentication information 256'. If they match, authenticity is assumed. If the received authentication information 256 ′ is correct, the signal 410 for enabling the memory 206 could be generated. If the authentication information 256 'is not in order, this signal 410 could not be generated, so that the selected events 226 contained in the memory 206 are not (yet) deleted.

The further IDS instance 34 also receives a timer interrupt signal 412 cyclically, which is formed similarly to the signal 400 as already described. In response to this interrupt signal 412, the further IDS instance 34 in turn sends an encrypted message, signal 414. This message may contain the event report 242 or a vehicle-related event report (including further event reports) as transmitted via signal 406 in front of the communication adapter 32. As with the communication adapter 32, the message is encrypted by the further IDS instance 34, in particular by a constantly changing variable 254 'such as a random number 273. If the communication adapter 32 has not transmitted an event report 242, because, for example, no new selected event 226 occurred, In turn, a dummy message with the same data format as an event report 242 is used and transmitted in encrypted form to the backend 36 (signal 414). The backend 36 sends a confirmation signal 416 and / or a further message or request to overwrite the events 236 or the like temporarily stored in the buffer memory 206 to the further IDS entity 34. The confirmation signal 416 can be formed as described above.

After receiving the signal 410 relating to the event release, the event manager 30 selects further selected events 226.3 and 226.4. The further process can be seen in FIG. 6. In the meantime, the event manager 30 also selected a further event 226.5. Again, a timer interrupt (signal 420) arrives at the communication adapter 32. This now requests an event report 242 for the gateway 20 (signal 422). The event manager 30 sends to the communication adapter 32 an event report 242 which is based on the selected events 226.3, 226.4, 226.5, signal 424. After Receipt of the event report 242, the communication adapter 32 sends the event report 242 encrypted and authenticated by a new variable 254 such as a random number to the further IDS entity 34, signal 426. The receipt is confirmed by the further IDS entity 34 with a confirmation signal 428. The actuation signal 428 can be formed as described in connection with actuation signal 408 (Figure 5). After receiving the confirmation signal 428, the communication adapter 32 again sends a request to the event manager 30 to overwrite or delete the selected events 226.3, 226.4, 226.5 on which the event report 242 is based, signal 430. Between the transmission of the signal 424 and the reception of the signal 430, a further selected event 226.6 is selected in the meantime. However, this selected event 226.6 must not yet be overwritten, since this selected event 226.6 was not yet the basis for an event report 242 already transmitted to the communication adapter 32. In this respect, the signal 430 does not relate to overwriting the selected event 226.6, but rather merely overwriting those selected events 226.3, 226.4, 226.5 that were already transmitted in the context of the last event report 242.

Again, a timer interrupt also occurs in the further IDS instance 34 (signal 432), as already described. This causes the further IDS entity 34 to transmit the event report 242 newly received in signal 426 in encrypted form to the backend 36, signal 434. The receipt of the corresponding message 434 is acknowledged by the backend 36 with a corresponding confirmation signal 436, which is sent to the further IDS entity 34 is sent. The confirmation signal 436 could be formed like the confirmation signal 408 or 416.

The further sequence is shown in FIG. Another timer interrupt occurs for the communication adapter 32, signal 440. The communication adapter 32 then sends a request from the trusted zone Z2 to the event manager 30 to send an event report 242, signal 442. The event manager 30 sends an event report 242 that contains the Intermediate selected event 226.6 includes, signal 444. The communication adapter 32 encrypts the event report 242 using a new variable variable 256, possibly using the security module 73, and sends the encrypted event report 242 via the part of the communication adapter 32 located in the untrustworthy zone Z1 to the further IDS entity 34, signal 446. Upon receipt, the further IDS entity 34 sends a confirmation, signal 448, upon receipt of which the communication adapter 32 sends a request to the event manager 30 to overwrite or release the events 226.6 already transmitted, 450.

The further IDS instance 34 again receives a timer interrupt, signal 452. The encrypted event report 242 is then transmitted to the backend 36 in a vehicle-related manner together with further event reports from further IDS systems. The backend 36 sends a confirmation signal and / or a request to release or overwrite etc., signal 456, to the further IDS instance (s) 34.

In the exemplary sequence according to FIG. 8, no new selected event 226 has occurred between the sending of the last event report 242 and the new occurrence of a timer interrupt (signal 460). After receiving the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 for a new event report 242 to the event manager 30 from the trustworthy zone Z2. The event manager 30 generates - although a new selected event 226 has occurred - an event report 242 with a dummy content , which is then sent to the communication adapter 32, signal 464. This dummy content can be recognized as such by the further IDS instances 34 and / or by the backend 36. The communication adapter 32 encrypts in the trustworthy zone Z2, possibly using the security module 73, the received event report 242, which has a dummy content, with a new changed size 254, sends and sends the encrypted and authenticated event report 242 to the further IDS instance 34, signal 466. the sending takes place again from the untrustworthy zone Z1. The receipt is confirmed by the further IDS instance 34, signal 468. When this is received, the communication adapter 32 again sends a request signal to the event manager 30 to overwrite the last selected events 226, signal 470. This takes place itself when there are no new selected events 226 as in this constellation.

The further IDS instance 34 again receives a timer interrupt, signal 472. The further IDS instance 34 then encrypts the most recently received encrypted event report 242 as transmitted by the communication adapter 32 and sends it, if necessary, with further event reports from further IDS systems to the backend 36 in relation to the vehicle The backend 36 sends a confirmation signal 476 and / or a request to release the underlying events etc. to the further IDS entity 34.

In the communication sequence of FIG. 9, communication adapter 32 again receives a timer interrupt, signal 480. This timer interrupt 480 can be a special signal so that communication adapter 32 requests an event summary from event manager 30 (and not one of the usual event reports 242), signal 482. The event manager 30 sends the event summary to the communication adapter 32, signal 484. This takes place again in the trustworthy zone Z2. The event summary can contain higher-level information such as the various counter readings 231 for the various event types 218, or the occurrence of a new event type etc. Security module 73, encrypted in the security-relevant zone Z2 and transmitted to further IDS instances 34, signal 486. The transmission takes place again from the non-security-relevant zone Z1. As soon as the IDS instance 34 has received the encrypted event summary from the communication adapter 32, the further IDS instance 34 sends the event summary on to the backend 36, particularly preferably in encrypted form. In the exemplary embodiment, no timer interrupt for initiating the communication process is provided for the transmission process between the further IDS instance 34 and the backend 36. Alternatively, however, this could in turn be initiated cyclically as well as the transmission of a customary event report. In the communication sequence of FIG. 10, the backend 36 sends a request for an event report to the further IDS instance 34, signal 490. The further IDS instance 34 sends an encrypted request for an event report, for example via a diagnostic interface, to the communication adapter 32, signal 492. The encryption can again take place via the variable variable 254 ', such as a random number, for example, which changes in particular for each encryption. After receiving the request 492, the communication adapter 32 in the security-relevant zone Z2 sends a request for an event report 242 to the event manager 30, signal 494. After receiving the corresponding request 494, the event manager 30 sends the event report 242 to the communication adapter 32, signal 496 Communication adapter 32 encrypts the event report 242, for example using a new variable 254 such as a random number, possibly using the security module 73, and sends it from the non-security-relevant zone Z1 to the further IDS instance 34, signal 498. After receiving the encrypted event report 242 sends the further IDS instance 34 the event report 242 to the backend 36. The receipt acknowledges the 36 backend to the further IDS instance 34, signal 492. The receipt of the acknowledgment signal 492 confirms the further IDS instance 34 the communication adapter 32, signal 494. After receiving the appropriate Signal 494, the communication adapter 32 sends a corresponding request to the event manager 30 to release or overwrite at least the events 220 transmitted in the context of the last event report 242.

The described methods can be implemented in a processing unit, computer or controller, in particular in a control unit of a vehicle 18. The method can likewise be created in the context of a computer program that is set up to carry out the method when it is carried out on a computer. Furthermore, the computer program can be stored on a machine-readable storage medium. At the same time, the program can be uploaded as software "over-the-air" wirelessly or via diagnostic interfaces using cables.

Claims

Expectations

1. A method for treating an anomaly in data, in particular in a motor vehicle, with at least one sensor (24, 26, 28) receiving data (211) for anomaly detection, the sensor (24, 26, 28) receiving the data (211 ) examined for anomalies and, if an anomaly is detected, an event (220, 221) is generated as a function of the associated data (211) and forwards to an event manager (30), characterized in that at least one trustworthy zone (Z2) and one untrustworthy zone (Z1) are provided, at least one sensor (24, 26, 28; 40, 60) and / or the event manager (30) being assigned to the trustworthy zone (Z2).

2. The method according to claim 1, characterized in that at least one communication adapter (32) is arranged in the same zone (Z2) as the event manager (30), the communication adapter (32) of the communication being at least partially created by the event manager (30) Event report (242) is used.

3. The method according to any one of the preceding claims, characterized in that the communication adapter (32) is also assigned to an untrustworthy zone (Z1).

4. The method according to any one of the preceding claims, characterized in that the sensor (24, 26, 28) in the trustworthy zone (Z2) contains at least data (211), in particular defragmented data, from a sensor (38, 62) which is arranged in the untrustworthy zone (Z1), the sensor (24, 26, 28) in the trustworthy zone (Z2) checking the received data (211) for anomalies and, if an anomaly is present, generating an event (220) and / or wherein the sensor (38,62) in the untrustworthy zone (Z1) receives the data (211) checks for anomalies and, if an anomaly is present, generates an event (220).

5. The method according to any one of the preceding claims, characterized in that the event report (242) is sent by the communication adapter (32) in the trustworthy zone (Z2) storing the event report (242) in a memory in the untrustworthy zone (Z1) that the communication adapter (32) in the untrustworthy zone (Z1) can access and send.

6. The method according to any one of the preceding claims, characterized in that the event report (242) comprises at least one variable (254) that changes for each event report (242) and / or at least one piece of authentication information (256) and / or by means of encryption (258) is encrypted.

7. The method according to any one of the preceding claims, characterized in that a security module (73) assigned to the trustworthy zone (Z2) has a variable (254) for each event report (242) and / or authentication information (256) and / or provides encryption (258).

8. The method according to any one of the preceding claims, characterized in that after the event report (242) has been sent, a confirmation signal (408, 416) is received, which is received by the communication adapter (32) of the untrustworthy zone (Z1) and sent to the communication adapter (32) the trusted zone (Z2) is forwarded.

9. The method according to any one of the preceding claims, characterized in that the confirmation signal (408, 416) has at least one variable (254 ') and / or at least certain data or patterns (255') and / or at least one variable for each confirmation signal (408, 416) Authentication information (256 ') and / or at least a constant length (257') and / or is encrypted with an encryption (258 ').

10. The method according to any one of the preceding claims, characterized in that the communication adapter (32) of the trustworthy zone (Z2) decrypts and / or authenticates the received confirmation signal (408, 416) using a security module (73) arranged in the security-relevant zone (Z2) .

11. The method according to any one of the preceding claims, characterized in that the received confirmation signal (408, 416) is decrypted and / or authenticated by checking whether the variable size (256) of the event report (242) sent is contained in the confirmation signal (408, 416) is.

12. The method according to any one of the preceding claims, characterized in that when data is transmitted from one zone (Z1) to the other zone (Z2), the sensor (24, 26, 28) checks the data before use, in particular whether a Event (220) has occurred and / or that, in the event that no event (220) has been detected, the data are released for use in the other zone (Z2).

13. The method according to any one of the preceding claims, characterized in that when an event (220) occurs, the data are not transferred to the other zone (Z2) and / or the sensor (24, 26, 28) detects the event (220) forwards to the event manager (30).

14. The method according to any one of the preceding claims, characterized in that the event manager (30) and / or the communication adapter (32) of the trustworthy zone (Z2) and / or the sensor (24,26,28) of the trustworthy zone (Z2) and / or the security module (73) are implemented on a computer core (K2).

15. The method according to any one of the preceding claims, characterized in that at least one computing device (100a; 100b) certain executable application programs (AP) are assigned to one of the at least two zones (Z1, Z2), the zones (Z1, Z2) Characterize resources of the computing device (100b; 100b) which can be used for executing a relevant application program (AP), optionally executing at least one of the Application programs (AP) depending on the zone (Z1, Z2) assigned to it.

16. The method according to at least one of the preceding claims, further comprising:

Exchanging first data between different zones (Z1, Z2) via a buffer memory, in particular working memory, in particular exchanging the first data between the first zone (Z1) and the second zone (Z2) having the following steps: d1) copying the first data into a first buffer memory area assigned to the first zone (Z1), d2) checking the copied first data and, in particular depending on the check, d3) copying the first data from the first buffer memory area assigned to the first zone (Z1) into one of the second zones (Z2) assigned second buffer storage area.

17. Device for carrying out the method according to at least one of the preceding claims.