Method for processing data anomalies, in particular in a motor vehicle

Abstract

A method for processing data anomalies, in particular in a motor vehicle, is proposed, in which at least one sensor (24, 26, 28) for identifying anomalies acquires data (211), wherein the sensor (24, 26, 28) checks the acquired data (211) for anomalies, generates an event (220, 221) from the associated data (211) in the event of an identified anomaly, wherein it is decided whether the event (220, 221) is further processed, in particular stored and / or at least partially further transmitted.

Description

Technical Field

[0001] This invention relates to a method for handling data anomalies, particularly in motor vehicles. Background Technology

[0002] DE 102018209407 A1 discloses an apparatus and method for handling anomalies in communication networks, particularly communication networks of motor vehicles. At least one detector analyzes a data stream in the communication network, wherein if at least one parameter of a data packet in the data stream deviates from a nominal value, the at least one detector identifies at least one anomaly using a rule-based anomaly identification method, wherein the at least one detector transmits information about the at least one identified anomaly via the communication network.

[0003] In particular, the automatic creation of protocols, historical records, or reports (logging) upon identifying anomalies or events should be performed in cases of high event occurrence and / or prolonged attacks without overloading or denying the corresponding service. Log entries or corresponding event reports should be true, complete, and available. If possible, a non-deterministic historical record of a complete (long-duration) attack should be created for attackers. Manipulation by attackers, and especially deletion, should be avoided. Log entries should be protected from unauthorized analysis outside of the control device. The logger should reliably transmit event reports, for example, via an interface to an external node. After successful transmission to the external node, event entries can be deleted locally, particularly preferably after the receiving instance has performed, in particular, authenticated confirmation. Furthermore, the logger should send a so-called heartbeat signal indicating network connectivity. Event accumulation should be feasible to reduce the number of log entries to be processed.

[0004] Under normal operating conditions, events are rarely or never triggered, for example, on the order of one event per hour. In the worst case, an attacker could gain complete control of the interface, especially the Ethernet interface. At, for example, a full bandwidth of 100 Mbit, an attacker could send up to 128,000 UDP (User Datagram Protocol) frames per second. Each such frame could potentially trigger an event (identifying an anomaly in the data stream). This assumes such an attack occurs at a frequency of one attack per vehicle's lifespan. The permissible number of write cycles for memory, especially flash memory, is limited and must be considered. Similarly, the number of effective operating hours is limited. Likewise, the availability of the external data logger is limited. Therefore, corresponding log entries or event reports must be cached. All log entries or event reports should be able to be transmitted to the external data logger at least once per day.

[0005] For traditional IDS or IDPS (Intrusion Detection System, a system used to automatically identify attacks on computer networks or computer interfaces; or IDPS: Intrusion Detection Prevention System, which prevents intrusion attempts by not forwarding corresponding data when they are detected) embedded systems, the deterministic behavior and limited resources are often problematic.

[0006] Instead, the aim is to describe an improved method for identifying anomalies. This task is addressed through the features of the independent claims. Summary of the Invention

[0007] This is achieved by means of the method described in accordance with the features of the independent claim.

[0008] The method involves determining whether to process an event further, specifically storing and / or at least partially transmitting it, so that different events can be recorded with different priorities. This allows higher-priority events to be stored more frequently than lower-priority events.

[0009] A suitable extension specifies that further processing of an event is determined randomly and / or based on the number of occurrences of a particular event type. This provides an attacker with a non-deterministic selection of events, thereby reducing the number of events. This simplifies further processing of the selected events.

[0010] A suitable extension specifies that when an event of a particular event type occurs for the first time, that event is further processed. Thus, each event type always selects an event with associated metadata. This allows for a general understanding of the anomaly that has occurred.

[0011] A suitable extension specifies that for events with an event type that has already appeared in previous events, a random determination is made as to whether the event should be further processed. This allows the attacker to select events in a non-deterministic manner, but always reliably selects the first occurrence of the event beforehand.

[0012] A suitable extension specifies the number of associated events for each event type. This generates useful additional information that is helpful for subsequent evaluation. Furthermore, the event types can be correlated with each other.

[0013] A suitable extension specifies that different priority groups are assigned to specific event types, where events in higher priority groups are further processed with a higher probability than events in lower priority groups, and in particular, further processed randomly. It is precisely by combining these into different priority groups that events can be simplified in terms of their importance. However, by randomly selecting events within a priority group, the attacker still cannot understand or definitively comprehend the behavior.

[0014] In a suitable extension, specific offsets or ranges are assigned to different priority groups. From each offset or range, at least one event from the corresponding priority group is selected for further processing, wherein the offset or range of a higher priority group is smaller than that of a lower priority group. This allows for the random selection of an average number of events based on priority within each offset. Consequently, more events are randomly selected for higher priority groups, while fewer events are randomly selected for lower priority groups.

[0015] A suitable extension specifies that, from multiple events with the same event type and / or priority group, it is randomly determined which event should be further processed. Events from different sources can be processed with the same priority. This simplifies priority handling.

[0016] A suitable extension specifies the use of random numbers and / or ranges of random numbers, particularly vehicle-specific and / or control device-specific random numbers, for random decision-making. This ensures a reduction in nondeterministic anomalies. Even if the random numbers are public in one vehicle, the knowledge gained cannot be transferred to other vehicles. By using different random numbers in a convoy, different events are selected for each vehicle. In the event of a convoy attack, this increases data diversity and enables a broader assessment or complete reconstruction of the attack.

[0017] In a suitable extension, events awaiting further processing are specified to be stored at least partially in memory, particularly in volatile or buffered memory and / or non-volatile memory (208) and / or transmitted within the scope of event reporting and / or equipped with additional information, particularly general metadata, such as the number of events occurring, time signals, the number of events not further processed, and their lengths. This generates useful additional information that is helpful for subsequent evaluation. It is precisely by archiving the length of each event that the buffer fill level can be inferred without having to read the fill level separately.

[0018] A suitable extended specification involves setting up multiple sensors for anomaly detection, each acquiring data from a different data source, particularly a communication system and / or a host or microcontroller. Each sensor checks its acquired data for anomalies, generates an event based on associated data upon anomaly detection, and forwards the event to an event manager. It is precisely in the context of different data sources that the event manager ensures a higher-level perspective when appropriately selecting events to be selected. Attached Figure Description

[0019] Other advantageous designs are derived from the other dependent claims, as well as the following description and drawings. In the drawings...

[0020] Figure 1 A schematic diagram of the components for anomaly detection is shown.

[0021] Figure 2 Exemplary structures or interactions of received data, exemplary structures or interactions of events derived from said data, structures of associated selected events, and event reporting are shown.

[0022] Figure 3 This shows a more accurate structure of the event manager.

[0023] Figure 4 A flowchart is shown for selecting events to be processed further.

[0024] Figure 5 The flowchart of the counter increment is shown.

[0025] Figure 6 A flowchart illustrating the storage process in non-volatile memory is shown.

[0026] Figure 7 A schematic diagram illustrating the random selection of events to be stored is shown.

[0027] Figure 8 It shows Figure 7 The assignment of specific variables used,

[0028] Figures 9-14 The different communication flows between the event manager, communication adapter, additional IDS instances, and the backend are illustrated. Detailed Implementation

[0029] In conjunction with the aspects described below, deviations from normal behavior will be referred to as anomalies, which may occur in actual operation, particularly in the data 211 of networked systems (e.g., data from communication systems or system data), due to various reasons. The causes of this may include, for example, the following types: defective or completely malfunctioning sensors providing incorrect data or not providing data at all; damage to system components; and manipulation of the system by external, local, or physical attacks (e.g., hacking).

[0030] Anomalies in data 211 are identified using a so-called Intrusion Detection System (IDS) or Intrusion Detection System (IDPS). Hereinafter, IDS stands for a system that monitors for anomalies in data 211. This data may be, for example, data 211 during data connections in a communication network, such as when a gateway control device 20 communicates via the network on different communication channels (e.g., via a bus system such as 25 or the Internet 27). However, other data 211, such as system data within a control device (or a host 29, microcontroller, processor, or chip located within the control device), should also be checked for anomalies by the IDS system. Anomalies in data 211 are detected by suitable sensors 24, 26, and 28. Sensors 24, 26, and 28 are adapted to the corresponding source of data 211 (in embodiments, bus systems 25, 27, or host 29).

[0031] according to Figure 1Control devices, such as gateway 20, are arranged in vehicle 18. The control device or gateway 20 includes processor(s), memory, working memory (e.g., as part of host system 29), and interfaces for communication via a communication network. Gateway 20, for example, processes instructions for data connections. This communication generates data 211 in the form of data packets. Data 211, such as system data, is also generated during operation of host system 29. Under normal conditions, data 211 adheres to, for example, recipient and destination addresses, conformity to correct procedure flow (e.g., for host system 29), timestamps, and the frequency or frequency rating of occurrence of specific data packets. Data 211 of data packets is exchanged between other control devices or components in vehicle 18 (not shown in detail) to accomplish specific tasks. Gateway 20 is used to couple multiple communication systems or interfaces, such as CAN bus 25, Ethernet connection 27, and data connections, to host system 29, which is part of control device 20 or gateway. However, other communication systems (such as additional wired bus systems like LIN, CAN-FD, etc.) or wireless networks (such as WLAN or Bluetooth) can be coupled to each other through gateway 20 for data exchange. Typically, intrusion detection systems (IDS) or anomaly detection are used in control devices to monitor all data 211 (data 211 received through the communication system and data 211 generated by host 29 within control device 20) for corresponding anomalies. In this embodiment, the IDS functional mechanism is described exemplary for gateway 20. However, typically, the described anomaly detection or intrusion detection IDS functionality can be implemented in any control device or any electronic component. In particular, this use is not limited to vehicle 18. Instead, any communication component, such as a communication module in the Internet (Internet of Things) or a networked production system, can be equipped with the described functionality.

