DE102020204057A1 - Method for treating an anomaly in data, in particular in a motor vehicle - Google Patents

Abstract

A method for handling an anomaly in data, in particular in a motor vehicle, is proposed, with an event (220, 221) being generated as a function of the associated data (211) when an anomaly is detected, with an event (220, 221) being generated as a function of the event (220, 221) an event report (242) is generated, the event report (242) preferably being received cyclically and / or encrypted and a confirmation signal (406, 412) being sent back after the event report (242) has been received.

Description

Technical area

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

State of the art

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

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

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

For conventional IDS or IDPS systems (Intrusion Detection System, intrusion detection, a system for the automated detection of attacks on computer networks or computer interfaces; or IDPS: Intrusion Detection Prevention System, if an intrusion attempt is detected, corresponding data is not forwarded and thus the intrusion attempt prevented), deterministic behavior and the limited resources of the embedded systems are often problematic.

In contrast, it is desirable to specify an improved method for anomaly detection. This object is achieved by the features of the independent claim.

Disclosure of the invention

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

Because the event report is preferably received cyclically and / or encrypted and a confirmation signal is sent back after the event report has been received, the behavior of the system is concealed from an attacker. This ensures a non-deterministic behavior of the communication channel between the higher-level instance and the communication adapter or event manager, in particular with regard to the feedback.

In an expedient development it is provided that the confirmation signal comprises at least one variable variable for each confirmation signal and / or at least certain data or patterns and / or at least one piece of authentication information. Due to the variable size, the confirmation signal always looks significantly different from the attacker, especially after encryption, and is therefore not interpretable. With the additional variable signal it is ensured that it is up-to-date, as an elderly incident report cannot be accessed. The authentication information ensures that the confirmation signal comes from a real higher-level entity and was not generated by an attacker. This means that the local event report can be deleted in a trustworthy manner.

In an expedient development it is provided that the confirmation signal always has a constant length and / or is encrypted with a key. Due to the constant length, the attacker cannot understand whether certain data related to the attack were included.

In an expedient development it is provided that the confirmation signal is sent cyclically. This ensures a non-deterministic behavior of the communication channel between the higher-level instance and the communication adapter or event manager, in particular with regard to the feedback.

In an expedient development it is provided that a confirmation signal is only generated or sent back if the received event report has been classified as authentic. This ensures that the event report has been received and authentically confirmed by an authentic authority, the parent authority. This allows the event report to be deleted at the local level.

In an expedient development, it is provided that authentication information contained in the event report is used in order to classify the event report as authentic. This enables the higher-level unit to ensure the authenticity and topicality of the received event report. This prevents the transmission of manipulated or old event reports. For this purpose, it is expediently provided that the event report sent is decrypted.

In an expedient development, it is provided that authentication information is formed from data contained in the event report, in particular from the variable size and / or from at least one selected event and / or at least from filler data, which is linked to the authentication information contained in the event report. Information is compared. This ensures that the entire event report is authentic and up-to-date. For this purpose, in an expedient development, a confirmation signal is sent when the authentication information formed matches the authentication information received.

In an expedient further development, it is provided that after the receipt of the confirmation signal, a signal for releasing or overwriting a memory is triggered, in particular for overwriting at least one component of the last event report sent. This ensures that selected events are only deleted when it is ensured that they have reached a higher-level instance.

In an expedient development it is provided that the authentication information contained in the event report is formed by at least one additional item of information contained in the event report. This ensures the authenticity of the data contained in the event report.

In an expedient development it is provided that the variable size of the confirmation signal corresponds to the variable size of the event report. As a result, the events of the event report can be clearly assigned to the confirmation signal. By extracting the variable variable from the event report and using it as a variable variable for the confirmation signal, when the confirmation signal is received, it can be clearly assigned to the corresponding event report. A renewed injection of the same confirmation signal by an attacker cannot therefore be used advantageously, and replay attacks are not possible.

In an expedient development, it is provided that the event report is also transmitted cyclically if no new event has occurred since the last event report was sent. This means that the attacker cannot understand the effects of his attack behavior. For this purpose, it is provided in an expedient development that the event report always has the same length and / or is encrypted with a key.

• 1 schematisch Komponenten einer Anomalieerkennung,
• 2 einen beispielhaften Aufbau bzw. Wechselwirkung von empfangenen Daten, daraus abgeleitetem Ereignis, Aufbau des zugehörigen selektierten Ereignisses sowie einen Ereignisbericht,
• 3 einen genaueren Aufbau eines Ereignismanagers,
• 4 ein Flussdiagramm zur Auswahl eines weiterzuverarbeitenden Ereignisses,
• 5 ein Flussdiagramm für die Zählerinkrementierung,
• 6 ein Flussdiagramm für das Abspeichern eines nichtflüchtigen Speichers,
• 7 eine schematische Übersicht für die zufällige Auswahl eines abzuspeichernden Ereignisses,
• 8 die Zuordnung bestimmter in 7 verwendeter Größen,
• 9-14 unterschiedliche Kommunikationsabläufe zwischen Ereignismanager, Kommunikationsadapter, weiterer IDS Instanz sowie Backend.

Further advantageous refinements emerge from further dependent claims as well as the following description and the drawing. In the drawing shows

• 1 schematic components of an anomaly detection,
• 2 an exemplary structure or interaction of received data, the event derived from it, the structure of the associated selected event and an event report,
• 3 a more detailed structure of an event manager,
• 4th a flowchart for selecting an event to be processed,
• 5 a flowchart for counter incrementation,
• 6th a flow chart for saving a non-volatile memory,
• 7th a schematic overview for the random selection of an event to be saved,
• 8th the assignment of certain in 7th used sizes,
• 9-14 different communication processes between event manager, communication adapter, additional IDS instance and backend.

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

The detection of anomalies in data 211 is implemented using a so-called intrusion detection system, IDS or IDPS. In the following, IDS is used to describe a system that saves data 211 monitored for abnormalities. This can be data, for example 211 in the data connection in a communication network via which the control unit 20th such as a gateway on different communication channels (for example via bus systems such as 25 or the Internet 27 ) communicate, act. However, other dates should also be used 211 , for example system data within a control unit (or host arranged in it 29 or microcontroller or processor or within a chip) can be checked for anomalies by this IDS system. The detection of anomalies in the data 211 takes place through suitable sensors 24 , 26th , 28 . The sensors 24 , 26th , 28 are to the respective source of the data 211 (in the example of bus systems 25th , 27 or host 29 ) customized.