[0032] Communication components, such as control devices or gateway 20, include at least one anomaly detection 22. Data 211 input via the interfaces of the respective communication systems 25, 27, 29 is directed via sensors 24, 26, 28 (hereinafter referred to as IDS sensors) for identifying anomalies or intrusions. Corresponding sensors 24, 26, 28 are thus deployed in gateway 20. These sensors 24, 26, 28 are used to identify whether the acquired data 211 indicates an anomaly. For this purpose, corresponding filtering algorithms or rule sets are stored in sensors 24, 26, 28 for detecting and classifying anomalies. If sensors 24, 26, 28 determine an anomaly, the corresponding data packet of data 211 is classified as event 220 (attempted intrusion). Typically, based on the source 25, 27, 29, sensors 24, 26, 28 can classify different anomalies as events 220 (assigning the corresponding events 220 to specific event types 218) and identify these anomalies. Based on the corresponding event type 218 (different anomaly types in data 211), sensors 24, 26, and 28 summarize specific event-related metadata 216 into associated events 220. Furthermore, the event-related metadata 216 may also contain data or data components of the anomalous data 211. Events 220 generated in this manner are forwarded to event manager 30. Sensors 24, 26, and 28 are typically designed to forward associated data 211 of the communication system (e.g., bus systems 25, 27) to a designated address when no anomaly is detected. In the event of an anomaly, sensors 24, 26, and 28 may be designed not to forward associated data 211 of the communication system (e.g., bus systems 25, 27) to the designated address. Alternatively, sensors 24, 26, and 28 may also be used to reduce events 220 (reduced events or pre-reduced events 221). This reduction can alleviate the burden on event manager 30 by, for example, forwarding only a small portion of the useful data containing the anomalous data 211 or a data packet. This is particularly advantageous in cases of large amounts of data, such as in Ethernet connections.

[0033] Thus, for example, IDS CAN sensor 24 is used to identify anomalies in the case of CAN bus 25, IDS Ethernet sensor 26 is used to identify anomalies in the case of Ethernet system 27, and IDS host sensor 28 is used to identify anomalies in the case of host system 29. Depending on different communication paths and protocols, additional IDS sensors can be configured, capable of detecting anomalies or sources of anomalies from corresponding sources and classifying them when necessary.

[0034] The IDS CAN sensor 24 detects related events 220 of associated event type 218, such as invalid CAN-ID, invalid message frequency, invalid message length, etc. The IDS Ethernet sensor 26 detects related events 220 of associated event type 218 for Ethernet 27, such as invalid address or MAC address, invalid message frequency, invalid message length, etc. The IDS host sensor 28 detects related events 220 of associated event type 218 for the host system 29, such as invalid code execution, program corruption, stack counter, etc. Each event type 218 typically has an event-specific event ID. For different data sources with associated unique event IDs, there are numerous predefined event types 218.

[0035] The following additional anomalies can be considered as event 220 for other event type 218. For example, these are events 220 or event type 218 that can be assigned to a firewall, such as frame loss due to a full buffer, filter violation (stateless / stateful), transmission rate limiting being active or inactive, monitoring mode being active or deactivated, and context transition. Other anomalies involving host system 29 can also be considered as event 220 with associated event type 218, such as high CPU load, memory access violation, error during code execution, detection of ECU reset, corrupted log entries in non-volatile memory, log record memory overflow, event rejection, MAC address port change, etc.

[0036] Event Manager 30 is used to further process the input events 220 or event-related metadata 215 contained in the corresponding events 220. Specifically, Event Manager 30 is used to aggregate, format, or prepare events 220 and / or prioritize events 220 and / or reduce / select and / or store or retain or permanently store selected and / or reduced events 220, 221. In particular, Event Manager 30 determines which input events 220 should be further processed. The event selected from the input events 220 is referred to as the selected event 226. The corresponding selection should be made as non-deterministically as possible. Furthermore, Event Manager 30 particularly preferably sets additional general metadata 217 for the input events 220 or the selected events 226. This allows for higher-level observation of events 220 transmitted by different sensors 24, 26, 28 by, for example, adding the number of events occurring, associated timestamps, or time signals 224, etc., within the scope of the general metadata 217. In addition, ensure that even in the event of a so-called sudden event, a sufficient number of persuasive events 220 can be stored as the selected events 226.

[0037] The event manager 30 exchanges signals with the communication adapter 32 for intrusion detection or anomaly detection. The communication adapter 32 serves as a communication device for exchanging data between the event manager 30 and other components 34, 36 besides the anomaly detection 22 of the control device or gateway 20. Specifically, the communication adapter 32 serves as an interface for exchanging data between the event manager 30 and another IDS instance 34 (preferably within the vehicle 18) and / or the backend 36 (preferably outside the vehicle 18). The other IDS instance 34 may be optionally configured.

[0038] To enhance security, Event Manager 30 can randomly, non-deterministically, and covertly reduce and prioritize events 220 and 221. This allows for random, non-deterministic, and covert non-volatile storage of the selected event 226. The selection of random control can be based, for example, on a separate random number 273 for a specific control device. Similarly, Event Manager 30 can also randomly store the counter reading 231 of event counter 204. In addition to event-related metadata 216, Event Manager 30 also randomly stores additional general metadata 217 as the selected event 226.

[0039] To enhance security, communication adapter 32 can randomly, non-deterministically, and covertly upload or send event reports 242 to other IDS instances 34. Randomly controlled uploads can be based, for example, on a separate random number 273 from a specific control device (or gateway 20). This allows specific events 220 to be transmitted periodically and encrypted within the scope of event reports 242. However, even without new events 220, so-called virtual events can be transmitted periodically and encrypted in the format of event reports 242. This is used to prevent eavesdropping or random concealment of data exchange between communication adapter 32 and other IDS instances 34 or backends 36.

[0040] Combination Figure 2 An example is shown of how, in the event of an anomaly being detected, data 211 is further processed by sensors 24, 26, 28 and sent to event manager 30 until the event manager sends event report 242 via communication adapter 32.

[0041] exist Figure 2 Example a illustrates a data packet of data 211, which may appear, for example, in a network frame (e.g., CAN, Ethernet). Data 211 has a header 214 including, for example, a source address and a destination address (e.g., MACa, MACb). Furthermore, data 211 includes useful data 213.

[0042] As described in more detail below, sensors 24, 26, and 28 can optionally randomly select useful data areas 219 to forward to event manager 30. Sensors 24, 26, and 28 have determined that this is an anomaly based on a specific event type 218 (event ID, ID). Therefore, sensors 24, 26, and 28 generate data such as... Figure 2 The event-related metadata 216 is shown in b. Different information about the anomaly can be stored in the event-related metadata 216 based on the event type 218 (or ID). In this embodiment, the event-related metadata 216 specifically uses the source and destination addresses (MACa, MACb), the event type 218, and a selected useful data area 219.

[0043] Alternatively, the useful data 213 related to the event can be forwarded to the event manager 30 in its entirety within the scope of event 220.

[0044] Alternatively, event 220 may not include event-related useful data 213, such as when host 29 is used as the source. This could be event type 218, such as information about a data frame being lost due to a full buffer, activation or deactivation of watch mode, excessive CPU load, corrupted entries in non-volatile memory 208, log buffer overflow, event reduction being effective, and so on.

[0045] Furthermore, for different event types 218, additional event-related information within the scope of event-related metadata 216 may be part of event 220. In the case of event type 218 "Context Change," event-related metadata 216 may include, for example, a context, such as a 32-bit context. In the case of event type 218 "Memory Access Violation" or "Code Execution Violation," event-related metadata 216 may include, for example, an access address (e.g., 32 bits), a program counter (e.g., 32 bits), and a task ID (e.g., 8 bits). In the case of event type 218 "Control Device Reset Detected," event-related metadata 216 may include, for example, the reason for the reset (e.g., 8 bits), such as POR (Return Point), software reset, exception, etc.

[0046] The Ethernet-related event 220 below can be recorded as event-related metadata 216, such as static / state-related filter violations (specific rule ID or ID of specific event type 218, e.g., 16 bits), the ID of the filter rule that caused event 220 (if available), the physical port address, the physical port ID through which the frame was obtained, the source address (e.g., MAC address, e.g., 48 bits), the destination address (e.g., MAC address, e.g., 48 bits), the possible IP address of the source or destination, and the specification of the UDP / TCP port (e.g., 16 bits, optional if present in the frame). Alternatively, static / state-related filter violations can also be recorded together, such as the rule ID, physical port, frame (number of bytes), the specific number of bytes stored in the received frame, the selected useful data region 219 (specific number of bytes), the selected useful data region 219 in the original frame, the useful data region 219 index (e.g., 16 bits), and the starting byte of the selected useful data region 219 in the original frame. Other Ethernet-related events can also be included in event 220 transmitted to event manager 30. For example, for event type 218 "Transmission rate limited (valid / invalid)", it is the rule ID with the associated ID of the filter rule that caused event 220; for event type 218 "Change context", it is the context (e.g., 32-bit); and for event type 218 "Address hop" or "MAC hop", it is the old port (the physical port ID originally assigned to the address), the new port (the physical port ID of the recently observed address), and the address (preferably the MAC address). However, event type 218 without metadata 216 may also occur, such as "Frame loss due to buffer full", etc.

[0047] Therefore, the forwarding of event-related useful data 213 depends in particular on the source of data 211 with associated event type 218. Metadata 216 is transmitted to event manager 30 as event 220 or reduced event 221 (due to the random selection or reduction of useful data area 219 to be transmitted in sensors 24, 26, 28).

[0048] If Event Manager 30 selects event 220 or 221 for further processing (selected event 226), as explained in more detail below, then general metadata 217 is also added to event-related metadata 216, thereby generating... Figure 2Metadata 215 is shown in c. General metadata 217 is typically generated in event manager 30. This is, for example, the output signal of event counter 204, i.e., the current counter reading 231, indicating how many global events 220 or how many events 220 currently have a specific event type 218. Furthermore, general metadata 217 may include, for example, a time signal 224 regarding when the event 220 occurred. Additionally, metadata 217 may include the length 232 (data size) of event-related metadata 216 or complete metadata 215. This is advantageous for subsequent memory management of buffer memory 206.

[0049] The following general metadata 217 is presented as an example. This could be, for example, an event type 218 within the range of event IDs (e.g., 8 bits). This event ID of event type 218 is unique and may include, for example, TLV-based encoding (TLV: Type-Length-Value). General metadata 217 includes a 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. TLV-based encoding can also be set. A time signal 224, i.e., a timestamp (e.g., 64 bits), is also included. For example, the time 224 is described as an absolute time value (in milliseconds) elapsed since a reference time such as January 1, 1970, to describe a unique timestamp. In addition, general metadata 217 may include counter readings 231 or output values ​​231 (e.g., 32-bit) of event type counter 204 and / or counter readings 231 (e.g., 32-bit) of global (event) counter 204, and the sum of all counter readings 231 of event counter 204 for each event type 218.

[0050] Event-related metadata 216 is managed in the form of metadata formed by the corresponding sensors 24, 26, and 28. The event 220, having corresponding metadata 215 formed by both sensors 24, 26, and 28 and the event manager 30, is stored in the buffer memory 206 of the event manager 30. Similarly, additional events 226 (based on...) are selected or reduced by the event manager 30. Figure 2 In the embodiment of d, exemplarily represented as 215_1, 215_8, 215_190, the data are stored in buffer storage 206, as will be explained in more detail below.

[0051] The selected event 226 (in accordance with) stored in buffer memory 206 Figure 2In the embodiment of d, exemplarily represented as 215_1, 215_8, 215_190 (metadata 215 event number 1, metadata 215 event number 8, metadata 215 event number 190 as examples of selected events 226), an event report 242 is now generated. This event report includes the selected events 226 (215_1, 215_8, 215_190 in this example) stored in buffer memory 206. These selected events 226 are previously variables 254 (e.g., random numbers, time, or counters) that have changed relative to each event report 242. Furthermore, the event report 242 also includes authentication information 256. This authentication information allows authentication between the communication adapter 32 or event manager 30 and the unit receiving the event report 242 (IDS instance 34, backend 36, etc.). The event report 242 includes a fixed length 258. To achieve this fixed length of 258, data 254, 215_1, 215_8, 215_190, and 256 are still padded with so-called padding data 255. This padding data 255 does not contain event-related information. For example... Figure 2 As shown in d, the data shown in event report 242 is encrypted with encryption 258 before transmission. Event report 242, encrypted in this way with encryption 258, is sent by communication adapter 32 and decrypted and authenticated by another IDS instance 34 or backend 36, as described.

[0052] IDS sensors 24, 26, and 28 forward event 220 or reduced event 221 to event manager 30. It is precisely in an Ethernet network, under attack intent, that when there are a large number of events 220 to be forwarded with large amounts of data or event-related metadata 216, memory 206, especially volatile memory or buffer memory 206, may quickly become unable to hold all events 220. This is due to the high data transmission rate or the large amount of data that can be transmitted. Therefore, it is meaningful that one or more IDS sensors 24, 26, and 28 have pre-selected events 220 to be forwarded and / or data reduction (reduced event 221) according to specific criteria. These criteria should be characterized by low predictability.

[0053] In the case of IDS sensors 24, 26, and 28, and especially in the case of IDS Ethernet sensor 26, it is preferable to randomly and controllably select specific events 220 to be forwarded and / or reduce events to reduced events 221 for enhanced security. The random or arbitrary selection or reduction of data blocks of specific events 220 or Ethernet frames is nondeterministic and hidden from attackers. The randomized selection or reduction can, for example, be based on a single random number 273 from a specific control device. In the simplest case, the same random number 273 can also be used in other random-based scenarios, as a reference in the event manager 30 for reducing or prioritizing all events 220, storing random associations of events 220, etc. Alternatively, the corresponding random number can be regenerated in the control device.

[0054] The input message or data 211 typically has a corresponding header information 214 (e.g., specific address data) and subsequent useful data 213. It usually contains much header information that is not absolutely necessary for anomaly assessment. According to the invention, only the absolutely necessary specific address portions are forwarded as part of the reduced event 221 within the scope of event-related metadata 216, such as the source address (e.g., MAC address, e.g., 48-bit), the destination address (e.g., MAC address, e.g., 48-bit), and the ID number that caused the anomaly (event type 218). Other information—such as the physical port or port ID of the received frame, the source or destination IP address, and a description of the UDP / TCP port of the source or destination (if such information is included in the frame)—does not need to be transmitted in its entirety in event 220.

[0055] However, the useful data region 219 to be forwarded or selected is randomly selected from the useful data 213 of the input data 211, as if already combined. Figure 2The explanations in a and 2b are as follows. Thus, for example, the starting data number (the beginning of the storage area for the useful data to be transmitted, e.g., byte number xyz) can be randomly set (e.g., transmitting a data area whose initial value is randomly determined, e.g., useful data byte number 538 for event 220). The offset of the selected useful data area 219 (the amount of data transmitted, e.g., 10 bytes) can be fixed. Therefore, in addition to the minimum address information (source address, destination address), the useful data bytes numbered 538-547 are forwarded to the event manager 30 as the selected useful data area 219 within the range of event 221 reduced in this way. Alternatively, the offset of the selected useful data area 219 (the amount of useful data transmitted) can also be changed, preferably randomly. Preferably, the selected useful data area 219, particularly the starting or ending area of ​​the selected useful data area 219, depends on a random number 273. This random number 273 is particularly preferably dependent on the control device or gateway 20. Particularly preferably, the random number 273 is unique, i.e., given only once for this particular control device.

[0056] However, alternatively, random number 273 can also be updated. This yields the following advantages. By updating the random number, different events 220 can be recorded or selected even when the attack sequence (event 220 sequence) is the same. This is also the case when the attack targets only a single control device / vehicle 18 rather than the entire fleet. The following assumptions / examples:

[0057] 1. Repeating the same attack sequence multiple times (Event 220 sequence)

[0058] 2. Update random number 273 between attack sequences.

[0059] 3. Not all events 220 (event bursts) can be logged or selected within the scope of an attack sequence. This is followed by an event reduction for event report 242.

[0060] 4. Event report 242 with reduced event 221 is fully forwarded to parent instances 34, 36 between the two attack sequences. Thus, after repeating the same attack sequence multiple times, the complete attack sequence can be reconstructed through event report 242.

[0061] Sensor 26 can preferably adapt the selection of random number 273, or different regions of random number 273, to the size of input data 211, particularly to the size of input useful data 213. If useful data 213 has a small data area, then random number 273 must be selected such that the selection of a specific reduced useful data area 219 also falls only within this small data area of ​​useful data 213. Therefore, the random number 273, or the area of ​​the considered random number 273, must be correspondingly small. However, if input useful data 213 has a very large data area, then random number 273, or the area of ​​the considered random number 273, must be selected so large that the selection of a specific reduced useful data area 219 can also cover this large data area of ​​useful data 213. Therefore, random number 273 is correspondingly large.

[0062] By uniquely assigning a random number 273 to the corresponding control device 20, in the presence of other control devices, during analysis in the backend 36, by merging numerous reduced events 221 from multiple control devices, a complete message with a complete data area may be synthesized (which also arrives at the other control devices and is correspondingly detected and forwarded in a reduced manner by the corresponding equipped sensors 26). This is because other control devices with the same sensor functionality, as described above, now also randomly select other useful data areas 219 (with other randomly selected start or end addresses), which, after merging multiple reduced events 221, can cover most or all of the (useful) data area 213 based on sub-areas of different control devices or selected useful data areas 219. Event 220 can thus be reconstructed from reduced event 221 or selected useful data area 219 by different control devices, for example, by providing sub-data areas 538-547 (of a selected useful data area 219) from one control device, sub-data areas 548-557 (of another selected useful data area 219) from another control device, and sub-data areas 558-567 (of another selected useful data area 219) from yet another control device, and the corresponding selected useful data areas 219 are then recombined into a complete (useful) data area 213, for example, in a higher-level control device or in the backend 36. This is particularly true in the case of a so-called broadcast attack on the entire fleet or a so-called multicast attack on a portion of the fleet.

[0063] Preferably, the start and / or end of the forwarded or selected useful data area 219 is re-randomized after a specific event (periodically, startup of the control device, reset of the control device, etc.). For this purpose, for example, random number 273 can be regenerated. Alternatively, other ranges of random number 273 can be used to generate the start and / or end of the data area to be forwarded or the selected useful data area 219.