According to 1 is a control device such as a gateway 20th in a vehicle 18th arranged. The control unit or the gateway 20th includes processor (s), memory, main memory (for example as part of a host system 29 ) and interfaces for communication via a communication network. The gateway 20th processes, for example, instructions for the data connection. Communication creates data 211 in the form of data packets. Even with the operation of the host 29 data is created 211 , for example system data. In a normal state, setpoint values, for example with regard to the recipient and destination address, compliance with the correct program sequence (for example for the host 29 ), Time stamp, frequency of occurrence or frequency of data 211 certain data packets adhered to. The data 211 the data packets are used to fulfill the specific tasks between other control units or components in the vehicle, which are not shown in detail 18th exchanged. The gateway 20th is used to couple several communication systems or interfaces such as a CAN bus 25th , an ethernet connection 27 as well as a data connection to the host system 29 , which is part of the control unit 20th or the gateway. However, other communication systems (for example further wired bus systems such as LIN, CAN-FD etc. or wireless networks (for example WLAN or Bluetooth) can also be used by the gateway 20th be coupled with each other for the purpose of data exchange. In general, an intrusion detection IDS or anomaly detection in a control unit serves to collect all data 211 (data received by communication system 211 as well as within the control unit 20th by the host 29 generated data 211 ) monitor for corresponding anomalies. In the exemplary embodiment, the IDS function mechanism is exemplified for the gateway 20th described. In general, however, the described functionalities of anomaly detection or intrusion detection IDS can be implemented in any control device or any electronic components. In particular, it is not used on a vehicle 18th limited. Rather, any communication components, for example communication modules in the Internet (IOT Internet of Things) or in networked production systems, can be equipped with the functions described.

A communication component such as a control unit or the gateway 20th includes at least one anomaly detection 22nd . The via the interfaces of the respective communication systems 25th , 27 , 29 incoming data 211 are each via so-called sensors 24 , 26th , 28 for anomaly detection or intruder detection, IDS sensors for short. So are in the gateway 20th appropriate sensors 24 , 26th , 28 arranged. Such sensors 24 , 26th , 28 are used to detect whether data has been received 211 represents an anomaly. These are in the sensors 24 , 26th , 28 Corresponding filter algorithms or rule sets are stored, which are used to detect and classify anomalies. Becomes an anomaly through a sensor 24 , 26th , 28 determined, the corresponding data packet of the data is determined 211 as an event 220 (an attempted intrusion) classified. Generally speaking, the sensors 24 , 26th , 28 depending on the source 25th , 27 , 29 different anomalies as events 220 classify (assignment of the respective event 220 on certain types of events 218 ) and recognize. Depending on the type of event 218 (different types of anomalies in the data 211 ) represent the sensors 24 , 26th , 28 certain event-dependent metadata 216 as an associated event 220 together. In addition, the event-dependent metadata 216 also data or data parts of the anomalous data 211 contain. The event generated in this way 220 is sent to an event manager 30th forwarded. The sensors 24 , 26th , 28 are usually designed so that if there is no anomaly, the associated data 211 a communication system (e.g. bus systems 25th , 27 ) to be forwarded to the destination address. If an anomaly is detected, the sensors could 24 , 26th , 28 be designed so that the associated data 211 a communication system (e.g. bus system 25th , 27 ) cannot be forwarded to the destination address. Alternatively, the sensors 24 , 26th , 28 can also be used for events 220 to reduce (reduced event or pre-reduced event 221 ). By reducing this, the event manager could 30th be relieved, for example by only a small part of the user data of data containing anomalies 211 or data packets are forwarded. This is particularly advantageous with large amounts of data, such as those that occur with Ethernet connections.

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

The IDS CAN sensors 24 detect relevant events 220 of related event types 218 such as invalid CAN IDs, invalid message frequencies, invalid message lengths or the like. The IDS Ethernet sensors 26th detect for the ethernet 27 relevant events 220 of related event types 218 such as invalid addresses or MAC addresses, invalid message frequencies, invalid message lengths or the like. The IDS host sensors 28 detect for the host system 29 relevant events 220 of related event types 218 such as invalid code executions, corruption of programs, batch counters or the like. Often times, the respective types of events 218 provided with event-specific event ID or event ID. There are a number of predefined event types 218 for a wide variety of data sources with associated unique event IDs.

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

The event manager 30th is used for further processing of the incoming events 220 or the one in the respective event 220 event-dependent metadata included 215 . The event manager is used in particular 30th the aggregation, formatting or processing of the events 220 and / or the prioritization and / or reduction / selection of the events 220 and / or the storage or persistence or permanent storage of the selected and / or reduced events 220 , 221 . In particular, the event manager decides 30th what incoming events 220 are to be further processed. Those from the incoming events 220 are selected as selected events 226 designated. The corresponding selection should be made as non-deterministic as possible. The event manager also provides 30th the incoming events 220 or the selected events 226 particularly preferably with further generic metadata 217 . This allows the from different sensors 24 , 26th , 28 transmitted events 220 can be viewed at a higher level by, for example, the number of events that have occurred, the associated time stamp or time signal 224 or the like in the context of the generic metadata 217 to be added. Furthermore, it is ensured that even in the event of a so-called event burst, a sufficient number of meaningful events 220 as selected events 226 can be saved.

The event manager 30th exchanges signals with a communication adapter 32 intrusion or anomaly detection. The communication adapter 32 acts as a means of communication for data exchange between the event manager 30th and other components 34 , 36 outside of the anomaly detection 22nd of the control unit or Gateways 20th . Specifically, the communication adapter is used 32 as an interface for data exchange between the event manager 30th and other IDS instances 34 (preferably inside the vehicle 18th ) and / or a backend 36 (preferably outside the vehicle 18th ). The other IDS instance 34 can only be provided as an option.

To increase security, the event manager could 30th a random, for an attacker not determininistic and disguised reduction and prioritization of events 220 , 221 make. This could be random, non-deterministic for the attacker and disguise a non-volatile storage of selected events 226 be made. The randomly controlled selection could, for example, be based on a random number that is individual for a specific control unit 273 based. The event manager 30th a random storage of the meter readings 231 the event counter 204 take place. The event manager 30th also saves randomly in addition to the event-dependent metadata 216 the added generic metadata 217 as selected events 226 away.

The communication adapter 32 could be a random, non-deterministic and disguised uploading or sending of an event report to increase security 242 to other IDS instances 34 make. The randomly controlled upload could, for example, be carried out for a specific control device (or gateway 20th ) individual random number 273 based. So could certain events 220 as part of the incident report 242 are transmitted cyclically and encrypted. But even if there are no new events 220 so-called dummy events in the format of an event report could exist 242 are transmitted cyclically and encrypted. This is used to protect against eavesdropping or to conceal the data exchange between the communication adapter in a random manner 32 and other IDS instances 34 or the backend 36 .

An example is used in conjunction with 2 shown how data 211 from the sensor 24 , 26th , 28 in the event of an anomaly detected, processed further and sent to the event manager 30th be sent pending this one event report 242 via the communication adapter 32 sent.

An example is in 2a a data packet of data 211 shown how they could occur, for example, in a network frame (e.g. CAN, Ethernet). The data 211 assign a header 214 which includes, for example, the source address and the destination address (for example MACa, MACb). Also include the data 211 Payload 213 .

As will be explained in more detail below, the sensor could 24 , 26th , 28 optionally a user data area 219 randomly choose the one sent to the event manager 30th is forwarded. The sensor 24 , 26th , 28 has determined that it is an anomaly according to a certain type of event 218 (event ID or event ID, ID). Therefore the sensor generates 24 , 26th , 28 event-dependent metadata 216 as in 2 B shown. Depending on the type of event 218 (or ID) can be found in the event-dependent metadata 216 different information about the anomaly can be stored. In the exemplary embodiment, event-dependent metadata 216 including source and destination address (MACa, MACb), the type of event 218 and the selected user data area 219 used.

Alternatively, the event-dependent user data could also be used 213 completely in the context of the event 220 to the event manager 30th to get redirected.

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

You can also use for different types of events 218 further event-dependent information in the context of the event-dependent metadata 216 Part of the event 220 be. In the event type 218 “Change of context” could be the event-dependent metadata 216 for example include the context, for example in the size of 32 bits. In the event type 218 "Memory Access Violation" or "Code Execution Violation" could be the event-driven metadata 216 for example the accessed address (for example 32 bits), the program counter (for example 32 bits), the task ID (for example 8 bits). In the event type 218 "Detected reset of a control unit" could be the event-dependent metadata 216 for example the reason for the reset (for example 8 bits), for example POR (Point of Return), software reset, exceptions, etc.

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

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

Should be the event manager 30th this event 220 , 221 select for further processing (selected event 226 ) as explained in more detail below, become the event-dependent metadata 216 still generic metadata 217 added so that the in 2c metadata shown 215 develop. This generic metadata 217 are usually in the event manager 30th generated. These are, for example, output signals from the event counters 204 , i.e. current meter readings 231 to find the number of the global event 220 or how many events of a certain type of event 218 it is the current event 220 acts. In addition, the generic metadata 217 for example a time signal 224 include when this event 220 occured. Also, the metadata could 217 include what length 232 (Size of the data) the event-dependent metadata 216 or the complete metadata 215 exhibit. This is for the later memory management of the buffer memory 206 advantageous.

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

The event-dependent metadata 216 are taken over as the respective sensor 24 , 26th , 28 has formed. This event 220 with the corresponding both from the sensor 24 , 26th , 28 as well as from the event manager 30th formed metadata 215 is in the buffer memory 206 of the event manager 30th filed. In a similar way, others - as explained in more detail below - are handled by the event manager 30th selected or reduced events 226 (in the embodiment according to 2d exemplary as 215_1 , 215-8 , 215_190 labeled) in the buffer tank 206 filed.

Off in the buffer tank 206 stored selected events 226 (in the embodiment according to 2d exemplary as 215_1 , 215_8 , 215_190 designated (metadata 215 Event # 1, metadata 215 Event # 8, metadata 215 Event no. 190 as examples for selected events 226 ) now becomes an event report 242 generated. This includes those in the buffer memory 206 stored selected events 226 (in the example 215_1, 215_8, 215_190). These selected events are placed in front 226 one against each incident report 242 changed size 254 (for example random number, time or counter etc.). Also includes the event report 242 authentication information 256 . This can be used for authentication between communication adapters 32 or event manager 30th and the event report 242 receiving unit (IDS instance 34 , Backend 36 or the like). The event report 242 includes a fixed length 258 . By this fixed length 258 to achieve will be the data 254 , 215_1 , 215_8 , 215_190 , 256 still filled with so-called filler data 255 . These fill data 255 do not contain any event-relevant information. Before a transmission, the data shown are used in the event report 242 with an encryption 258 provided as in the 2d indicated. The way through the encryption 258 encrypted event report 242 is used by the communication adapter 32 sent, and from the other IDS instance 34 or backend 36 decrypted and authenticated as described.

IDS sensors 24 , 26th , 28 direct the events 220 or reduced events 221 to the event manager 30th Further. In the case of an attempted attack, a memory can be used, especially in Ethernet networks 206 , especially a volatile memory or buffer memory 206 , very quickly with a large number of events to be forwarded 220 with large amounts of data or event-dependent metadata 216 no longer all events 220 take up. This is due to the high data transfer rate or the large amount of data that can be transferred. Therefore it can make sense to have one or more IDS sensors 24 , 26th , 28 already a preselection of the events to be forwarded 220 and / or a data reduction (reduced events 221 ) according to certain criteria. These criteria are said to be characterized by low predictability.

With the IDS sensors 24 , 26th , 28 , especially with the IDS Ethernet sensors 26th , the selection of certain events to be forwarded is preferably carried out to increase security 220 and / or reducing the events to reduced events 221 randomly controlled. A random or arbitrary selection or reduction of certain events 220 or data blocks of an Ethernet frame are not deterministic and disguised for an attacker. The randomly controlled selection or reduction could, for example, be based on an individual random number for a specific control device 273 based. The same random number 273 In the simplest case, it could also be used as a reference in the event manager for the other random-based scenarios 30th for the reduction or prioritization of all events 220 , the random storage of events 220 or the like can be used. Alternatively, corresponding random numbers could also be regenerated in the control unit.

Incoming messages or data 211 usually have corresponding header information 214 (e.g. certain address data) and subsequent user data 213 on. Usually a lot of header information is contained that is not absolutely necessary for the anomaly evaluation. According to the invention, only certain address components that are absolutely necessary are included as part of a reduced event 221 in the context of the event-dependent metadata 216 forwarded such as the address of the source (e.g. MAC address, e.g. 48 bit), the address of the destination (e.g. MAC address, e.g. 48 bit) and the ID number that led to an anomaly (event type 218 ). Other information such as the physical port or port ID where the frame was received, IP address of the source or destination, details of the UDP / TCP port of the source or destination, if such information is contained in the frame, must be required not or not completely in the event 220 be transmitted.

The user data area to be forwarded or selected 219 however, a random selection is made from the user data 213 of the incoming data 211 as already in connection with the 2a and 2 B explained. For example, the number of the start date (start of the memory area of the user data to be transmitted, for example byte no. Xyz) could be determined on a random basis (for example, transfer a data area whose initial value was determined randomly, for example for this event 220 User data byte no. 538. The offset of the selected user data area 219 (Number of transmitted data, for example 10 bytes) could be chosen to be fixed. Thus, the user data bytes would be numbered 538-547 in addition to the minimum address information (source address, destination address) as a selected user data area 219 as part of the so reduced event 221 to the event manager 30th forwarded. Alternatively, the offset of the selected useful data area could also be used 219 (Number of transmitted user data) can be varied, preferably randomly. The selected useful data area preferably depends 219 , in particular the start or end area selected user data area 219 starting from a random number 273 . This random number is particularly preferred 273 depending on the control unit or the gateway 20th . The random number is particularly preferred 273 unambiguous, i.e. only assigned once for this specific control unit.

1. 1. Mehrfache Wiederholung derselben Angriffs-Sequenz (Sequenz von Ereignissen 220)
2. 2. Zwischen Angriffs-Sequenzen werden Zufallszahlen 273 erneuert
3. 3. Im Rahmen einer Angriffs-Sequenz können nicht alle Ereignisse 220 geloggt bzw. selektiert werden werden (Ereignis Burst). Es folgt eine EreignisReduktion für den Ereignisbericht 242
4. 4. Ein Ereignisbericht 242 mit reduzierten Ereignissen 221 wird an die übergeordnete Instanz 34, 36 vollständig zwischen zwei Angriffs-Sequenzen weitergeleitet. Hierdurch kann nach mehrmaliger Wiederholung der gleichen Angriffs-Sequenz die komplette Angriffs-Sequenz über die Ereignisberichte 242 rekonstruiert werden.

Optionally, the random number 273 but also to be renewed. This results in the following advantages. By renewing the random number, the same attack sequence (sequence of events 220 ) different events 220 logged or selected. This is also the case if the attack only affects a single control unit / vehicle 18th and not on the entire fleet. The following assumption / example:

1. 1. Multiple repetitions of the same attack sequence (sequence of events 220 )
2. 2. Random numbers are used between attack sequences 273 renewed
3. 3. Not all events can occur as part of an attack sequence 220 be logged or selected (event burst). An event reduction for the event report 242 follows
4. 4. An event report 242 with reduced events 221 is sent to the higher-level instance 34 , 36 completely passed between two attack sequences. As a result, after repeating the same attack sequence several times, the complete attack sequence can be accessed via the event reports 242 be reconstructed.

The sensor 26th could preferably choose the random number 273 or the different ranges of the random number 273 adapt to the size of the incoming data 211 , especially the size of the incoming user data 213 . Assign the payload 213 a smaller data area, the random number must 273 be chosen so that the selection of a certain reduced user data area 219 also only in this small data area of the user data 213 falls. The random number 273 or the considered range of the random number 273 must therefore be correspondingly small. Assign the incoming payload 213 However, if the data area is very large, then the random number must 273 or the considered range of the random number 273 be chosen so large that the selection of a certain reduced user data area 219 also this large data area of the user data 213 can cover. The random number 273 so it turns out to be correspondingly larger.

By the random number 273 uniquely for a respective control unit 20th was assigned, if there are other control units, the complete message (which was also sent to the other control units and with sensors equipped there accordingly) could possibly be sent 26th was also detected accordingly and forwarded in a reduced manner) with the complete data area during an analysis in the backend 36 by merging many reduced events 221 several control units can be combined. Because other control units with the same sensor function as described now also randomly select other user data areas 219 (with other randomly selected start or end addresses) from after merging several reduced events 221 a large part of the (useful) data area 213 or the complete data area of the useful data 213 based on the sub-areas or selected user data areas 219 of the various control units. Thus, the reduced events could be generated by various control units 221 or selected user data area 219 an event 220 can be reconstructed by, for example, partial data area 538-547 (of the selected user data area 219 ) from one control unit, partial data area 548-557 (of another selected user data area 219 ) from another control unit, partial data area 558-567 (of another selected user data area 219 ) made available by another control unit and the respective selected user data areas 219 for example in a higher-level control unit or in the backend 36 can be reassembled to form the complete (useful) data area 213. This is the case in particular in the case of a so-called broadcast attack on the entire vehicle fleet or a so-called multicast attack on parts of the vehicle fleet.

The random determination of the beginning and / or the end of the forwarded or selected useful data area 219 is preferably carried out again after certain events (cyclical, start-up of the control unit, reset of a control unit, etc.). For example, the random number 273 be regenerated. Alternatively, the random number could be a different range 273 for generating the beginning and / or end of the data area to be forwarded or selected user data area 219 can be used.

The edited reduced events 221 are from the sensor 26th to the event manager 30th forwarded. This gives the event manager 30th from this sensor 26th not complete data streams of these net frames, but only reduced events 221 with reduced data size. The reduction of the events to be forwarded 221 was based on an IDS Ethernet sensor 26th described by way of example. In principle, however, this could also be done in other IDS sensors 24 , 26th , 28 be realized. However, due to the high information content in an Ethernet frame with high transmission rates, such events would occur 220 quickly leads to a buffer overflow 206 to lead. With IDS CAN sensors 24 occur corresponding data 211 anyway with a lower data rate and lower data volume, so that here tend to be complete events 220 can be passed on and saved. In principle, however, the data could also be reduced there as described accordingly.

In principle, the following steps are therefore carried out to reduce the number of events 220 in the sensor 24 , 26th , 28 away. data 211 are from the sensor 24 , 26th , 28 receive and / or data 211 are evaluated as to whether there is an anomaly. If there is an anomaly, the data 211 reduced. The reduction takes place by reducing the address range or header 214 and / or the data area or user data 213 . The reduction of the address range 214 could be done by selecting the destination address and / or the source address. The reduction of the user data 213 happens randomly. The reduction of the user data 213 takes place randomly through the random selection of a start value and / or an end value of a sub-area of the user data 213 . The offset of the data area (number of transmitted data) is set to a certain value. The reduced events 221 will be sent to the event manager 30th transmitted. The reduced events 221 contain reduced address data and / or reduced or selected user data 219 . An update of the random number 273 takes place depending on certain system states (cyclical, start-up, reset etc.). Alternatively, the random number could be updated 273 be done randomly and / or time-controlled. The random number 273 or ranges of the random number 273 to determine the start or end area of the selected user data area 219 may depend on the size of the usable area 213 of the received data 211 .

According to 3 is the structure of the event manager 30th shown in more detail. The event manager 30th has several functional blocks that interact with one another. Each of the from the sensors 24 , 26th , 28 detected events 220 or reduced events 221 get to a block 202 . block 202 is used to select the incoming events 220 , or reduced events 221 that are to be further processed. In particular, block is used 202 the prioritization and reduction of events 220 , 221 .

Every event 220 or every reduced event 221 also comes to a block 204 who acts as a counter 204 for events 220 , 221 serves. When an event occurs 220 , 221 a corresponding counter is incremented, in particular a global event counter 205 . The counter particularly preferably has 204 different counters Z1 , Z2 , ... Zn for different types of events 218 (ID1, ID2, ... IDn) as above in connection with the corresponding sensors 24 , 26th , 28 detailed. The global event counter 205 in turn represents the sum of all counter readings of the counters Z1 , Z2 , ... Zn for different types of events 218 (ID1, ID2, ... IDn). The output signal 231 of the block 204 or counter contains the counter readings of all events 220 , 221 , i.e. counter readings of the respective event-dependent counter Z1 , Z2 , ... Zn as well as the global event counter 205 . The corresponding output signal 231 from block 204 becomes a block 210 to communicate the events 220 fed. block 204 is set up to receive a reset signal 222 , which is a reset request to the counter (s) or event counter 204 , 205 represents. block 204 receives from block 202 a signal for a reduction status 225 , for example "Event reduction active". In block 202 For example, event reduction is active if only a reduced number of certain events 220 , 221 as selected events 226 are further processed. This is particularly the case when, for example, a high number of events occurs in the context of a so-called event burst 220 , 221 enter with an increased level 228 of the buffer memory 206 . In this case, an additional event is supposed to be 220 can be generated, for example with an event type 218 "Event reduction active" as described above. For this event 220 ' with the associated event type 218 there is then also a corresponding counter or counter reading.

Block's 202 Edited events arrive as selected events 226 to a block 206 , which is used as a memory or buffer memory for the block 202 supplied selected events 226 serves and includes the corresponding logic for this. In return, the memory reports 206 the filling level or the memory usage 228 back to the block 202 . At the store 206 it is preferably a volatile memory, in particular a buffer memory of a RAM. In addition, the time signal arrives 224 , especially a global time signal 224 , to the memory 206 or to the block for buffering the selected events 226 . The memory 206 is part of the event manager 30th .

Certain in the store 206 saved or buffered events 236 get to a block 210 that of communicating event reports 242 depending on the selected events 226 or saved events 236 serves. The block 210 for communication of events also receives output signals 231 of the event counter 204 , for example counter readings of the counters Z1 , Z2 ... Zn for the respective event types 218 and / or the count of the global event counter 205 . The block 210 to communicate events, especially event reports 242 , exchanges signals 244 with a cryptography module 212 the end. The cryptography module carries out cryptography operations such as encryption operations, authentication and authentication operations and random number generation, etc. With the help of the cryptography module 212 can encrypt communication of the block 210 to the outside. The cryptography module 212 in particular, encrypts the event report 242 using the in 2d indicated encryption 257 by. The cryptography module 212 an authentication of the event report 242 using the authentication information 256 perform, compare as well 2d . block 210 can in the communication adapter 32 and / or in the event manager 30th be located. The block 210 gives corresponding event reports 242 the end. block 210 receives a request command 240 , corresponding in memory 206 , 208 saved events 236 read out. The request command 240 can be done cyclically and / or upon explicit request. The block also sends 210 a signal 239 (Event release) to the memory 206 . This is usually after a successful transmission of the associated event reports 242 that also includes the saved events 236 or selected events 226 include, the memory 206 respectively. 208 communicated that the stored and further communicated events 236 , 2 26th may be overwritten or deleted.

Also in the event manager 30th another store 208 provided, in particular a non-volatile memory. In the further, in particular, non-volatile memory 208 become certain events 234 that are in the buffer memory 206 were buffered, and / or counter readings of the event counter 204 saves permanently. To do this, the memory swaps 208 Data from with the event counter 204 and / or with the buffer storage 206 .

Based 4th the following is the operation of the block 202 to prioritize and reduce events 220 described in more detail. The mechanism described below is used to select whether for an event 220 , 221 additional helpful (and memory-intensive) metadata 215 should be saved. Block serves to further generalize 202 about this, from the event manager 30th supplied events 220 , 221 the events to be processed as selected events 226 to select. For every type of event 218 of the received event 220 , 221 tracks whether this is the first time this particular type of event has occurred 218 acts or whether an event 220 with this type of event 218 already to the memory or buffer 206 was sent; query 301 . When an event type occurs for the first time 218 closes block 304 in which the respective event 220 as a selected event 226 to the buffer 206 is transferred and saved there. Otherwise, the block closes 302 at. In this step 302 it is decided according to a certain criterion whether this is with regard to the type of event 218 event that has already occurred 220 , 221 should be saved anyway. This takes place, for example, after a random selection of the event 220 , 221 , especially based on a random number 273 . This random selection could particularly preferably be based on a control device-specific or vehicle-specific random number 273 . An intelligent algorithm is to be used for the random selection in order to prevent the overflow of the buffer memory 206 in worst-case attack scenarios (long-lasting attack with so-called event bursts). On the other hand, you want a reasonable number of stored events 236 or selected events 226 or log entries are received in normal scenarios in order to cover the largest possible spectrum over the entire attack. This is done in step 303 that in step 302 selected event 220 to the memory 206 as a selected event 226 transmitted for storage.

If now, then, according to random criteria according to step 302 the event was selected, query 303 so will this event too 220 , 221 as a selected event 226 to the memory 206 skillful, step 304 . Otherwise the program sequence ends without saving this event 220 , 221 In the storage room 206 or without additional storage of further metadata 215 to the event 220 . Monitoring the first occurrence of the event type 218 is reset when the memory 206 read out and over block 210 was communicated. If an event 220 , 221 was not selected or rejected, the status "Event rejected" is triggered for each rejected event 220 , 221 . A further counter is particularly preferred for this purpose 204 the number of unselected events 220 recorded.

The events could be used for additional prioritization 220 , 221 optional depending on the respective type of event 218 grouped and a separate instance for the random event reduction for each event type 218 are provided. In addition, prioritization can be achieved by forming groups. This means that the types of events 218 assigned to different priority groups. The priority group with the highest priority (Prio 1 ) are certain types of events 218 (for example, types of events 218 with the ID numbers ID1, ID6, ID14, ID23 etc.), a priority group with the next lower priority (Prio 2 ) become associated additional event types 218 (for example, types of events 218 with the ID numbers ID2, ID5, ID12, ID27 etc.), a priority group with the next lower priority (Prio 3 ) become associated additional event types 218 (for example, types of events 218 with the ID numbers ID3, ID9, ID13, ID19 etc.) etc. For different priority groups (Prio1, Prio2, Prio3, ...) a different number of events are randomly based 220 on average as selected events 226 selected (N1: (number of selected events for priority group 1 (Prio1), Nx: Number of selected events for priority group x (Prio_x). In the case of priority groups with high priority, more random events are on average 220 selected than for priority groups with low priority ( N1 > N2 ...). This could be achieved, for example, by the areas B1 , B2 .. Bx (with the associated priority groups Prio1, Prio2 ... Prio_x) or the number from which an event 220 selected the smaller the selected, the higher the priority (B1 <B2 ...).

Selected events 226 are in volatile memory 206 saved. Selected events 226 however, should not be directly in the non-volatile memory 208 saved, since too frequent saving the non-volatile memory 208 could damage it. Saving the selected events 226 in non-volatile memory 208 could be random, such as in conjunction with 6th explained in more detail.

The memory (s) 206 , 208 can be selected events 226 treat with different size. In the 7th here is an example of the memory 206 shown. It includes a free memory area 250 as well as a filled memory area 252 . In the filled memory area 252 are several selected events 226 respectively. 226 deposited. The entries 226 can each have different sizes. Due to the non-rigid division of memory areas, the memory space is optimally used. If the memory 206 is full, new selected events would be 226 discarded. In principle, however, as explained below, the memory is completely filled 206 prevented by a self-regulating mechanism. So are at a very high level 228 of memory 206 on average, there are far fewer events based on chance 220 selected than at a low level 228 of memory 206 . If, however, selected events 226 are discarded due to a full buffer 206 , then an event counter for a new event type 218 "Logging Buffer Overflow 206 ) "Implemented to determine the number of discarded events or entries. This can be done as in 3 shown for example by the status 230 of memory 206 the counter 204 is communicated or this signal 230 always then a pulse to the counter 204 sends, if again another selected event 226 due to full memory 206 cannot be saved.

Once all saved events 236 or selected events 226 successful over block 210 as part of an incident report 242 For example, reports have been made to an external data logger in the control unit, the buffer 206 to overwrite or delete the corresponding events 226 released (signal 239 free event). Writing events 236 especially in a non-volatile memory 208 like a flash memory, it could advantageously be mapped using a non-AUTOSAR storage mechanism in order to ensure storage efficiency and performance requirements. However, there is also the option of using a standard AUTOSAR storage mechanism.

Combined with 5 becomes the event counter 204 described in more detail. For every type of event 218 becomes its own counter Z1 , Z2 ... Zn as part of the event counter 204 implemented. The event counter 204 always starts with the value zero. First of all, it is determined whether the counter reading is still less than a maximum value, query 260 . If this is the case, when an event occurs 220 , 221 a certain type of event 218 the counter Z1 , Z2 ... Zn for the respective type of event 218 incremented, step 262 . Otherwise the counter reading is kept at the maximum value, so there is no overflow. It is possible to use the event counter 204 reset to zero on request. The counter 204 could for example be implemented as a 32-bit counter.

According to 6th becomes the non-volatile storage of the event counter 204 and / or certain selected events 226 in the non-volatile memory 208 described. The data should be in the non-volatile memory 208 saved at regular intervals. Such time intervals are, for example, in the seconds, minutes to hours range, for example the data is saved every 30 minutes. The time for saving should be chosen randomly in order to make the writing behavior unpredictable for an attacker. The storage cycles could be randomly controlled, for example in a certain interval (for example within 30 minutes, etc., but the exact time of saving within the, for example, 30 minute interval is randomly controlled). Again, the random variable (for determining the storage time) could be a function of a control device-specific or vehicle-specific random number 273 can be generated or selected.

Alternatively, time-controlled storage moments could be chosen randomly by multiplying a random number by a basic time interval. For example, it is a specific basic time interval of 15 seconds, which is multiplied by, for example, a 3-bit random number or a random number range of a random number 273 . The random number 273 itself could be updated cyclically and / or randomly. Alternatively it could be the random number 273 ECU-specific or vehicle-specific individually assigned, for example, in production and manufacturing. Alternatively, a certain range could be the random number 273 be selected, on the basis of which the factor depending on the range of the random number 273 is formed.

As soon as a new selected event 226 occurs and storage in the non-volatile memory 208 is possible, the selected events 226 stored non-volatile. About that In addition, the selected events are saved 226 (In the storage room 206 ) and / or further information such as certain meter readings 232 of the event counter 204 in the non-volatile memory 208 initiated when a state change (which could also have been caused by an attacker) of the control unit results in a loss of the current RAM content (and thus the loss of the buffer memory 206 ) is pending, for example, due to a requested reset or sleep mode.

The data should be stored in a redundant manner so that it can be recovered even if part of the data was corrupted. The authenticity and integrity of the stored data should be checked or ensured after they have been read from the non-volatile memory 208 . The non-volatile memory is preferred 208 arranged in a trusted zone. It is assumed that the IC internal memory is classified as trustworthy. A standard AUTOSAR NVM (Non Volatile Memory) handler could be used for this.

In 5 is an example of a state graph for storing selected events 226 in non-volatile memory 208 shown. In a state 264 is the storage of data in non-volatile memory 208 basically possible if this condition 264 is achieved. In a state 266 is a storage in the non-volatile memory 208 not possible. A change of state 264 in the state 266 takes place after saving. A change back to the state 264 , in which saving is possible, is time-controlled. The time is preferably random as already described. The system remains in the state 266 (no saving) if the control unit does not prepare for an idle state or reset.

7th shows a more detailed representation of the components of the event manager 30th . In the buffer memory or memory 206 are multiple events 226 and form the filled memory area 252 . Event no.2 ( 226.2 ), an event # 4 ( 226.4 ), an event # 8 ( 226.8 ), an event No. 13 ( 226.13 ), an event No. 25 ( 226.25 ), an event No. 38 ( 226.38 ), an event number 77 ( 226.77 ) and an event no. 97 ( 226.97 ) as selected events 226 in the buffer memory 206 saved. These selected events 226 emerged from a series of events following a specific procedure, as described below 220 (No. 0 to e.g. 200) selected and stored in the buffer memory 206 as selected events 226 saved.

The unfilled area or the remaining area of the buffer memory 206 forms the free memory area 250 .

The corresponding fill level 228 the memory allocation shown is formed in the exemplary embodiment by the last selected event that was saved 226.97 . The storage area of the buffer memory 206 is now in several areas 267 or fill level ranges 267 divided between 0 and 100%. In the exemplary embodiment, these are, for example, ten (fill level) areas 267.1-267.10 . In the exemplary embodiment, the areas are 267 always chosen to be the same size, in the exemplary embodiment these are 10% intervals. In the exemplary embodiment, the memory 206 just the current area 267.4 , so the fourth area 267.4 which is between 30 and 40% of the total memory usage.

The current memory area 267.4 , which shows the current level 228 of memory 206 is located in the functional block 268 determined. The current level range 267 , in the exemplary embodiment 267.4 for the fourth area, comes to a block 270 .

In block 270 becomes the offset 271 determined for the next event. The offset 271 indicates from how many events 220 the next one in memory 206 event to be saved 226 should be selected. This number (offset 271 ) of events 220 from which the next event to be saved 226 should be selected in particular at random, depends on the respective fill level 228 or associated memory area 267 . When the fill level is low 228 or memory area 267 (the level 228 of memory 206 is relatively low) events become faster 20th stored, so the offset is 271 relatively low. With increasing fill level 228 or memory area 267 takes the offset 271 to, so there will be fewer events 220 saved or only one event is saved 220 from a larger number (offset 271 ) selected. This can lead to a targeted overflow of the memory 206 delayed or prevented. Within an offset 271 the next event to be saved is selected at random 226 . Per offset 271 will only ever be one event 220 (within the offset 271 ) randomly selected or saved. By varying the offset size depending on the fill level 228 of memory 206 thus become more or less events on average 220 randomly selected or saved. As long as the level is 228 of memory 206 within a certain range 227 is located, the Event Manager selects 30th always from the same associated offset 271 an event to be selected 226 off until the level 228 the next area 227 achieved with a changed, usually increased offset 271 .

Will the storage area 267 , defined by the lower or upper limit value, the next offset 271 increased or decreased for the new area, for example by a certain factor or divisor.

A corresponding scenario is exemplified in the table according to 8th shown this to a memory occupancy 206 as in 7th shown leads. The offset 271 could for the different fill levels 228 or memory areas 267 can be selected by way of example as specified below. For example, the offset for the memory area could be between 0 and 10% (267.1) 271 to two (from zero to two, so the selection is made from three events 220 ), for the memory area between 10% and 20% (267.2) to 8 (from zero to eight, so the selection is made from nine events 220 ), for the memory area between 20% and 30% (267.3) 32 (from zero to 32, the selection is made from 33 events 220 ) and for the memory area between 30% and 40% to 128 (from zero to 128, the selection is made from 129 events 220 ) etc. can be assigned. A corresponding increase in the offset 271 for the next memory area 267 could, for example, by a corresponding factor ( 4th ) or the like. Both the memory areas 267 as well as the offset values 271 can be freely configured and thus adapted to the respective desired situation such as memory size, etc.

In the following block 272 the 7th should now be the next event to be saved 220 random (depending on the random number 273 as in 7th shown as an example) depending on the level 228 or the memory area 267 to be selected. It must be ensured that the offset 271 , so the number of events 220 or the area of the next events to be considered 220 , from which the respective event to be saved 220 to be selected randomly from the random number 273 or a corresponding range of the random number 273 can be covered. Depending on the respective offset 271 becomes the size of the range of the random number to be considered 273 chosen. Is the random number 273 for example bit-coded as in 7th are shown by way of example for an offset 271 from two (0-2) initially a preliminary range of the random number 273_temp preliminary selected with the size of two bits. At an offset 271 of 8 (0-8) becomes a range x of the random number 273.x_v selected in the size of 4 bits. At an offset 271 of 32 (0-32) becomes a preliminary range of the random number 273_v selected in the size of 6 bits. At an offset 271 from 128 (0-128) becomes a preliminary range of the random number 273_v selected in the size of 8 bits. The preliminary range of the random number 273_v can be column 4th refer to, given there by way of example for the specific random number 273 the 7th . It is then checked whether the section of the random number contained in the preliminary area 273_temp 273 is less than or equal to the offset 271 for the next memory area 276 . If so, it becomes the provisional range 273_v also actually as a section of the random number 273.x used as a random number range. The corresponding query in column 5 can be answered with "TRUE". In these cases, the temporary portion of the random number is correct 273.x_v with the selected section of the random number 273.x match. If this is not the case (query in column 5 is answered with "FALSE"), then the provisional section of the random number 273.x_v scaled down. This can be done by omitting a bit, preferably the most significant bit (MSB). For the resulting value of the random number in this area 273.x it can now be ensured that this value is within the offset 271 for the next memory area 267 lies.

For example, for an offset 271 of 8 (0-8) initially 4 bits of the random number 273 considered to include the number 8th itself (size of the current offset 271 ), see columns with buffer entries no. 3, 4, 5 in 8th . Is the 4-bit value of the associated preliminary random number range 273.5_v <= the offset 271 - e.g. event no. 25, 273.5 = 0b01 11 = 7, then this 4-bit number is used directly. The associated query shows column 5 the 8th . Since the condition is met, the result is "TRUE".

Is the 4-bit value of the associated preliminary random number range 273.4_v > the offset 271 - e.g. event no. 13, 273.4 = 0b1100 = 12, then this 4-bit number is not used directly, but the MSB (most significant bit for the considered range of the random number 273.4 ) and the resulting 3-bit number 0b100 = 4 is used. The truncated MSB does not have to be thrown away, but is used as the LSB (least significant bit) of the next section of the random number to be considered 273.5_v a. The associated condition (is the corresponding random number range 273.3 <= Offset 271 ) is not fulfilled in this case (corresponding result "FALSE" in column 5 ). This procedure can ensure that the random number 273 used completely and not consumed unnecessarily quickly.

For determining the size of the random number range 273.x (e.g. the number of bits required for the range of the random number 273 ) it must be taken into account whether the size (e.g. the number of bits required) to represent the size of the offset 271 of the associated memory area 267 of the next event 220 sufficient.

In the embodiment according to 8th is therefore according to line 1 at the offset 271 of 2 (from 0-2) for the selected random number 273.1 of 2 so event no. 2 ( 220.2 , global event counter 285 is 2) (after discarding the events 220.0 , 220.1 0 and 1) as a selected event 226.2 selected. According to line 2 will be at the next offset range 271 (still at 0-2) random event no. 1 related to this offset range 271 selected. Event no. 0 in this offset area 271 was discarded (would correspond to the global counter reading 285 of 3), but event number 1 in this offset range 271 was selected (corresponds to the global counter reading 285 of 4, results in the selected event 226.4 ). The next offset range 271 lies according to line 3 still at 2 (0-2) because the level 267 of the buffer 206 still in the field 267.1 is between 0 and 10%. The random number for 273.3 is at 2, so after discarding the events number 0 and 1 in this offset range 271 event no. 2 is selected (global counter reading 285 at 8, selected event 226.8 ). Since then the level 267 in the next level range 267.2 the new offset changes 271 now on 8 (0-8). As described above, the next 4 bits now become the preliminary random number range 273.4_v considered. As the associated random number of the preliminary random number range 273.4_v with 12 is greater than the current offset 271 (Query 12 <= 8 in column 5 results in "FALSE") becomes the most significant bit of the preliminary random number range 273.4_v not used, only the lower 3 bits within the selected random number range 273.4 (binary 100, so 4). Thus, for this new offset range 271 from 8 (0-8) the events no. 0 (global counter reading 285 is 9) to No. 3 discarded and event number 4th (global counter reading 285 is therefore 13) as a selected event 226.13 selected. Exemplary represents 8th the corresponding values for further filling levels 267 together.

In block 272 So now it was determined randomly which event 220 next is selected as the selected event 226 . The corresponding block 280 now monitors the occurrence of new events 220 (Block 284 ). For example, that was determined beforehand after the saved event 226.8 (8th event) next the event 226.13 (13th event) is to be saved. block 280 waits for event no. 13, so discards the next events no. 9-12 and first saves event no. 13 as a selected event 226.13 In the storage room 206 away. Depending on the new selected event 226 with a data size of the metadata 215 (event-dependent metadata 216 and generic metadata 217 ) becomes the new level 228 of memory 206 determined. This could, for example, be particularly simple using the length 232 as already in the metadata 215 included.

The random number 273 is for different control units or vehicles 18th different to choose. So could the random number 273 for example, they can be assigned once for each vehicle or control unit in production. Alternatively it could be the random number 273 generated internally according to certain rules. The regeneration could take place, for example, in the event of transitions from system states (when booting, resetting, transferring to a sleep mode, etc.) and / or cyclically after certain times.

The block determines from the corresponding information 272 the next event hit 278 (next event hit: the next event hit 278 in the next offset 271 ). The next event hit 278 comes to a block 280 (throw the dice), in which the randomized event occurs 220 either discarded (event 220 will not be in the buffer 206 saved) or selected as a selected event 226 for storage in the buffer memory 206 . If the selection is made (event hit 282 , event hit) closes block 284 at. block 284 will be at every event 220 called. block 284 itself, however, calls (at every event 220 ) Block 280 on what feedback to block 284 indicates whether the event 220 should be selected or not. If the event 220 by block 280 is selected, then Block triggers 284 saving the event 220 In the storage room 206 as a selected event 226 .

In block 284 (on event) the selected event is read in 220 for subsequent storage in the free area 250 of the buffer memory 206 as a selected event 226 . block 284 is always with every new incoming event 220 , 221 called. block 284 is used for random selection including possible reduction and prioritization of incoming events 220 , 221 .

In addition to the random selection in block 280 can also be a random reduction of the event 220 take place, for example, with the ETH sensors 26th described. In this way, a certain data area (beginning of a preferably fixed data area or end of a data area) can be selected randomly. Likewise, only certain reduced address data could be saved.

Likewise, if there is a high volume of events 220 or the sensor in general 24 , 26th , 28 itself (with a specific source, such as Ethernet) events 220 select or reduce, a sort of pre-filtering analogous to the event manager 30th to the event manager 30th (with that too events 220 other sources). If the sensor 24 , 26th , 28 already individual events 220 not to the event manager 30th forward, this should also be a separate event type 218 to the event manager 30th communicated (analogous to the reduction status 225 in the event manager 30th ). In general, however, the event-dependent selection of events 220 in the sensor 24 , 26th , 28 take place itself and in a buffer memory of the sensor 24 , 26th , 28 be filed. Corresponding counters can also be installed in the sensor 24 , 26th , 28 for the respective event types 218 to be provided to the event manager if necessary 30th could be transmitted. The sensor could also 24 , 26th , 28 selected events 226 ' at the request of the event manager 30th communicated to them for possible forwarding to the higher-level authority 34 and / or the backend 36 . Those in connection with the event manager 30th The described procedures for random selection and / or prioritization can nonetheless be used in the sensor 24 , 26th , 28 expire. However, you can only access the special data 211 be limited for the particular source, the sensor 24 , 26th , 28 can therefore only sensor-specific events 220 select.

The communication adapter 32 could be a random, non-deterministic and disguised sending of an event report to increase security 242 to other IDS instances 34 provide.

As already in connection with 2d is written from in the buffer memory 206 stored selected events 226 an event report 242 generated. This includes those in the buffer memory 206 stored selected events 226 . These selected events are placed in front 226 one against each incident report 242 changed size 254 (for example random number, time or counter etc.). Also includes the event report 242 authentication information 256 . This can be used for authentication between communication adapters 32 and the event report 242 receiving unit (IDS instance 34 , Backend 36 or the like). The authentication information 256 could for example be formed from at least part of the data in the event report 242 , preferably from all data in the event report 242 (With the exception of course the authentication information to be created 256 ). There is a corresponding algorithm in the event manager for this 30th deposited. A higher-level unit can be used for authentication purposes 34 and / or the backend 36 in the same way from the corresponding data of the received event report 242 after decryption the associated authentication information 256 ' and with the authentication information actually received 256 as in the event report 242 transmitted to be compared. If they match, authenticity is assumed.

The event report 242 includes a fixed length 258 . By this fixed length 258 to achieve will be the data 254 , 215_1 , 215_8 , 215_190 , 256 still filled with so-called filler data 255 . These fill data 255 do not contain any event-relevant information. Before a transmission, the data shown are used in the event report 242 with an encryption 258 provided as in the 2d indicated. The way through the encryption 258 encrypted event report 242 is used by the communication adapter 32 sent, and from the other IDS instance 34 or backend 36 decrypted and authenticated as described. Even if the for each event report 242 changing size 254 If, for example, only differs by 1 bit, then the subsequent encryption has the effect 258 that the encrypted event report 242 strongly (and not just in one bit) from the previous event report 242 differs.

So could certain events 220 cyclically and encrypted (both with a constantly changing size 254 as part of the event report 242 in plain text as well as with the encryption 258 of the event report 242 ) as part of the incident report 242 be transmitted. But even if there are no new events 220 so-called dummy events (consisting, for example, of filler data 255 ) are transmitted cyclically and encrypted. This is used to protect against eavesdropping or to conceal the data exchange between the communication adapter in a random manner 32 and other IDS instances 34 . or the backend 34 .

The following are the communication flows between event managers 30th and communication adapter 32 within the control unit or gateway 20th , as well as between communication adapters 32 and at least one other IDS instance 34 inside the vehicle 18th as well as between the other IDS instance 34 and the backend 36 based on 9-14 described by way of example.

Communication from the control device such as the gateway 20th to further IDS instance (s) 34 (for example a central event logger within the vehicle 18th ) should ensure that the further IDS instance 34 or the event logger about unread entries or in the memory 206 saved events 236 or selected events 226 is informed. The control unit or the gateway 20th supposed to be an event report 242 on a regular basis to the other IDS instance 34 send, preferably via a so-called heartbeat signal (cyclical signal, which is used to check that the Communication participants can be used). The heartbeat signal (including the event report 242 ) should be encrypted and authentic. The transmitted information should preferably be authentic (if necessary using the authentication information 256 ) and encrypted, preferably randomly or using a random number 273 between control unit or gateway 20th and the other IDS instance 34 be replaced. Preferably the event report should 242 a fixed length 257 should be encrypted and authenticated. Any encrypted event report 242 should differ from previous event reports 242 differ even if the transmitted status has not changed.

Communication from the other IDS instance 34 to the control unit or gateway 20th or the associated communication adapter 32 should also be characterized by the following functionalities. The data logger or the IDS instance 34 should be the events 236 or associated event reports 242 Read in as quickly as possible to avoid overflow, in particular of the memory or buffer memory 206 to prevent. The event reports 242 should be able to be read out via a diagnostic interface, for example on request. Alternatively, the event report 242 be sent completely cyclically. The event reports 242 should be communicated or read on a regular basis, preferably authentically and encrypted or camouflaged, even if there are no new selected events 226 as part of a new incident report 242 Are available. The control unit or gateway 20th should respond to a read request 240 with a response or an event report 242 answer with a fixed length, encrypted and authenticated. Any encrypted response or event report 242 should differ from previous responses or event reports 242 differ even if the content has not changed. This is exemplified by the constantly changing size 254 as already described.

According to 9 selects the event manager 30th first a first selected event 226.1 and then a second selected event 226.2 . These are handled by the event manager 30th processed as described. The selected events 226.1 , 226.2 are in memory 206 filed. The communication adapter 32 contains a signal 400 , a time-dependent interrupt signal (timer IRQ). Preferably the signal is time dependent 400 formed cyclically, so that an event report is sent cyclically 242 from the communication adapter 32 to other IDS instances 34 in the vehicle 18th is initiated. But even with no new events 226.1 , 226.2 a signal is generated as described below (in the form of a "normal" event report 242 ) from the communication adapter 32 to the other IDS instance 34 sent (compare signal 406 ). However, it is particularly preferred to send an event report 242 not depending on the receipt of an event 220 or selected event 226 triggered, but cyclically (due to the timing of the cycle time). This is particularly advantageous as the transmission to other IDS instances can also be carried out later 34 and / or the backend 36 always cyclically, i.e. after a certain time has elapsed. This is the behavior of the event manager for an attacker 30th or anomaly detection opaque. The attacker never knows whether his attack was detected, what was detected and how the anomaly detection system works.

After the communication adapter 32 the signal 400 (Timer interrupt), the communication adapter requests 32 an event report 242 from the event manager 30th on, signal 402 . The event manager 30th creates the corresponding event report 242 , of the previously selected events 226.1 and or 226.2 (with respective generic metadata 217 and event-dependent metadata 216 ) as well as a changed size 254 includes. Furthermore, corresponding fill data 255 added so the fixed length 257 of the event report 242 is achieved (with knowledge of the length of the authentication information still to be formed 256 ). The event manager also generates, for example 30th from the changed information 254 , the selected events 226.1 , 226.2 and the filling data 255 authentication information 256 using a certain algorithm. The authentication information thus formed 256 completes the event report 242 . The complete event report is then encrypted 242 with the key 258 . The encrypted event report 242 arrives as a signal 404 to the communication adapter 32 . Encryption (using the changed information 254 and / or the key 258 ) and authentication (formation of the authentication information 256 ) could be in the event manager 30th and / or in the communication adapter 32 take place when the corresponding safety requirements are met.

Alternatively, the communication adapter could 32 the event report 242 encrypt, for example, depending on a random number 273 . A new random number is always particularly preferred for encryption 273 formed, for example by hashing. This further complicates the decryption of a transmitted message or the encrypted event report 242 . If necessary, the communication adapter takes over 33 the authentication using the authentication information 256 and / or adding the variable size 254 and / or the final encryption of the entire event report 242 with the encryption 258 .

A corresponding signal 406 the timer interrupt (signal 400 ) sent even if there is no new event report 242 by occurrence of new selected events 226 from the event manager 30th is made available. Then a dummy message is created with the data format of an event report 242 used and by a random number or the constantly changing size 254 encrypted (using the key 258 ) to the other IDS instance 34 transfer. Even dummy messages are always changing sizes 254 or new random numbers are encrypted, so that even if new selected events do not occur 226 always cyclical other or encrypted messages (signal 406 ) be transmitted. As a result of the cyclical transmission, the functioning of a proper communication connection between the communication adapter 32 and the other IDS instance 34 to be checked.

After receiving the from the communication adapter 32 sent message (signal 406 ) by the other IDS instance 34 sends the other IDS instance 34 a confirmation signal ( 408 ) to the communication adapter 32 . After receiving the confirmation signal 408 generated by the communication adapter 32 a request to the event manager 30th , the cached, possibly reduced, selected events 226 or associated event reports 242 to be deleted or to be overwritten again (signal 410 ).

In an alternative exemplary embodiment, the higher-level entity checks 34 and / or the backend 36 the authenticity of the encrypted event report received 242 . To do this, the higher-level instance decrypts 34 and / or the backend 36 the received message, namely the encrypted event report 242 , using the known key 258 . Then there is the event report 242 available in plain text. Using the appropriate algorithm (also used by Event Manager 30th or communication adapter 32 to create the authentication information 256 was used) to form the authentication information 256 becomes the event report 242 authenticated. For this purpose, all data of the received and decrypted event report are used again 242 (with the exception of the authentication information 256 ) is used and a corresponding authentication information is obtained from it 256 ' educated. The generated authentication information is then compared 256 ' with the as part of the incident report 242 received authentication information 256 . If there is a match, the received event report applies 246 as authentic. Only after authentication has taken place can further data communication with the instance of the higher or lower level take place in this variant. The signal is only activated in this version if the authentication is successful 408 (Confirmation signal) to the communication adapter 32 sent the signal 410 to enable overwriting of the selected events 226.1 , 226.2 to the event manager 30th sent.

The answer or the confirmation signal should preferably also be 408 , 416 a fixed length 257 ' exhibit. The confirmation signal should preferably 408 be authenticated and encrypted. Every answer or confirmation signal 408 by the higher-level instance 34 and / or the backend 36 should differ even if the content has not changed.

An example of such a confirmation signal 408 , 416 is 9 refer to. The confirmation signal 408 , 416 is structured similarly to the event report 242 . The confirmation signal 408, 416 includes a variable size 254 ' . The changeable size 254 ' changes for each newly sent confirmation signal 408 , 416 . The changeable size 254 ' could again be implemented, for example, by a random number, a counter, a time.

The variable size could be particularly preferred 254 ' the confirmation signal 408, 416 can be formed by changing the size 254 of the event report 242 as just transmitted is used. This is the higher-level instance 34 , 36 , set up to change the size 254 from the received event report 242 to extract and in the confirmation signal 408 , 416 to insert. An authentication of the confirmation signal could thus also be carried out in a subsequent step 408 , 416 done by changing the received variable size 254 ' of the confirmation signal 408 , 416 is compared with the variable size 254 the event report that was just sent previously 242 . In the event of a match, an authentic confirmation signal 406, 408 is concluded. In addition, the variable size must be 254 'in the higher-level instance 34 , 36 cannot be generated by themselves. This can be used to release the memory 206 follow.

The confirmation signal also includes 408 , 416 certain dates 255 ' , for example in the form of any pattern. The confirmation signal also includes 408 , 416 authentication information 256 ' . The authentication information 256 ' could be similar to the event report 242 can again be formed using a specific algorithm that is based on the remaining data of the confirmation signal 408 , 416 , namely the variable size 254 ' as well as the data 255 ' falls back. The authentication information thus formed 256 ' completes the confirmation signal 408 , 416 . It has a fixed length 257 ' on. Encryption then takes place using a key 258 ' . This encryption could also be optional 258 ' be waived.

The receiving instances (for example, the parent instance 34 the backend 36 ) and / or the communication adapter 32 or the event manager 30th are in turn able to send the confirmation signal 408 , 412 to decrypt (using the key 258 ' ) and for authentication. For this purpose, the received data (variable size 254 ' , Data 255 ' ) using an appropriately known algorithm, the resulting authentication information 256 " determined and with the received authentication information 256 ' compared. If they match, authenticity is assumed. Provided the authentication information received 256 ' is okay, the signal could 410 to release the memory 206 be generated. Should be the authentication information 256 ' this signal could be out of order 410 are not generated, so those in memory 206 selected events contained 226 not (yet) deleted.

Also the other IDS instance 34 receives a timer interrupt signal cyclically 412 which is similar to the signal 400 is formed as already described.

On this interrupt signal 412 sends the other IDS instance 34 again an encrypted message, Signal 414 . This message includes the event report, if applicable 242 or a vehicle-related event report (including further event reports) such as via Signal 406 in front of the communication adapter 32 transmitted. Just like with the communication adapter 32 the message is sent by the further IDS instance 34 encrypted, especially due to a constantly changing size 254 ' such as a random number 273 . Should the communication adapter 32 no event report 242 because, for example, there was no new selected event 226 occurred, it is again a dummy message with the same data format as an event report 242 used and encrypted to the backend 36 transmitted (signal 414 ). The backend 36 sends a confirmation signal 416 and / or a further message or request to overwrite the in the buffer memory 206 cached events 236 or similar to the other IDS instance 34 . The confirmation signal 416 can be formed as described above.

After receiving the signal 410 The event manager selects the event release 30th further selected events 226.3 as 226.4 . The rest of the process can be 10 remove. In the meantime, the event manager selected 30th yet another event 226.5 . Another timer interrupt (signal 420 ) to the communication adapter 32 . This now calls for the gateway 20th an event report 242 on (signal 422 ). The event manager 30th sent to the communication adapter 32 an event report 242 on the selected events 226.3 , 226.4 , 226.5 based, signal 424 . After receiving the incident report 242 sends the communication adapter 32 by a new variable size 254 like a random number encrypted and authenticated event report 242 to the other IDS instance 34 , Signal 426 . The further IDS instance confirms receipt 34 by a confirmation signal 428 . The actuation signal 428 can be formed as in connection with actuation signal 408 ( 9 ) described. After receiving the confirmation signal 428 sends the communication adapter 32 again a request to the event manager 30th that the event report 242 underlying selected events 226.3 , 226.4 , 226.5 to overwrite or delete signal 430 . Between the sending of the signal 424 and receiving the signal 430 becomes another selected event in the meantime 226.6 selected. This selected event 226.6 however, it must not yet be overwritten because this selected event 226.6 not yet base for one already attached to the communication adapter 32 submitted event report 242 was. In this respect, the signal is related 430 does not care about the selected event 226.6 to overwrite, but only those selected events 226.3 , 226.4 , 226.5 to overwrite that already in the context of the last event report 242 were transmitted.

Again occurs at the other IDS instance 34 a timer interrupt on (signal 432 ) as already described. This becomes the further IDS instance 34 causes the in Signal 426 newly received event report 242 encrypted to the backend 36 to transmit, signal 434 . Receipt of the relevant message 434 acknowledges the backend 36 by a corresponding confirmation signal 436 , which is sent to the other IDS instance 34 is sent. The confirmation signal 436 could be formed like the confirmation signal 408 respectively. 416 .

The rest of the process is shown in 11 shown. Another timer interrupt occurs again for the communication adapter 32 on, signal 440 . The communication adapter then sends 32 a request to the event manager 30th to send an event report 242 , Signal 442 . The event manager 30th sends an event report 242 , of the event selected in the meantime 226.6 includes, signal 444 . The communication adapter 32 encrypts the event report 242 using a new variable size 256 and sends the encrypted event report 242 at the other IDS instance 34 , Signal 446 . The other IDS instance sends on receipt 34 an acknowledgment, signal 448 , upon receipt of the communication adapter 32 a request to the event manager 30th sends the events that have already been transmitted 226.6 to overwrite or release, 450 .

The other IDS instance receives again 34 a timer interrupt, signal 452 . This will bring up the encrypted event report 242 If necessary, together with further event reports from other IDS systems, vehicle-related to the backend 36 transmitted. The backend 36 sends to the other IDS instance (s) 34 a confirmation signal and / or a request to enable or overwrite corresponding events, etc., signal 456 .

In the exemplary sequence according to 12th is between the sending of the last event report 242 and the new occurrence of a timer interrupt (signal 460 ) no new selected event 226 occurred. After receiving the timer interrupt 460 sends the communication adapter 32 a corresponding request signal 462 for a new event report 242 to the event manager 30th . The event manager 30th generated - although a new selected event 226 occurred - an event report 242 with a dummy content, which is then sent to the communication adapter 32 is sent, signal 464 . This dummy content can be used by the other IDS instances 34 and / or from the backend 36 be recognized as such. The communication adapter 32 encrypts the received event report 242 , which has a dummy content, with a new, changed size 254 sends and sends the encrypted and authenticated event report 242 to the other IDS instance 34 , Signal 466 . The receipt is made by the further IDS instance 34 confirmed, signal 468 . When it is received, the communication adapter sends 32 another request signal to the event manager 30th , the last selected events 226 to overwrite, signal 470 . This happens even if there are no new selected events 226 as present in this constellation.

The other IDS instance is given again 34 a timer interrupt, signal 472 . The other IDS instance then encrypts it 34 the last encrypted event report received 242 as from the communication adapter 32 transmits it and sends it to the backend with further event reports from other IDS systems, if necessary, on a vehicle-specific basis 36 . The backend 36 sends a confirmation signal 476 and / or a request to release the underlying events etc. to the further IDS instance 34 .

In the communication sequence of the 13th the communication adapter receives 32 again a timer interrupt, signal 480 . With this timer interrupt 480 it may be a special signal so that the communication adapter 32 an event summary from the event manager 30th requests (and not one of the usual event reports 242 ), Signal 482 . The event manager 30th sends the event summary to the communication adapter 32 , Signal 484 . The event summary can contain higher-level information such as the various meter readings 231 for the different types of events 218 , or the occurrence of a new type of event, etc. Again, the event summary is also provided by the communication adapter 32 by a new variable size 254 encrypted like a random number and sent to other IDS instances 34 transmitted, signal 486 . As soon as the IDS instance 34 the encrypted event summary from the communication adapter 32 the other IDS instance sends 34 the event summary is particularly preferably encrypted to the backend 36 Further. In the exemplary embodiment, the transmission process is between the further IDS instance 34 and the backend 36 no timer interrupt provided to initiate the communication process. Alternatively, however, this could in turn be initiated cyclically as well as the transmission of a customary event report.

In the communication sequence of the 14th sends the backend 36 a request for an event report to the additional IDS instance 34 off, signal 490 . The other IDS instance 34 sends an encrypted request for an event report, for example via a diagnostic interface, to the communication adapter 32 , Signal 492 . The encryption can again have the changeable size 254 ' such as, for example, a random number that changes in particular for each encryption. After receiving the request 492 sends the communication adapter 32 a request for an event report 242 to the event manager 30th , Signal 494 . After receiving the relevant request 494 sends the event manager 30th the event report 242 to the communication adapter 32 , Signal 496 . The communication adapter 32 encrypts the event report 242 for example a new variable size 254 like a random number and sends it to the other IDS instance 34 , Signal 498 . Upon receipt of the encrypted event report 242 sends the other IDS instance 34 the event report 242 to the backend 36 . The 36 backend acknowledges receipt to the additional IDS instance 34 , Signal 492 . Receipt of the acknowledgment signal 492 confirms the other IDS instance 34 the communication adapter 32 , Signal 494 . After receiving the appropriate signal 494 sends the communication adapter 32 a corresponding request to the event manager 30th , at least as part of the last incident report 242 transmitted events 220 to be released or overwritten.

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

QUOTES INCLUDED IN THE DESCRIPTION

This list of the documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• DE 102018209407 A1 [0002]

Claims (14)

Method for treating an anomaly in data, in particular in a motor vehicle, at least one sensor (24, 26, 28) receiving data (211) for anomaly detection, the sensor (24, 26, 28) receiving the data (211) for anomalies and if an anomaly is detected, an event (220, 221) is generated as a function of the associated data (211), which is forwarded to an event manager (30), an event report (242) being generated as a function of the event (220, 221) , wherein the event report (242) is preferably received cyclically and / or encrypted and, after the event report (242) has been received, a confirmation signal (406, 412) is sent back. Procedure according to Claim 1 , characterized in that the confirmation signal (406,412) comprises at least one variable (254 ') variable for each confirmation signal (406,412) and / or at least certain data or patterns (255') and / or at least one piece of authentication information (256 ") . Method according to one of the preceding claims, characterized in that the confirmation signal (406, 412) always has a constant length (257 ') and / or is encrypted with a key (258'). Method according to one of the preceding claims, characterized in that the confirmation signal (406, 412) is sent cyclically. Method according to one of the preceding claims, characterized in that a confirmation signal (406, 412) is only generated or sent back if the received event report (242) has been classified as authentic. Method according to one of the following claims, characterized in that the sent event report (242) is decrypted. Method according to one of the preceding claims, characterized in that authentication information (256) contained in the event report (242) is used in order to classify the event report (242) as authentic. Method according to one of the preceding claims, characterized in that from data contained in the event report (242), in particular from the variable variable (254) and / or at least from at least one selected event (226) and / or at least from filler data (255) , authentication information (256 ") is formed which is compared with the authentication information (256) contained in the event report (242). Method according to one of the following claims, characterized in that a confirmation signal (408, 416) is sent when the generated authentication information (256 ') matches the received authentication information (256). Method according to one of the preceding claims, characterized in that after receipt of the confirmation signal (408, 416), a signal to enable or overwrite a memory (206) is triggered, in particular to overwrite at least one component of the last event report (242) sent. Method according to one of the preceding claims, characterized in that the authentication information (256) contained in the event report (242) is formed by at least one additional item of information (254, 226, 255) contained in the event report (242). Method according to one of the preceding claims, characterized in that the variable size of the confirmation signal (254 ') corresponds to the variable size of the event report (254). Method according to one of the preceding claims, characterized in that the event report (242) always has the same length (257) and / or is encrypted with a key (258). Method according to one of the preceding claims, characterized in that the event report (242) is also transmitted cyclically if no new event (220) has occurred since the last event report (242) was sent.

Images