[0064] The processed, reduced event 221 is forwarded from sensor 26 to event manager 30. Therefore, event manager 30 does not obtain the complete data stream of these network frames from sensor 26, but only the reduced event 221 with a reduced data size. The reduction of the forwarded event 221 is exemplarily described based on IDS Ethernet sensor 26. However, in principle, this can also be implemented in other IDS sensors 24, 26, 28. However, due to the high information content in Ethernet frames with high transmission rates, such an event 220 would quickly cause buffer memory 206 to overflow. In the case of IDS CAN sensor 24, the corresponding data 211 appears at a lower data rate and with a smaller data volume, so that the event 220, which tends to be complete, can be forwarded and stored here. However, in principle, the data can also be reduced there, as described correspondingly.

[0065] Therefore, the following steps are performed in principle to reduce event 220 in sensors 24, 26, and 28. Data 211 is received from sensors 24, 26, and 28 and / or evaluated to determine if an anomaly exists. If an anomaly exists, data 211 is reduced. This reduction is performed by reducing address regions or headers 214 and / or data regions or useful data 213. Reduction of address regions 214 can be performed by selecting a target address and / or a source address. Reduction of useful data 213 is performed randomly. Useful data 213 is reduced randomly by randomly selecting the start and / or end values ​​of sub-regions of useful data 213. The offset of the data region (the amount of data transmitted) is set to a specific value. The reduced event 221 is transmitted to event manager 30. The reduced event 221 contains the reduced address data and / or the reduced or selected useful data 219. Random number 273 is updated according to a specific system state (periodic, startup, reset, etc.). Alternatively, the update of random number 273 can be performed randomly and / or time-controlled. The random number 273 used to specify the start or end region of the selected useful data region 219, or the range of the random number 273, can depend on the size of the useful region 213 of the received data 211.

[0066] according to Figure 3The structure of the event manager 30 is shown in more detail below. The event manager 30 has multiple interactive functional blocks. Each event 220 or reduced event 221 detected by sensors 24, 26, and 28 reaches block 202. Block 202 is used to select which of the input events 220 or reduced events 221 should be further processed. Specifically, block 202 is used to prioritize and reduce events 220 and 221.

[0067] Each event 220 or each decreasing event 221 also reaches block 204, which serves as a counter 204 for events 220 and 221. Upon occurrence of events 220 and 221, the corresponding counters are incremented, particularly the global event counter 205. Counter 204 preferably has different counters Z1, Z2, ... Zn for different event types 218 (ID1, ID2, ... IDn), as detailed above in conjunction with the corresponding sensors 24, 26, and 28. The global event counter 205 represents the sum of all counter readings for the different event types 218 (ID1, ID2, ... IDn) Z1, Z2, ... Zn. The output signal 231 of block 204 or the counter contains the counter readings for all events 220 and 221, i.e., the counter readings of the corresponding event-related counters Z1, Z2, ... Zn and the global event counter 205. The corresponding output signal 231 of block 204 is sent to block 210 to transmit event 220. Block 204 is configured to receive a reset signal 222, which indicates a reset request for one or more counters or event counters 204, 205. Block 204 receives a signal from block 202 for the reduction state 225, such as "Event Reduction Valid". In block 202, event reduction is valid, for example, when only a specific number of events 220, 221 are reduced and further processed as the selected event 226. This is particularly true when, for example, a large number of events 220, 221 are input within a so-called event burst range, accompanied by an increase in the fill level 228 of the buffer memory 206. In this case, an additional event 220 should be generated, for example, using event type 218 "Event Reduction Valid" as described above. Thus, for this event 220' with the associated event type 218, there is also a corresponding counter or counter reading.

[0068] The event processed by block 202 arrives at block 206 as the selected event 226. Block 206 serves as a memory or buffer for the selected event 226 delivered from block 202 and includes corresponding logic for this. In response, memory 206 reports a fill level or memory occupancy 228 back to block 202. Memory 206 is preferably a volatile memory, particularly a buffer for RAM. Furthermore, a time signal 224, particularly a global time signal 224, arrives at memory 206 or at the block used to buffer the selected event 226. Memory 206 is a component of event manager 30.

[0069] A specific event 236 stored or buffered in memory 206 arrives at block 210, which transmits an event report 242 based on the selected event 226 or the stored event 236. Block 210, used for transmitting the event, also receives the output signal 231 of event counter 204, such as the counter readings of counters Z1, Z2...Zn for the corresponding event type 218 and / or the counter reading of the global event counter 205. Block 210, used for transmitting events, particularly event report 242, exchanges signal 244 with cryptographic module 212. This cryptographic module performs cryptographic operations such as encryption, verification and authentication, and random number generation. Encrypted communication from block 210 to the outside world can be performed by means of cryptographic module 212. Specifically, cryptographic module 212 uses... Figure 2 The encryption 257 shown in d encrypts the event report 242. Similarly, the cryptographic module 212 can also use authentication information 256 to authenticate the event report 242, see also [reference 256]. Figure 2 d. Block 210 may reside in communication adapter 32 and / or event manager 30. Block 210 outputs the corresponding event report 242. Block 210 receives a request command 240 requesting to read the corresponding event 236 stored in memory 206, 208. The request command 240 may be performed periodically and / or in response to an explicit request. In addition, block 210 sends a signal 239 (event release) to memory 206. Thus, generally after successfully transmitting the associated event report 242, which also contains the stored event 236 or the selected event 226, memory 206 or 208 is notified to allow overwriting or deleting the stored and further transmitted events 236, 226.

[0070] In addition, an additional memory 208, specifically non-volatile memory, is provided in the event manager 30. The counter readings of a specific event 234 and / or event counter 204 that were previously cached in the buffer memory 206 are permanently stored in this additional, specifically non-volatile memory 208. For this purpose, memory 208 exchanges data with event counter 204 and / or with buffer memory 206.

[0071] The following is based on Figure 4 The workings of block 202 for prioritizing and reducing events 220 are described in more detail. The mechanism described below is used to select whether metadata 215 that is additionally helpful (and consumes a large amount of memory) to events 220, 221 should be stored. More generally, block 202 is used to select events 226 for further processing from events 220, 221 delivered to event manager 30. For each event type 218 of the obtained events 220, 221, it is tracked whether it is the first occurrence of that particular event type 218 or whether an event 220 with event type 218 has already been sent to memory or buffer 206; i.e., query 301. If event type 218 is the first occurrence, then the next step is block 304, where the corresponding event 220 is transferred to buffer 206 as the selected event 226 and stored there. Otherwise, the next step is block 302. In step 302, it is determined according to certain criteria whether events 220, 221 that have already occurred with event type 218 should still be stored. This is, for example, after events 220 and 221 have been randomly selected, particularly based on random number 273. This random selection can be particularly preferably based on a control device-specific or vehicle-specific random number 273. An intelligent algorithm should be used for the random selection to limit the overflow of buffer memory 206 in the worst-case attack scenario (a long-duration attack with so-called event bursts). On the other hand, a reasonable number of stored events 236 or selected events 226 or log entries should be maintained in normal scenarios to detect the widest possible range throughout the attack. To this end, in step 303, event 220 selected in step 302 is transferred to memory 206 as selected event 226 for storage.

[0072] Therefore, if an event is now selected according to the random criteria in step 302 (i.e., query 303), then events 220 and 221 are also sent to memory 206 as selected events 226 (i.e., step 304). Otherwise, the program flow ends without storing events 220 and 221 in memory 206 or storing additional metadata 215 for event 220. When memory 206 has been read out and notified via block 210, the monitoring of the first occurrence of event type 218 is reset. If events 220 and 221 are not selected or are discarded, the state "event rejected" is triggered for each discarded event 220 or 221. For this purpose, it is particularly preferable to set an additional counter 204 to detect the number of unselected events 220.

[0073] For additional priority settings, events 220 and 221 can optionally be grouped according to their respective event types 218, and separate instances can be set to randomly reduce the number of events for each event type 218. Priority settings can also be implemented additionally by forming groups. This means assigning event types 218 to different priority groups. For example, assigning a specific event type 218 (e.g., event type 218 with ID numbers ID1, ID6, ID14, ID23, etc.) to the priority group with the highest priority (Prio 1), assigning another associated event type 218 (e.g., event type 218 with ID numbers ID2, ID5, ID12, ID27, etc.) to the next lower priority group (Prio 3), and so on. For different priority groups (Prio1, Prio2, Prio3, ...), a different number of events 220 are randomly selected on average as the selected events 226 (N1: the number of events selected in priority group 1 (Prio1), Nx: the number of events selected in priority group x (Prio_x)). In priority groups with higher priorities, more events 220 are randomly selected on average than in priority groups with lower priorities (N1>N2...). This can be achieved, for example, by selecting regions B1, B2...Bx (with associated priority groups Prio1, Prio2...Prio_x) from which events 220 are chosen, or by selecting smaller numbers, indicating higher priorities (B1...Bx...Bx). <B2...)。

[0074] The selected event 226 is stored in volatile memory 206. However, the selected event 226 should not be immediately stored in non-volatile memory 208, as too frequent storage may damage non-volatile memory 208. For example, in combination with... Figure 6 To explain in more detail, the selected event 226 can be randomly stored in non-volatile memory 208.

[0075] One or more memories 206, 208 can process selected events 226 of different sizes. Here in Figure 7The image exemplarily illustrates memory 206. This memory includes a free storage area 250 and a filled storage area 252. In the filled storage area 252, multiple selected events 226 or 226 are stored. These entries 226 can each have different sizes. Due to the non-rigid partitioning of the storage areas, the storage space is optimally utilized. If memory 206 is full, a new selected event 226 is discarded. However, in principle, memory 206 is prevented from being filled through a self-regulating mechanism as described below. Thus, when the fill level 228 of memory 206 is very high, on average, far fewer events 220 are randomly selected than when the fill level 228 of memory 206 is low. However, if a selected event 226 is discarded due to buffer 206 being full, an event counter implementing a new event type 218 "logging buffer overflow (memory 206 overflow)" is used to determine the number of discarded events or entries. Figure 3 As shown, this can be done, for example, by notifying the counter 204 of the state 230 of the memory 206, or by always sending a pulse to the counter 204 at another selected event 226 when the memory 206 is full and cannot store anything.

[0076] Once all stored events 236 or selected events 226 within the scope of event reporting 242 have been successfully reported via block 210 to, for example, an external data logger in a control device, buffer 206 is released to overwrite or delete the corresponding event 226 (signal 239 releases the event). Writing events 236, particularly to non-volatile memory 208 such as flash memory, can advantageously be mapped using non-AUTOSAR storage mechanisms to ensure memory efficiency and performance requirements. However, the possibility of using standard AUTOSAR storage mechanisms also exists.

[0077] Combination Figure 5 The event counter 204 is described in more detail. For each event type 218, a separate counter Z1, Z2...Zn is implemented within the range of event counter 204. Event counter 204 starts with a value of zero. First, it is determined whether the counter reading is still less than the maximum value, i.e., query 260. If this is the case, the counters Z1, Z2...Zn for the corresponding event type 218 are incremented when events 220 and 221 of a specific event type 218 occur, i.e., step 262. Otherwise, the counter reading is kept at the maximum value so that no overflow occurs. Event counter 204 can be reset to zero upon request. For example, counter 204 can be implemented as a 32-bit counter.

[0078] according to Figure 6The non-volatile storage of event counter 204 and / or a specific selected event 226 in non-volatile memory 208 is described. Data should be stored in non-volatile memory 208 at regular time intervals. Such time intervals are, for example, in the range of seconds, minutes, to hours, such as data being stored every 30 minutes. The storage time points should be randomly selected so that an attacker cannot predict the write behavior. The storage period can be randomly controlled, for example, at specific intervals (e.g., within 30 minutes, however, the exact storage time point within, for example, the 30-minute interval is randomly controlled). Random variables (used to specify the storage time points) can be generated or selected based on random number 273 individual to the control device or vehicle.

[0079] Alternatively, a time-controlled storage moment can be randomly selected by multiplying a random number by a base time interval. Thus, for example, a specific base time interval of 15 seconds is multiplied by, for example, a 3-bit random number or a range of random numbers 273. Random number 273 itself can be updated periodically and / or randomly. Alternatively, random number 273 can be individually given, controllable specifically for a particular device or vehicle, such as in production and manufacturing. Alternatively, a specific range of random number 273 can be selected, on which a factor dependent on the range of random number 273 is formed.

[0080] Once a new selected event 226 occurs and can be stored in non-volatile memory 208, the selected event 226 is stored in a non-volatile manner. Furthermore, if a state change of the control device occurs, for example due to a request for a reset or sleep mode, resulting in the loss of the current RAM contents (and thus the loss of buffer memory 206) (which could also be caused by an attacker), the storage of the selected event 226 (in memory 206) and / or other information (such as a specific counter reading 232 of event counter 204) in non-volatile memory 208 is initiated.

[0081] Data should be stored redundantly so that it can be recovered even if some data is damaged. After reading from the non-volatile memory 208, the authenticity and integrity of the stored data should be checked or ensured. Preferably, the non-volatile memory 208 is located in a trusted area. It is assumed here that the memory inside the IC is classified as trusted. Standard AUTOSAR NVM (non-volatile memory) processing procedures can be used for this purpose.

[0082] exist Figure 5The diagram illustrates a state diagram for storing the selected event 226 in non-volatile memory 208. When state 264 is reached, data can, in principle, be stored in non-volatile memory 208. Storage in non-volatile memory 208 is not possible in state 266. The transition from state 264 to state 266 occurs after storage has been performed. The transition back to state 264, where storage is possible, is time-controlled. Preferably, the timing is random, as already described. When the control device is not ready for hibernation or reset, the system remains in state 266 (no storage).

[0083] Figure 7 A more accurate illustration of the components of the event manager 30 is shown. Multiple events 226 are stored in a buffer or memory 206 and form a filled storage area 252. Exemplarily, event number 2 (226.2), event number 4 (226.4), event number 8 (226.8), event number 13 (226.13), event number 25 (226.25), event number 38 (226.38), event number 77 (226.77), and event number 97 (226.97) are stored in the buffer 206 as selected events 226. As described below, these selected events 226 are selected from a series of occurring events 220 (numbered 0 to, for example, 200) according to a specific process and stored in the buffer 206 as selected events 226.

[0084] The unfilled or remaining areas of the buffer memory 206 form a free storage area 250.

[0085] The corresponding fill level 228 of the memory occupancy shown is formed in this embodiment by the last stored selected event 226.97. The storage area of ​​the buffer memory 206 is now divided into multiple regions 267 or fill level regions 267 between 0 and 100%. In this embodiment, these are, for example, ten (fill level) regions 267.1-267.10. In this embodiment, regions 267 are always selected to be the same size, and in this embodiment, these are 10% intervals. In this embodiment, memory 206 has exactly the current region 267.4, i.e., the fourth region 267.4, which is between 30% and 40% of the total memory occupancy.

[0086] In function block 268, the current memory region 267.4 where the current fill level 228 of memory 206 is located is determined. The current fill level region 267 (in this embodiment, it is used as the fourth region 267.4) reaches block 270.

[0087] In block 270, an offset 271 for the next event is determined. Offset 271 indicates how many events 220 should be selected from to store the next event 226 in memory 206. This number of events 220 (offset 271) depends on the corresponding fill level 228 or associated storage area 267, from which the next event 226 to be stored should be selected, in particular, randomly. When the fill level 228 or storage area 267 is low (the fill level 228 of memory 206 is relatively low), events 20 are stored more quickly, and therefore offset 271 is relatively small. As the fill level 228 or storage area 267 increases, offset 271 increases, i.e., fewer events 220 are stored or events 220 are selected only from a larger number (offset 271). This allows for targeted delays or prevention of memory 206 overflow. Within offset 271, the next event 226 to be stored is randomly selected. For each offset 271, only one event 220 (within offset 271) is always randomly selected or stored. Therefore, by varying the offset size according to the fill level 228 of memory 206, more or fewer events 220 are randomly selected or stored on average. Thus, as long as the fill level 228 of memory 206 is within a specific range 227, the event manager 30 always selects the event 226 to be selected from the same associated offset 271 until the fill level 228 reaches the next region 227 with a changed, typically increasing, offset 271.

[0088] If you leave the storage area 267 defined by the lower or upper limit value, you can increase or decrease the next offset 271 of the new area, for example, by increasing it by a certain multiple or decreasing it by a certain divisor.

[0089] Exemplary illustration based on Figure 8 The corresponding scenario in the table causes memory 206 to be occupied, such as... Figure 7As shown. Offset 271 can be selected for different fill levels 228 or storage regions 267, as illustrated below. Thus, for example, for a storage region between 0 and 10% (267.1), offset 271 can be assigned to 2 (from zero to 2, thus selected from three events 220), for a storage region between 10% and 20% (267.2) to 8 (from 0 to 8, thus selected from 9 events 220), for a storage region between 20% and 30% (267.3) to 32 (from 0 to 32, thus selected from 33 events 220), and for a storage region between 30% and 40% to 128 (from 0 to 128, thus selected from 129 events 220), and so on. For example, a corresponding increase in offset 271 for the next storage region 267 can be achieved by a corresponding factor (4), etc. Both storage area 267 and offset value 271 can be freely configured, thus adapting to their respective desired conditions, such as memory size.

[0090] exist Figure 7 In subsequent block 272, it should now be randomly (according to) fill level 228 or storage area 267. Figure 7 The random number 273 (exemplarily shown) is used to select the next event 220 to be stored. Here, it must be ensured that the offset 271, i.e., the number of events 220 or the range of the next events 220 to be considered—from which the corresponding event 220 to be stored should be randomly selected—can be covered by the random number 273 or a corresponding range of random number 273. The size of the range of random numbers 273 to be considered is selected according to the corresponding offset 271. If the random number 273 is, for example, bit-encoded, such as... Figure 7 As illustrated in the example, for example, at an offset of 271 (0-2), a temporary range of two-digit random numbers, 273_temp, is first selected. At an offset of 271 (0-8), a range x of four-digit random numbers, 273.x_v, is selected. At an offset of 271 (0-32), a temporary range of six-digit random numbers, 273_v, is selected. At an offset of 271 (0-128), a temporary range of eight-digit random numbers, 273_v, is selected. The temporary range of random numbers 273_v can be found in column 4, where... Figure 7The specific random number 273 is illustrated by example. Then, it is checked whether the portion of random number 273 contained in the temporary range 273_temp is less than or equal to the offset 271 of the next storage area 276. If this is the case, the temporary range 273_v is also used as a random number range as part 273.x of the random number. The corresponding query in column 5 can be answered with "true". In these cases, the temporary portion 273.x_v of the random number is consistent with the selected random number portion 273.x. If this is not the case (the query in column 5 is answered with "false"), the temporary portion 273.x_v of the random number is reduced. This can be done by omitting one bit, preferably the most significant bit (MSB). For the value of the random number thus derived in this range 273.x, it can now be ensured that the value is within the offset 271 of the next storage area 267.

[0091] Thus, for example, for an offset of 271 (0-8) of 8, consider the first 4 bits of the random number 273 so as to also cover the number 8 itself (the size of the current offset 271), for which see Figure 8 The column contains buffer entries numbered 3, 4, and 5. If the associated temporary random number range 273.5_v is less than or equal to the offset 271—for example, event number 25, 273.5 = 0b0111 = 7—then the 4-bit number is used directly. The associated query shows... Figure 8 The 5th column. Since the condition is met, the result is "true".

[0092] If the 4-bit value of the associated temporary random number range 273.4_v is greater than the offset 271—for example, for event number 13, 273.4 = 0b1100 = 12—then the 4-bit number is not used directly. Instead, the MSB (the most significant bit of the considered random number range 273.4) is truncated, and the resulting 3-bit number 0b100 = 4 is used. The truncated MSB is not discarded but is used as the LSB (least significant bit) of the next range 273.5_v to be considered. In this case, the associated condition (corresponding random number range 273.3 <= offset 271) is not met (the associated result is "false" in column 5). This process ensures that random number 273 is fully utilized and is not unnecessarily depleted quickly.

[0093] In order to determine the size of the random number range 273.x (e.g., the number of bits required for the range of random number 273), it must be considered whether the variables (e.g., the required number of bits) used to represent the size of the offset 271 of the associated storage area 267 of the next event 220 are sufficient.

[0094] Therefore, according to Figure 8In the embodiment, according to line 1, when the selected random number 273.1 is 2, event number 2 (220.2, global event counter 285 is 2) is selected as event 226.2 when the offset 271 is 2 (from 0 to 2) (after discarding events 220.0, 220.1, numbers 0 and 1). According to line 2, in the next offset range 271 (still in 0 to 2), event number 1 related to the offset range 271 is randomly selected. Event number 0 in the offset range 271 has been discarded (corresponding to global counter reading 285 of 3), but event number 1 in the offset range 271 is selected (corresponding to global counter reading 285 of 4, resulting in the selected event 226.4). According to line 3, the next offset range 271 is still in 2 (0 to 2) because the fill level 267 of buffer 206 is still in the region 267.1 between 0 and 10%. The random number for 273.3 is 2, so after discarding event numbers 0 and 1 in the offset range 271, event number 2 is selected (global counter reading 285 is 8, the selected event is 226.8). Since the subsequent padding level 267 is in the next padding level range 267.2, the new offset 271 now becomes 8 (0-8). As mentioned above, the next 4 bits of the temporary random number range 273.4_v are now considered. Since the associated random number for the temporary random number range 273.4_v is 12, which is greater than the current offset 271 (the query 12<=8 in column 5 yields "false"), the most significant bit of the temporary random number range 273.4_v is not used; instead, only the 3 least significant bits (binary 100, i.e., 4) within the selected random number range 273.4 are used. Therefore, for this new offset range 271 of 8 (0-8), event number 0 (global counter reading 285 is 9) is discarded to number 3, and event number 4 (global counter reading 285 is therefore 13) is selected as the chosen event 226.13. Figure 8 The corresponding values ​​for the additional fill level 267 are combined as an example.

[0095] Therefore, in block 272, it has now been randomly determined which event 220 will be selected next as the chosen event 226. The corresponding block 280 now monitors for the occurrence of a new event 220 (block 284). For example, it was previously set that after storing event 226.8 (the 8th event), event 226.13 (the 13th event) should be stored next. Block 280 therefore waits for event number 13, discarding the next event numbers 9-12 and storing event number 13 as the chosen event 226.13 in memory 206. Based on the new chosen event 226 with data size of metadata 215 (event-related metadata 216 and general metadata 217), a new fill level 228 for memory 206 is determined. This can be done particularly simply, for example, using length 232 already included in metadata 215.

[0096] The random number 273 is selected differently for different control devices or vehicles 18. Thus, for example, the random number 273 can be given once, individually for each vehicle or control device during production. Alternatively, the random number 273 can be regenerated internally according to specific rules. This regeneration can be performed periodically, for example, during system state transitions (such as during boot, reset, transition to sleep mode, etc.) and / or after a specific time.

[0097] Block 272 determines the next event hit 278 from the corresponding information (next event hit: the next event hit 278 at the next offset 271). The next event hit 278 reaches block 280 (throw the dice), where the delivered event 220 is either discarded (event 220 is not stored in buffer memory 206) or selected as the chosen event 226 for storage in buffer memory 206. If a selection is made (event hit 282), then block 284 is next. Block 284 is called for each event 220. However, block 284 itself calls block 280 (for each event 220), and block 280 provides feedback to block 284 about whether event 220 should be selected. If event 220 is selected by block 280, then block 284 triggers the storage of event 220 as the selected event 226 in memory 206.

[0098] In block 284 (on event), the selected event 220 is read in and subsequently stored as the selected event 226 in the free area 250 of buffer memory 206. Block 284 is always invoked for each new input event 220, 221. Block 284 is used for random selection, including possible reductions and priority settings of input events 220, 221.

[0099] In addition to the random selection in block 280, event 220 can also be randomly reduced, as described with ETH sensor 26. This allows for the random selection of specific data regions (preferably the beginning or end of a fixed data region). Similarly, only the specific reduced address data can be stored.

[0100] Similarly, when event 220 occurs frequently, or when sensors 24, 26, and 28 themselves (in the case of a specific source, such as Ethernet) can select or reduce event 220, similar to quasi-pre-filtering in event manager 30, to reduce the burden on event manager 30 (which also receives events 220 from other sources). If sensors 24, 26, and 28 have not yet forwarded each event 220 to event manager 30, this should also be transmitted to event manager 30 as a separate event type 218 (similar to reduction state 225 in event manager 30). However, in general, the event-related selection of event 220 can be made within sensors 24, 26, and 28 themselves and stored in their buffer memory. Similarly, corresponding counters can be set in sensors 24, 26, and 28 for the respective event type 218, which can be transmitted to event manager 30 when needed. Event 226' selected by sensors 24, 26, and 28 can also be transmitted to event manager 30 upon request, so as to be forwarded to the parent instance 34 and / or backend 36 if possible. Nevertheless, the procedures for random selection and / or priority setting described in conjunction with event manager 30 can still be run in sensors 24, 26, and 28. However, these procedures can be limited to specific data 211 from the corresponding source, so sensors 24, 26, and 28 can select only sensor-specific events 220.

[0101] To enhance security, the communication adapter 32 may be configured to send event reports 242 randomly, nondeterministically, and covertly to other IDS instances 34.

[0102] If already combined Figure 2As described in d, an event report 242 is generated from selected events 226 stored in buffer memory 206. This event report includes the selected events 226 stored in buffer memory 206. These selected events 226 are preceded by variables 254 (e.g., random numbers, time, or counters) that change relative to each event report 242. Furthermore, the event report 242 also includes authentication information 256. This authentication information allows for authentication between the communication adapter 32 and the unit receiving the event report 242 (IDS instance 34, backend 36, etc.). The authentication information 256 can be formed, for example, from at least a portion of the data in the event report 242, preferably from all the data in the event report 242 (except, of course, the authentication information 256 to be formed). A corresponding algorithm is stored in the event manager 30 for this purpose. For authentication purposes, the upper-level unit 34 and / or the back-end unit 36 ​​can, in the same manner, decrypt the corresponding data from the received event report 242 to form associated authentication information 256', and compare it with the actually received authentication information 256 (as transmitted in the event report 242). If they match, authenticity is assumed.

[0103] Event report 242 has a fixed length of 258. To achieve this fixed length of 258, data 254, 215_1, 215_8, 215_190, and 256 are also padded with so-called padding data 255. Padding data 255 does not contain information related to the event. For example... Figure 2 As shown in d, the data shown in event report 242 is encrypted 258 before transmission. Event report 242, encrypted in this way by encryption 258, is sent by communication adapter 32 and decrypted and authenticated by another IDS instance 34 or backend 36, as described. Even if the variable 254 changed for each event report 242 differs by only, for example, 1 bit, subsequent encryption 258 results in encrypted event report 242 being significantly different from the previous event report 242 (and not just by one bit).

[0104] Thus, a specific event 220 can be transmitted periodically and encrypted within the scope of event report 242 (using both plain text as part of the constantly changing variable 254 and encryption 258 of event report 242). However, even without a new event 220, so-called virtual events (e.g., consisting of padding data 255) can be transmitted periodically and encrypted. This is used to prevent data exchange between communication adapter 32 and other IDS instances 34 or backend 34 from being eavesdropped on or randomly hidden.

[0105] The following is based on Figures 9-14The communication flow between the event manager 30 and the communication adapter 32 within the control device or gateway 20, the communication flow between the communication adapter 32 and at least one additional IDS instance 34 within the vehicle 18, and the communication flow between the additional IDS instance 34 and the backend 36 are described exemplarily.

[0106] Communication from a control device such as gateway 20 to another (or more) IDS instance(s) 34 (e.g., a central event logger within vehicle 18) should ensure that the other IDS instance 34 or event logger is notified of unread entries or events 236 or selected events 226 stored in memory 206. The control device or gateway 20 should periodically send event reports 242 to the other IDS instance 34, preferably via a so-called heartbeat signal (a periodic signal that can be used to check whether communication participants are connected as prescribed). The heartbeat signal (including event reports 242) should be encrypted and authentic. Preferably, the transmitted information should be authentic (using authentication information 256 if necessary) and encrypted, preferably randomly or using random numbers 273, exchanged between the control device or gateway 20 and the other IDS instance 34. Preferably, event reports 242 should have a fixed length 257 and should be encrypted and authenticated. Each encrypted event report 242 should be different from the previous event report 242, even if the transmitted state has not changed.

[0107] Furthermore, communication from another IDS instance 34 to the control device or gateway 20 or associated communication adapter 32 should also feature the following characteristics: The data logger or IDS instance 34 should read event 236 or associated event report 242 as quickly as possible to prevent overflow of memory or buffer memory 206, in particular. Event report 242 should be readable, for example, via a diagnostic interface upon request. Alternatively, event report 242 can be sent periodically in its entirety. Event report 242 should be periodically transmitted or read, preferably in a real and encrypted or hidden manner, even if no new selected event 226 is available in the range of new event reports 242. Control device or gateway 20 should respond to read request 240 encrypted and authenticated with a response or event report 242 of fixed length. Each encrypted response or event report 242 should be different from the previous response or event report 242, even if the content does not change. This is exemplarily achieved through a constantly changing variable 254 as already described.

[0108] according to Figure 9Event manager 30 first selects the first selected event 226.1, and then selects the second selected event 226.2. These selected events are processed by event manager 30 as described. Therefore, the selected events 226.1, 226.2 are stored in memory 206. Communication adapter 32 includes signal 400, namely a time-dependent interrupt signal (Timer IRQ). The time-dependent signal 400 is preferably formed periodically, thereby periodically initiating the transmission of event report 242 from communication adapter 32 to another IDS instance 34 in vehicle 18. However, even in the absence of new events 226.1, 226.2, as described below, the signal (in the form of a “normal” event report 242) is also transmitted from communication adapter 32 to another IDS instance 34 (see signal 406). However, particularly preferably, the transmission of event report 242 is not triggered based on the acquisition of event 220 or the selected event 226, but is triggered periodically (by the elapsed time of the period). This is particularly advantageous because the transmission to other IDS instances 34 and / or backend 36 is always executed periodically, i.e., after a specific time has elapsed. Therefore, the behavior or anomaly detection of Event Manager 30 is opaque to the attacker. The attacker will never know whether their attack has been detected, what has been detected, or how the anomaly detection system is working.

[0109] After the communication adapter 32 receives signal 400 (Timer Interrupt), it requests event report 242, i.e., signal 402, from the event manager 30. The event manager 30 creates the corresponding event report 242, which includes the previously selected events 226.1 and / or 226.2 (with corresponding general metadata 217 and event-related metadata 216) and the changed variables 254. Furthermore, corresponding padding data 255 is added to achieve a fixed length 257 for the event report 242 (knowing the length of the authentication information 256 to be formed). Additionally, the event manager 30 uses a specific algorithm, for example, to generate authentication information 256 from the changed information 254, the selected events 226.1 and 226.2, and the padding data 255. The authentication information 256 formed in this way completes the event report 242. The complete event report 242 is then encrypted using key 258. The encrypted event report 242 arrives at the communication adapter 32 as signal 404. If the corresponding security requirements are met, encryption (using modified information 254 and / or key 258) and authentication (forming authentication information 256) can be performed in the event manager 30 and / or communication adapter 32.

[0110] Alternatively, communication adapter 32 can encrypt event report 242, for example, based on random number 273. Particularly preferably, a new random number 273 is always generated for encryption, for example, by hashing. This further makes decryption of the transmitted message or the encrypted event report 242 more difficult. If necessary, communication adapter 33 takes over authentication using authentication information 256 and / or the addition of changeable variables 254 and / or final encryption of the entire event report 242 using encryption 258.

[0111] Even if the event manager 30 does not provide a new event report 242 due to the occurrence of a new selected event 226, the corresponding signal 406 is sent in response to a timer interrupt (signal 400). A virtual message with the data format of event report 242 is then transmitted encrypted (using key 258) to the other IDS instance 34 via a random number or a constantly changing variable 254. The virtual message is always encrypted via the constantly changing variable 254 or a new random number, so that other messages or encrypted messages (signal 406) are always transmitted periodically even if a new selected event 226 does not occur. This periodic transmission allows for checking whether the communication connection between the communication adapter 32 and the other IDS instance 34 is functioning as specified.

[0112] After another IDS instance 34 receives a message sent from communication adapter 32 (signal 406), the other IDS instance 34 sends an acknowledgment signal (408) to communication adapter 32. After receiving acknowledgment signal 408, communication adapter 32 generates a request to event manager 30 to delete or rewrite the cached, reduced, selected event 226 or associated event report 242 (signal 410).

[0113] In an alternative embodiment, the upper-level instance 34 and / or the backend 36 checks the authenticity of the received encrypted event report 242. To do this, the upper-level instance 34 and / or the backend 36 decrypts the received message, i.e., the encrypted event report 242, using a known key 258. The event report 242 is then available in plaintext. The event report 242 is authenticated using a corresponding algorithm used to form authentication information 256 (which is also used by the event manager 30 or communication adapter 32 to create authentication information 256). To do this, all data from the received and decrypted event report 242 (except for authentication information 256) is used again to form corresponding authentication information 256'. The formed authentication information 256' is then compared with the authentication information 256 received within the scope of the event report 242. If they match, the received event report 246 is considered authentic. In this variant, further data communication with higher or lower-level instances is only possible after authentication has been performed. In this embodiment, signal 408 (acknowledgment signal) is sent to communication adapter 32 only after successful authentication, and then communication adapter 32 sends signal 410 to event manager 30 to release overriding of selected events 226.1, 226.2.

[0114] Preferably, the response or acknowledgment signals 408, 416 should also have a fixed length of 257'. Preferably, the acknowledgment signal 408 should be authenticated and encrypted. Each response or acknowledgment signal 408 of the parent instance 34 and / or the backend 36 should be different from each other, even if the content does not change.

[0115] Examples of such confirmation signals 408 and 416 can be found in... Figure 9 The acknowledgment signals 408 and 416 have a similar structure to event report 242. Acknowledgment signals 408 and 416 include a modifiable variable 254'. The modifiable variable 254' changes for each newly sent acknowledgment signal 408 or 416. The modifiable variable 254' can again be implemented, for example, through a random number, a counter, or time.

[0116] Particularly preferably, the modifiable variable 254' of the confirmation signals 408, 416 can be formed using the modifiable variable 254 of the just-transmitted event report 242. For this purpose, the parent instances 34, 36 are configured to extract the modifiable variable 254 from the received event report 242 and insert it into the confirmation signals 408, 416. Thus, in subsequent steps, the confirmation signals 408, 416 can also be authenticated by comparing the modifiable variable 254' of the received confirmation signals 408, 416 with the modifiable variable 254 of the previously sent event report 242. If they match, the true confirmation signal 406, 408 is inferred. Furthermore, the modifiable variable 254' does not need to be generated by the parent instances 34, 36 themselves. After this, the memory 206 can be released.

[0117] Furthermore, confirmation signals 408 and 416 include specific data 255', for example, in any template format. Additionally, confirmation signals 408 and 416 include authentication information 256'. Similar to the case of event report 242, the authentication information 256' can again be formed using a specific algorithm that uses the remaining data of confirmation signals 408 and 416, i.e., the variable 254' and data 255'. The authentication information 256' formed in this way completes confirmation signals 408 and 416. This confirmation signal has a fixed length 257'. It is then encrypted using key 258'. Optionally, this encryption 258' can be omitted.

[0118] The receiving instance (e.g., parent instance 34, backend 36) and / or communication adapter 32 or event manager 30 can decrypt confirmation signals 408, 412 (using key 258') and use them for authentication. To this end, a corresponding known algorithm is used to determine the derived authentication information 256'' from the received data (changeable variables 254', data 255'), and compares it with the obtained authentication information 256'. If they match, authenticity is assumed. If the obtained authentication information 256' is correct, a signal 410 for releasing memory 206 can be generated. If the authentication information 256' is incorrect, the signal 410 cannot be generated, and the selected event 226 contained in memory 206 will (still) not be deleted.

[0119] The additional IDS instance 34 also periodically receives a timer interrupt signal 412, which is similar to the signal 400 already described. In response to the interrupt signal 412, the additional IDS instance 34 sends an encrypted message, namely signal 414. This message may, if necessary, contain event report 242 or vehicle-related event reports (including other event reports), as transmitted via signal 406 prior to communication adapter 32. As with communication adapter 32, the message is encrypted by the additional IDS instance 34, specifically by a constantly changing variable 254' such as a random number 273. If communication adapter 32 does not transmit event report 242, for example because no new selected event 226 has occurred, a virtual message with the same data format as event report 242 is again transmitted to backend 36 in encrypted form (signal 414). Backend 36 sends an acknowledgment signal 416 to the additional IDS instance 34 and / or additional notifications or requests such as event 236 cached in buffer memory 206. Acknowledgment signal 416 may be formed as described above.

[0120] After receiving signal 410 regarding event release, event manager 30 selects the other selected events 226.3 and 226.4. Further procedures can be initiated from... Figure 10 The event manager 30 also selects another event 226.5. A timer interrupt (signal 420) re-arrives at the communication adapter 32. The communication adapter now requests event report 242 (signal 422) from the gateway 20. The event manager 30 sends event report 242 based on the selected events 226.3, 226.4, and 226.5 to the communication adapter 32, i.e., signal 424. After receiving event report 242, the communication adapter 32 sends event report 242 encrypted and authenticated by a new, changeable variable 254 (such as a random number) to the other IDS instance 34, i.e., signal 426. The other IDS instance 34 confirms the acquisition via acknowledgment signal 428. Acknowledgment signal 428 can be combined with acknowledgment signal 408 ( Figure 9 As described above. After receiving the acknowledgment signal 428, the communication adapter 32 sends a request to the event manager 30 to overwrite or delete the selected events 226.3, 226.4, and 226.5, on which the event report 242 is based, i.e., signal 430. Simultaneously, another selected event 226.6 is chosen between the transmission of signal 424 and the reception of signal 430. However, this selected event 226.6 cannot be overwritten yet because it is not yet the basis for the event report 242 already transmitted to the communication adapter 32. In this respect, signal 430 does not involve overwriting the selected event 226.6, but only overwriting the selected events 226.3, 226.4, and 226.5 that have already been transmitted within the scope of the last event report 242.

[0121] As already described, a timer interrupt (signal 432) also occurs at the other IDS instance 34. This prompts the other IDS instance 34 to transmit the newly received event report 242 in signal 426 in encrypted form to the backend 36, i.e., signal 434. The backend 36 acknowledges receipt of the corresponding message 434 via the corresponding acknowledgment signal 436, which is then sent to the other IDS instance 34. The acknowledgment signal 436 can be formed in the same way as acknowledgment signals 408 or 416.

[0122] Further procedures are underway. Figure 11 As shown in the diagram. Another timer interrupt occurs again for communication adapter 32, signal 440. Communication adapter 32 then sends a request to event manager 30 to send event report 242, signal 442. Event manager 30 sends event report 242 containing the event 226.6 selected during this period, signal 444. Communication adapter 32 encrypts event report 242 using a new changeable variable 256 and sends the encrypted event report 242 to another IDS instance 34, signal 446. Upon receipt, the other IDS instance 34 sends an acknowledgment, signal 448, and upon receiving signal 448, communication adapter 32 sends a request to event manager 30 to overwrite or release the already transmitted event 226.6, signal 450.

[0123] Another IDS instance 34 receives a timer interrupt again, signal 452. Then, the encrypted event report 242, if necessary, is transmitted to the backend 36 along with other event reports from other IDS systems. The backend 36 sends an acknowledgment signal and / or a request to release or overwrite the corresponding event to (multiple) other IDS instances 34, signal 456.

[0124] According to Figure 12In the exemplary process, no new selected event 226 occurs between the sending of the last event report 242 and the occurrence of a new timer interrupt (signal 460). After receiving the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 to the event manager 30 for the new event report 242. The event manager 30 generates an event report 242 with virtual content—despite the occurrence of the new selected event 226—and then sends this event report to the communication adapter 32, i.e., signal 464. The additional IDS instance 34 and / or backend 36 can recognize the virtual content as virtual content. The communication adapter 32 encrypts the received event report 242 with virtual content using a new, changeable variable 254 and sends the encrypted and authenticated event report 242 to the additional IDS instance 34, i.e., signal 466. This acquisition is confirmed by the additional IDS instance 34, i.e., signal 468. Upon receiving this signal, the communication adapter 32 resends the request signal to the event manager 30 to overwrite the last selected event 226, i.e., signal 470. Even if there are no new selected events in this constellation (226), this will still proceed.

[0125] The additional IDS instance 34 reacquires the timer interrupt, i.e., signal 472. Then, the additional IDS instance 34 encrypts the last acquired encrypted event report 242 sent by communication adapter 32 and, if necessary, sends it vehicle-related to the backend 36 along with other event reports from the other IDS system. The backend 36 sends an acknowledgment signal 476 and / or a request to release the event on which it is based to the additional IDS instance 34.

[0126] exist Figure 13In the communication sequence, communication adapter 32 re-acquires a timer interrupt, i.e., signal 480. This timer interrupt 480 can be a special signal that causes communication adapter 32 to request an event digest from event manager 30 (instead of one of the common event reports 242), i.e., signal 482. Event manager 30 sends the event digest to communication adapter 32, i.e., signal 484. The event digest can contain higher-level information, such as different counter readings 231 for different event types 218, or the occurrence of a new event type, etc. The event digest is also encrypted by communication adapter 32 again via a new, changeable variable 254, such as a random number, and transmitted to another IDS instance 34, i.e., signal 486. Once IDS instance 34 receives the encrypted event digest from communication adapter 32, the other IDS instance 34 forwards the event digest to backend 36, preferably in encrypted form. In this embodiment, no timer interrupt is set to initiate the communication process for the transmission between the other IDS instance 34 and backend 36. However, alternatively, the communication process can be initiated periodically, just like sending a common event report.

[0127] exist Figure 14 In the communication sequence, backend 36 sends a request for an event report to another IDS instance 34, signal 490. The other IDS instance 34, for example, sends an encryption request for the event report to communication adapter 32 via a diagnostic interface, signal 492. This encryption can be performed again using a changeable variable 254', such as a random number, which changes specifically for each encryption. After receiving request 492, communication adapter 32 sends a query for event report 242 to event manager 30, signal 494. After receiving the corresponding query 494, event manager 30 sends event report 242 to communication adapter 32, signal 496. Communication adapter 32 encrypts event report 242, for example, using a new changeable variable 254 such as a random number, and sends the event report to the other IDS instance 34, signal 498. After receiving the encrypted event report 242, the other IDS instance 34 sends event report 242 to backend 36. Backend 36 confirms the acquisition, i.e., signal 492, to another IDS instance 34. The other IDS instance 34 then confirms the acquisition of confirmation signal 492, i.e., signal 494, to communication adapter 32. After acquiring the corresponding signal 494, communication adapter 32 sends a corresponding request to event manager 30 to at least release or overwrite event 220 transmitted within the scope of the last event report 242.

[0128] The described method can be implemented in a computing unit, computer, or controller, particularly in the control equipment of vehicle 18. Similarly, the method can be created within the scope of a computer program configured to execute the method when it is executed on a computer. Furthermore, the computer program can be stored on a machine-readable storage medium. However, the program can be loaded wirelessly, for example, as software "with a radio," or wired via a diagnostic interface.

Claims

1. A method for handling data anomalies in a motor vehicle, wherein at least one sensor (24, 26, 28) for identifying anomalies acquires data (211), wherein the sensor (24, 26, 28) checks whether the acquired data (211) is abnormal, and generates an event (220, 221) based on the associated data (211) if an anomaly is identified, wherein it is determined whether to further process the event (220, 221). For events (220, 221) that have an event type (218) that has already occurred in previous events (220, 221), it is randomly determined whether to further process the events (220, 221).

2. The method according to claim 1, characterized in that, Randomly determine and / or determine whether to further process the events (220, 221) based on the number of occurrences of events (220, 221) of a specific event type (218).

3. The method according to any one of the preceding claims, characterized in that, When an event (220, 221) of a specific event type (218) occurs for the first time, further processing is performed on that event (220, 221).

4. The method according to claim 1, characterized in that, Determine whether to store and / or at least partially transmit the events (220, 221).

5. The method according to any one of claims 1 to 2, characterized in that, Determine the number of associated events (220, 221) for each of the different event types (218).

6. The method according to any one of claims 1 to 2, characterized in that, Different priority groups are assigned to specific event types (218), where events in higher priority groups (220) are further processed randomly with a higher probability than events in lower priority groups (220).

7. The method according to claim 6, characterized in that, Assign specific offsets (271) or ranges to different priority groups, and select at least one event (220) of the corresponding priority group to be further processed from the offsets or ranges, wherein the offset (271) or range of the priority group with higher priority is smaller than the offset (271) or range of the priority group with lower priority.

8. The method according to any one of claims 1 to 2, characterized in that, Randomly determine which of the events (220, 221) with the same event type (218) and / or priority group should be further processed from among multiple events (220, 221) with the same event type (218) and / or priority group.

9. The method according to any one of claims 1 to 2, characterized in that, Random determination is performed using a range (273.x) of vehicle-specific and / or control device-specific random numbers (273) and / or vehicle-specific and / or control device-specific random numbers (273).

10. The method according to any one of claims 1 to 2, characterized in that, Events to be further processed (220, 221) are at least partially stored in volatile memory (206) or buffer memory and / or non-volatile memory (208) and / or transmitted within the scope of event reports (242) and / or equipped with general metadata (217).

11. The method according to any one of claims 1 to 2, characterized in that, Randomly select events (220, 221) to be further processed from a specific number or offset (271) of events (220, 221).

12. The method according to any one of claims 1 to 2, characterized in that, Multiple sensors (24, 26, 28) are set up to identify anomalies. Each sensor obtains data (211) from different data sources (25, 27, 29). Each sensor (24, 26, 28) checks whether there are any anomalies in the obtained data (211). When an anomaly is identified, an event (220, 221) is generated based on the associated data (211), and the event (220, 221) is forwarded to the event manager (30).

13. The method according to claim 10, characterized in that, The general metadata includes the number of events (220, 221) that occurred, the time signal (274), the number of events (220, 221) that were not further processed, and the length (232).

14. The method according to claim 12, characterized in that, The data source includes a communication system and / or a host or microcontroller.

Images