JP2023519910A - Methods for handling data anomalies, especially in automobiles - Google Patents

Abstract

A method is proposed for handling data anomalies, in particular in motor vehicles, wherein at least one sensor (24, 26, 28) for anomaly identification obtains data (211) and sensors (24, 26, 28) examines the acquired data (211) for anomalies and if an anomaly is identified an event (220, 221) is generated depending on the relevant data (211) and forwarded to the event manager (30). , at least one trusted zone (Z2) and one untrusted zone (Z1) are provided, wherein at least one sensor (24, 26, 28, 40, 60) and the event manager (30) assigned to the zone (Z2) where

Description

The invention relates in particular to a method for handling data anomalies in motor vehicles.

PRIOR ART A device and a method for handling faults in communication networks, in particular in motor vehicle communication networks, are already known from DE 10 2018 209 407 A1. At least one detector analyzes a data stream in a communication network, the at least one detector providing control-based anomaly identification when at least one parameter for data packets of the data stream deviates from a target value. At least one anomaly is identified by the technique, and the at least one detector transmits information about the at least one identified anomaly via a communication network.

The automatic generation of protocols, histories and reports (logging), especially when anomalies or events are identified, may lead to high event rates and/or long-term attacks, overloading or Should be done without rejection. The logging or corresponding event report entry should be genuine, integer, and available. Where possible, a non-deterministic history for attackers should be created for complete (long-running) attacks. Unauthorized manipulation, especially deletion, by an attacker should be avoided. Outside the controller, logging entries should be protected from unauthorized analysis. Loggers should reliably send event reports to external nodes, eg, via an interface. After successful transmission to the external node, the event entry can be deleted locally, particularly preferably after confirmation specifically authenticated by the receiving instance. Additionally, the logger should send a so-called heartbeat signal indicating network connectivity. To reduce the number of logging entries to process, it should allow accumulation of events.

Under normal operating conditions, no or very few Events occur, for example, on the order of once per hour. In the worst case, an attacker can gain complete control over an interface, especially an Ethernet interface. For example, with a full bandwidth of 100 Mbit, an attacker can send up to 128,000 User Datagram Protocol (UDP) frames per second. Each such frame can also potentially trigger an event (an anomaly identified in the data stream). Such attacks are met with an attack frequency over the life of the vehicle. Memories, especially flash memories, have limits on the allowable number of so-called write cycles, which must be considered. Similarly, there are limits on the number of hours of operation that can be activated. Similarly, the availability of high-level external data loggers is also limited. Therefore, there is a need to temporarily store corresponding logging events or event reports. At least once a day, all logging entries or event reports should be forwarded to a superior data logger.

Conventional IDS systems and IDPS systems (Intrusion Detection Systems, intrusion detection units, systems for automatically identifying attacks on computer networks or computer interfaces, or IDPSs: Intrusion Detection Prevention Systems, intrusion attempts are identified) in some cases, the corresponding data is not transferred, thus thwarting the intrusion attempt), often deterministic behavior and limited resources of the embedded system are a problem.

DE 102018209407 A1

In contrast, it would be desirable to provide improved methods for anomaly identification. This problem is solved by the characterizing parts of the independent claims.

DISCLOSURE OF THE INVENTION This is achieved by the method according to the independent claims.

Further tamper protection is provided using a two-level security concept, in that at least one trusted zone and one untrusted zone are provided and at least one sensor and event manager are assigned to the trusted zone. be able to raise it. In particular, placing sensors and/or event managers as trusted instances within a trusted zone makes the possibility of access to sensitive data and the possibility of manipulation more difficult.

In an expedient development, at least one communication adapter can be arranged in the same zone as the event manager, the communication adapter being used for communication of event reports at least partially generated by the event manager. is assumed. This allows the communication adapter to inspect data transfers to other zones, while the communication adapter can communicate with the event manager and/or sensors within the security relevant zone.

In a sensible development, it is assumed that the communication adapter is also assigned to untrusted zones. It is through this part that communication with higher IDS instances, which typically represent untrusted instances, takes place.

In an expedient development, the sensors in the trusted zone contain at least data, in particular defragmented data, from sensors located in the untrusted zone, and the sensors in the trusted zone are The data is checked for anomalies, generating an event if an anomaly exists, and/or the sensor in the untrusted zone checks the acquired data for anomalies and generates an event if an anomaly exists. It is expected to generate an event. This ensures that only data absolutely necessary for further processing in the event manager reaches the trusted zone. This further reduces the possibility of tampering.

In an expedient development, sending the event report causes the communication adapter in the trusted zone to bring the event report into the memory of the untrusted zone where the communication adapter in the untrusted zone can access and send it. is assumed to be performed by In this way, secure data transfer from one zone to another can be guaranteed.

In an expedient development, it is envisaged that the event reports contain at least one size and/or at least one authentication information that varies for each event report and/or are encrypted by encryption. . This allows higher instances to check whether the data is authentic. In particular, it is expediently envisaged for this purpose that the authentication information is formed by further information contained in the event report.

In a sensible development it is envisaged that the security modules assigned to the trusted zones provide varying sizes and/or authentication information and/or encryption for each event report. This allows a secure, authentic and reliable connection to be made with the higher instance.

In an expedient development, it is envisaged that after sending the event report an acknowledgment signal is received, which is received by the communication adapter of the untrusted zone and forwarded to the communication adapter of the trusted zone. be. Via the acknowledgment signal, proper completion of transmission of the event report can be confirmed and further measures can be initiated, for example emptying memory.

In an expedient development, the confirmation signal has at least one size and/or at least specific data or pattern and/or at least one authentication information and/or at least one constant length which varies for each confirmation signal. and/or encrypted using encryption. Due to the variable size, the verification signal, especially after encryption, always looks significantly different to an attacker and is uninterpretable. An additional variable signal ensures updating. This is because it becomes impossible to go back to old event reports. Credentials ensure that the confirmation signal came from a true superior instance and was not generated by an attacker. This allows local event reports to be trusted and deleted.

In an expedient development it is envisaged that the communication adapter of the trusted zone decrypts and/or authenticates the received confirmation signal using a security module located in the security relevant zone. be. Further checks in the trusted zone further improve the security of the communication. In particular, expediently for this purpose, the received confirmation signal is decoded and/or It is assumed to be authenticated. It is therefore not necessary to generate a new variable size for the acknowledgment signal, but rather expediently by the security module within the trusted zone, especially sent together within the framework of the event report. A variable size may also be used for the confirmation signal.

In an expedient development, during the transmission of data from one zone to another, the sensor checks the data before use, in particular checks whether an event has occurred and/or , the data is assumed to be released for use in the other zone if no event is detected. This further reduces the possibility of tampering. In particular, for this purpose it is assumed that when an event occurs, the data is not transferred to the other zone and/or the sensor forwards the event to the event manager. .

In an expedient development it is assumed that the event manager and/or the trusted zone communication adapter and/or the trusted zone sensor and/or the security module are implemented on the computer core. This allows all security-related functions to be implemented on one computer core, which further increases security.

In an expedient development, at least one computing device is assigned a specific executable application program for one of the at least two zones, wherein the zone is responsible for executing the corresponding application program. and optionally at least one of the application programs is executed dependent on the zone assigned to it. The allocation of these zones and functions described above makes it possible to ensure that only security relevant functions are executed in the trusted zone. This can also preferably be done in that the method steps include the following steps: Exchanging first data between the various zones via a buffer memory, in particular a main memory. In this case, in particular, the step of exchanging the first data between the first zone and the second zone comprises: d1) transferring the first data to a first buffer memory area allocated to the first zone; d2) checking the copied first data, and in particular depending on said checking, d3) copying the first data to the first buffer allocated to the first zone copying from the memory area to a second buffer memory area allocated to the second zone. This ensures that the secure data exchange between the zones proceeds favorably.

Further preferred arrangements will become apparent from the following description and drawings.

FIG. 4 is a schematic diagram of the components of the intrusion detector; FIG. 3 illustrates an exemplary structure or interaction of received data, events derived therefrom, structure of associated selected events and event reports. Fig. 3 is a simplified schematic block diagram of aspects according to a further preferred embodiment; Fig. 3 is a simplified schematic block diagram of aspects according to a further preferred embodiment; Fig. 3 shows different communication flows between the event manager, communication adapters, further IDS instances and the backend; Fig. 3 shows different communication flows between the event manager, communication adapters, further IDS instances and the backend; Fig. 3 shows different communication flows between the event manager, communication adapters, further IDS instances and the backend; Fig. 3 shows different communication flows between the event manager, communication adapters, further IDS instances and the backend; Fig. 3 shows different communication flows between the event manager, communication adapters, further IDS instances and the backend; Fig. 3 shows different communication flows between the event manager, communication adapters, further IDS instances and the backend;

In relation to aspects of the embodiments below, deviations from normal operation that may occur for various reasons in actual operation, particularly in network system data 211 (e.g., communication system data or system data), are as follows: is called an anomaly. The causes may be of the following types, for example: erroneous or completely missing data supplied by faulty or completely failing sensors, damaged system components, A system that has been manipulated not only externally but also by local or physical attacks (for example, hacker attacks) can be considered.

The identification of anomalies in data 211 is performed using so-called "Intrusion Detection Systems", IDS or IDPS. IDS hereinafter refers to a system that monitors data 211 for anomalies. In this case, for example, the data 211 may be data connections within a communication network with which the control device 20, for example a gateway, communicates over different communication channels (eg, via the bus system 25 or the like or the Internet 27). However, other data 211 as well, for example system data inside the controller (or host 29 or microcontroller located therein, or processor inside the chip) should be checked for anomalies by this IDS system. be. Detection of anomalies in data 211 is accomplished by appropriate sensors 24,26,28. These sensors 24, 26, 28 are adapted to respective sources of data 211 (bus systems 25, 27 or host 29 in this example).

According to FIG. 1 a control device, for example a gateway 20 , is arranged in a vehicle 18 . Controller or gateway 20 includes a processor, memory, working memory (eg, as a component of host system 29), and an interface for communication via a communication network. Gateway 20, for example, processes instructions for data connections. Due to communication, data 211 occurs in the form of data packets. Data 211, for example system data, also occur during operation of the host 29. FIG. Under normal conditions, target values are maintained, for example, with respect to receive and destination addresses, adherence to proper program flow (eg, for host 29), time stamps, frequency of occurrence or frequency of data 211 in a particular data packet. . The data packets data 211 are exchanged between further controllers or components within the vehicle 18, not shown in more detail, to fulfill specific tasks. The gateway 20 is used to combine multiple communication systems or interfaces such as, for example, a CAN bus 25, an Ethernet connection 27, and a data connection to a host system 29 that is a component of the controller 20 or gateway. However, other communication systems (eg further wired bus systems such as LIN, CAN-FD or wireless networks (eg WLAN or Bluetooth)) can also be coupled to each other by the gateway 20 for the purpose of data exchange. In general, an intrusion identifier IDS or anomaly identifier in the control device will process all data 211 (data 211 received by the communication system and data 211 generated by the host 29 inside the control device 20) into the corresponding anomaly used to monitor In this embodiment, the IDS function mechanism for gateway 20 is described by way of example. However, the described functionality of the anomaly identifier or intrusion identifier IDS can generally be implemented in any controller or any electronic component. In particular, use is not limited to vehicles 18 . Rather, any communication component, for example a communication module within the Internet of Things (IOT) or a communication module in a networked production system, can be provided with the described functionality.

A communication component such as a controller or gateway 20 includes at least one anomaly detector 22 . This anomaly detector 22 extends over at least one unreliable zone Z1 and over at least one reliable zone Z2. In particular, communication adapter 32 resides in both trusted zone Z2 and untrusted zone Z1. At least one sensor 24, 26, 28 is present within the trust zone Z2. The event manager 30 also resides within the trusted zone.

The data 211 arriving via the interface of each communication system 25, 27, 29 are respectively guided via sensors 24, 26, 28 (abbreviated IDS sensors) for so-called anomaly or intrusion detection. Corresponding sensors 24 , 26 , 28 are therefore arranged in the gateway 20 . Such sensors 24, 26, 28 are used to identify whether the acquired data 211 indicates an anomaly. To this end, stored in these sensors 24, 26, 28 are corresponding filter algorithms or control sets that are used to identify and classify anomalies. When an anomaly is identified by the sensors 24, 26, 28, the corresponding data packet of data 211 is classified as an event 220 (of attempted intrusion). In general, these sensors 24, 26, 28 are capable of classifying different anomalies as events 220 (assigning each event 220 to a particular event type 218) depending on the source 25, 27, 29 and identifying can be done. Depending on each event type 218 (a different type of anomaly in data 211 ), sensors 24 , 26 , 28 organize specific event-dependent metadata 216 into associated events 220 . Additionally, event-dependent metadata 216 may also include data or data components of anomaly data 211 . Events 220 so generated are forwarded to event manager 30 . These sensors 24, 26, 28 are normally arranged to transfer the relevant data 211 of the communication system (eg bus system 25, 27) to a specific address if no fault has occurred. Sensors 24, 26, 28 can also be configured such that relevant data 211 of the communication system (eg bus systems 25, 27) are not transferred to a specific address if an anomaly is identified. Alternatively, sensors 24, 26, 28 can also be used to reduce event 220 (reduced event or pre-reduced event 221). This reduction allows the event manager 30 to be less burdened, for example, by transferring only the data 211 containing the anomaly or the valid data part of the data packet. This is particularly advantageous for large amounts of data, such as occur with Ethernet connections.

For example, IDS CAN sensor 24 is used for fault identification in case of CAN bus 25, IDS Ethernet sensor 26 is used in case of Ethernet system 27 and IDS host sensor 28 is used in case of host system 29. . Further IDS sensors may also be provided that are able to detect and possibly classify anomalies at their respective sources or sources of anomalies, depending on different communication paths and different communication protocols.

The IDS CAN sensor 24 detects associated events 220 of associated event types 218 such as, for example, invalid CAN-ID, invalid message frequency, invalid message length. IDS Ethernet sensor 26 detects Ethernet 27 related events 220 from associated event types 218 such as, for example, invalid address or MAC address, invalid message frequency, invalid message length. IDS host sensor 28 detects events 220 associated with host system 29 from associated event types 218 such as, for example, invalid code execution, program corruption, staple counters, and the like. At least one sensor 24, 26, 28 is located within the trust zone Z2.

Further subsequent anomalies can be considered for further event types 218 as events 220 . For example, these include frame loss based on full buffer memory, filter violations (stateless/stateful), transmission rate limiting activation/deactivation, monitor mode activation/deactivation, context changes, firewall is an event 220 or event type 218 that can be assigned to. Further anomalies related to the host system 29 are also e.g. CPU load too high, memory access violation, code runtime error, ECU reset detected, log entry corruption in non-volatile memory, logging memory overflow, event rejection, MAC address It can be considered as an event 220 with an associated event type 218, such as port change.

The event manager 30 is used for subsequent processing of incoming events 220 or event dependent metadata 215 contained in each event 220 . In particular, event manager 30 aggregates, formats or prepares events 220, and/or prioritizes and/or reduces and/or selects events 220, and/or processes selected and/or reduced events. 220, 221 are used to store or perpetuate or permanently store them. In particular, the event manager 30 determines which incoming events 220 should be processed further. Those selected from the incoming events 220 are referred to as selected events 226 . The corresponding selection should be made as non-deterministic as possible. Furthermore, the event manager 30 causes incoming events 220 or selection events 226 to be more particularly preferably provided with further generic metadata 217 . Events 220 transmitted from different sensors 24 , 26 , 28 can thereby be superordinated by adding, for example, the number of events that occurred, the associated timestamp or time signal 224 , within the framework of generic metadata 217 . It is possible to observe Furthermore, it is guaranteed that a sufficiently large number of testimonial events 220 can be stored as selected events 226, even in the case of so-called event bursts. The event manager 30 is located within the trusted zone Z2.

The event manager 30 exchanges signals with the communications adapter 32 of the intrusion identifier or anomaly identifier. This communication adapter 32 serves as communication means for exchanging data between the event manager 30 and further components 34 , 36 external to the fault identifier 22 of the controller or gateway 20 . Specifically, the communication adapter 32 exchanges data between the event manager 30 and a further IDS instance 34 (preferably internal to the vehicle 18) and/or a backend 36 (preferably external to the vehicle 18). It functions as an interface for Further IDS instances 34 may also be provided only optionally. The communication adapter 32 is arranged in two zones Z1 and Z2.

To enhance security, the event manager 30 can perform randomized reduction and prioritization of events 220, 221 that are non-deterministic and hidden from attackers. As such, non-volatile storage of selection events 226 can be done in a random fashion, non-deterministic and transparent to an attacker. Randomly controlled selection can be based, for example, on an individual random number 273 for a particular controller. Similarly, event manager 30 may provide random storage of counter state 231 of event counter 204 . In addition to event dependency metadata 216 , event manager 30 also stores random dependencies for generic metadata 217 added as selected events 226 .

Communication adapter 32 may upload or transmit event reports 242 to other IDS instances 34 in a random fashion, non-deterministic and hidden from attackers, to enhance security. Random controlled uploads can be based, for example, on an individual random number 273 for a particular controller (or gateway 20). Certain events 220 can thus be transmitted periodically and encrypted within the framework of the event report 242 . However, even in the absence of new events 220 , so-called dummy events can be periodically encrypted and transmitted in the format of the event report 242 . This is used for eavesdropping security or randomized concealment of data exchanges between the communication adapter 32 and the further IDS instance 34 or backend 36 .

Processed and reduced events 221 are forwarded from sensors 26 to event manager 30 . Therefore, the event manager 30 does not get the full data stream of these netframes from this sensor 26, but only the reduced events 221 with reduced data size. The reduction of events 221 to be forwarded has been exemplarily described on the basis of the IDS Ethernet sensor 26 . However, in principle this can be implemented in other IDS sensors 24,26,28. However, due to the large amount of information in Ethernet frames with high transmission rates, especially such an event 220 can lead to rapid overflow of the buffer memory 206 . Since in the IDS CAN sensor 24 the corresponding data 211 occurs anyway at a lower data rate and less data volume, here tendingly complete events 220 can be transferred and stored.

By way of example, with reference to FIG. 2, how data 211 from sensors 24 , 26 , 28 is further processed when an anomaly is identified and sent to event manager 30 via communication adapter 32 to event report 242 . will be sent until you send the .

By way of example, in FIG. 2a it is shown how a data packet of data 211 can occur, for example, in a network frame (eg CAN, Ethernet). The data 211 has a header 214 containing, for example, a source address and a destination address (eg MACa, MACb). Additionally, data 211 includes valid data 213 .

Sensors 24 , 26 , 28 may optionally randomly select valid data areas 219 to be transferred to event manager 30 , as described in more detail below. Sensors 24, 26, 28 identify anomalies according to a particular event type 218 (event-ID or event-ID, ID). Therefore, the sensors 24, 26, 28 generate event-dependent metadata 216, as shown in Figure 2b. Depending on the event type 218 (or ID), different anomaly information may be stored in the event dependency metadata 216 . In this embodiment, the event-dependent metadata 216 is used, among others, the source and destination addresses (MACa, MACb), the event type 218 and the selected valid data field 219 .

Alternatively, the event-dependent valid data 213 can also be transferred to the event manager 30 within the framework of the event 220 as a whole.

Alternatively, event 220 may not include event dependent valid data 213, for example if host 29 is used as a source. In this case, the event type 218 can be, for example, data frame loss due to full buffer, observation mode activation or deactivation, CPU too high load, non-volatile memory 208 corrupt entry, logging buffer overflow , the activation of event reduction, and the like.

Additionally, for different event types 218 , additional event dependency information may be a component of event 220 within event dependency metadata 216 . For event type 218 “context change”, event dependency metadata 216 may include, for example, a context of size 32 bits, for example. For event type 218 "memory access violation" or "code execution violation", event dependency metadata 216 may be, for example, accessed address (eg, 32 bits), program counter (eg, 32 bits), task It may contain an ID (eg 8 bits). For event type 218 "Control Unit Detected Reset", the event dependency metadata 216 may include, for example, the reason for the reset (e.g., 8-bit), e.g., Point of Return (POR), software reset, exception, etc. can include

Subsequent Ethernet-related events 220 are documented as event dependent metadata 216, e.g. Filter control ID that triggered event 220 if possible, physical port address, physical port ID from which the frame was captured, source address (e.g. MAC address, e.g. 48 bits), destination address (e.g. MAC address, e.g. 48 bits). , possibly the IP address of the source or destination, optionally determining the UDP/TCP port (eg 16 bits) if present in the frame, etc.). Alternatively, static/state dependent filter violations, e.g., Control ID, Physical Port, Frame (Number of Bytes), Specific Bytes of Stored Received Frames, Selected Valid Data Area 219 (Specific Bytes number), the selected valid data area 219 of the bytes of the original frame, the valid data area 219-index (eg 16 bits), the starting byte of the selected valid data area 219 within the original frame, etc. can also be protocolized. Also, for further Ethernet related events, e.g. event type 218 "transmission rate limit (activate/deactivate)", the control ID with the associated ID of the filter control that caused the event 220, event type 218 "context change for event type 218 "address hopping" or "MAC hopping", old port (physical port ID originally assigned to the address), new port (the address was recently observed physical port ID), an address, preferably a MAC address, etc. may be included in the event 220 transmitted to the event manager 30 . However, event types 218 without metadata 216 can also occur, such as "frame loss due to full buffer".

Therefore, the transfer of event-dependent valid data 213 depends, among other things, on the source of data 211 that has an associated event type 218 . Metadata 216 is transmitted to event manager 30 as event 220 or reduced event 221 (based on random dependency selection or reduction of valid data areas 219 to be transmitted at sensors 24, 26, 28).

If the event manager 30 should select this event 220, 221 for further processing (selection event 226), as described in more detail below, to the event dependency metadata 216 Further generic metadata 217 is added, resulting in metadata 215 shown in FIG. 2c. This generic metadata 217 is typically generated at the event manager 30 . They are, for example, the output signals of the event counter 204, ie the current counter state 231, the number of global events 220 or the number of events of the event type 218 to which the current event 220 relates. Additionally, generic metadata 217 may include, for example, a time signal 224 as to when this event 220 occurred. Additionally, metadata 217 may also include what length 232 (size of data) the event-dependent metadata 216 or complete metadata 215 has. This is advantageous for subsequent memory management of buffer memory 206 .

Exemplarily, the following generic metadata 217 is proposed. This may be, for example, the event type 218 within the framework of the event ID (eg, 8 bits). The event ID of this event type 218 is unique and may include, for example, a TLV (Type-Length-Value) based encoding. This generic metadata 217 includes a length 232 of size, for example, between 8 and 16 bits. The size of the data (metadata 215) is up to 255 bytes according to the length unit of bytes. Again, TLV-based encoding can be assumed. Also included is a time signal 224, a time stamp (eg 64 bits). This time 224 is provided, for example, in the form of an absolute time value that has elapsed (in milliseconds) since a reference point in time, such as January 1, 1970, to indicate a unique time stamp. Additionally, generic metadata 217 may include counter state 231 or output value 231 (eg, 32 bits) of event type counter 204 and/or counter state 231 (eg, 32 bits) of global (event) counter 204, It may contain the sum of all counter states 231 of event counter 204 .

Event dependent metadata 216 is captured as produced by each sensor 24 , 26 , 28 . This event 220 with corresponding metadata 215 formed both by the sensors 24 , 26 , 28 and by the event manager 30 is stored in the buffer memory 206 of the event manager 30 . Further events 226 (exemplarily indicated by 215_1, 215_8, 215_190 in the example according to FIG. 2d) that are also selected or reduced by the event manager 30 (as explained in more detail below) in a similar manner. are also stored in the buffer memory 206 .

215_1, 215_8, 215_190 in the example according to FIG. .8, indicated by Event No. 190) in metadata 215), here an event report 242 is generated. This report includes selected events 226 (215_1, 215_8, 215_190 in this example) stored in buffer memory 206 . These selection events 226 are preceded by a modified size 254 (eg, random number, time or counter, etc.) for each event report 242 . Additionally, event report 242 includes authentication information 256 . In this regard, this authentication can occur between the communication adapter 32 or event manager 30 and the unit (IDS instance 34, backend 36, etc.) receiving the event report 242. FIG. This event report 242 contains a fixed length 257 . To achieve this fixed length 257, the data 254, 215_1, 215_8, 215_190, 256 are further padded with so-called padding data 255; These fill data 255 do not contain event-related information. Prior to transmission, the illustrated data of event report 242 undergoes encryption 258 as shown in Figure 2d. Event reports 242 encrypted by such encryption 258 are transmitted by communication adapter 32 and decrypted and authenticated by further IDS instance 34 or backend 36 as described.

Figure 3 schematically shows a computational core 102a of a switch SWT 48 according to a further preferred embodiment, which contains the operating system BS and/or the supervisor SV and is itself allocated to two zones Z1, Z2. .

The anomaly identifier 22 is based on a two-zone concept in which a particular application is assigned to an untrusted zone Z1 and a trusted zone Z2. The anomaly identifier 22 can be used in particular, for example, for embedded systems and/or control devices, especially for vehicles, especially for automobiles.

A preferred embodiment relates to a method for operating a computing device assigned to the anomaly identifier 22, the method comprising the following steps: one or more application programs executable by the computing device; assigning AP1, AP2 to one of at least two zones Z1, Z2, where zones Z1, Z2 characterize the resources of the computing device, the resources being the corresponding application programs AP1, AP2; and optionally executing at least one of the application programs AP1, AP2 depending on its assigned zone Z1, Z2; in which case the method alternatively further comprises the step of using the supervisor SVs for allocation of computing time resources for different application programs and/or instances of application programs , where the supervisor SV and/or the functionality corresponding to the supervisor SV are at least partially realized using at least two zone Z1, Z2 independent supervisor instances SVI. In a further preferred embodiment, this allows eg Trust Boundaries to be defined between eg trusted and untrusted instances/units/domains. In this way, for example, a first application program for computing devices is assigned to a first non-trustworthy zone Z1 (non-trustworthy zone, NT) and a second application program for computing devices is assigned to a trusted second zone Z1. 2 zone Z2 (trustworthy zone, (T)Z). In further preferred embodiments, the supervisor instance SVI may for example be formed by a (dedicated) computational core and/or a hardware security module HSM and/or a trusted platform module TPM, or the supervisor instance SVI can be realized using at least one of these elements.

In a further preferred embodiment, a method for operating a computing device includes the following elements: a) read rights to memory allocated to the computing device; b) write rights to memory allocated to the computing device; c) it is envisaged to further comprise the step of controlling, in particular restricting, at least one of the execution rights ("execution rights") to the memory allocated to the computing device, depending on at least one zone Z1, Z2; be. This preferably ensures that only application programs AP assigned to the corresponding zones Z1, Z2 receive access to one or the aforementioned memories. For example, this allows, in a further preferred embodiment, an application program in the untrusted zone Z1 to access one or more memories (in particular, for example a trusted memory area allocated to the trusted zone Z2). access by untrusted zone Z1, etc.), which possibly represents a risk regarding possible manipulation of memory contents by application programs of untrusted zone Z1.

In further preferred embodiments, the computing device is capable of executing, for example, the following scenarios. That is, the first application program AP1 receives, for example, data from the untrusted first zone Z1 (for example, a remote service request from the Internet (“remote service inquiry”)), and converts these data to , for the execution of the corresponding service (“Remote Service”), the data is to be processed or transferred accordingly within the trusted zone Z2 by the Z1-proxy AP1_I1 of the application program AP1 within the first zone Z1. Receiving takes place, where the corresponding Z2-Proxy_I2 performs, for example, the following steps: data verification of data that has been classified as untrustworthy by Z2-Proxy_I2, especially in the default manner, and (data Perform the step of processing or forwarding the data now (after data verification) rated as trustworthy in the second zone Z2 (in case of successful verification). In a further preferred embodiment, it is envisaged that the method further comprises the step of exchanging first data between the various zones via a buffer memory, in particular a main memory, wherein In particular, the step of exchanging the first data between the first zone Z1 and the second zone Z2 comprises the following steps: 1 buffer memory area; checking the copied first data; to a second buffer memory area allocated to the second zone Z2. These briefly outlined functions of the two-zone concept are implemented here for anomaly identifier 22, as described below.

A computing core 102a according to FIG. 3 can be used, for example, for a network switch, for example to transmit and/or receive Ethernet data packets. The corresponding instances of the application program AP are referenced I1 (receiving Ethernet packets, running in zone Z1), I2 (receiving Ethernet packets, running in zone Z2), I3 (sending Ethernet packets, running in zone Z1). execution), I4 (transmission of Ethernet packets, execution in zone Z2). For example, a further application program AP5, which performs administrative tasks for the network switch 48, runs only within the second zone Z2 defined as trusted and within the first zone Z1 defined as untrusted. is not executed in Furthermore, the Ethernet sensor 38 is located within a first zone Z1 defined as untrusted. A further Ethernet sensor 40 is arranged in a second zone Z2 defined as trusted. Additionally, the host sensor 42 is located within a first zone Z1 defined as unreliable. An untrusted zone Z1 host sensor 43 may optionally be provided. The host sensor 45 is located within a second zone Z2 defined as trusted. That is, depending on the application case, the sensor can be placed in the trusted zone Z2 and/or the untrusted zone Z1.

Compute core 102a is allocated RAM 1030, which may be partitioned in further preferred embodiments. Optionally, a switching engine (eg a coupling network) and/or a ternary content-addressable memory (TCAM) module or an Access-Control-List (ACL) module are provided. A switching engine SE or TCAM/ACL module is a hardware module 42 . Within the TCAM/ACL module, corresponding filter rules can be configured, so that the TCAM/ACL module is used as a sensor to detect anomalies. Correspondingly configured filter rules in this hardware module 42 correspond to the filter rules of the sensors 24, 26, 28 described. If an anomaly is detected by this filter rule, an event 220 can be generated and/or the anomaly can be blocked. If an event 220 is generated, an interrupt can be triggered by the hardware module 42, allowing the anomaly to be logged as an event 220 in software. The same applies to the CAN hardware transceiver on the main controller, where the sensor's filter rules can be configured in hardware.

Also shown is an interrupt 44, which can be triggered, for example, by software, by hardware, or by a timer, as described above. The above parts are components of an electronic unit 48 or switch. External to the electronic unit 48 or switch is a computing unit 100b (main controller), which exchanges data with the electronic unit 48 or switch via a communication channel 52 . Additionally, the computing unit 100b can communicate with other IDS instances 34 . This communication can be, for example, from the computing unit 100b to the other IDS instance 34 via CAN, or from the computing unit 100b to the other IDS instance 34 via the switch 48. FIG. Electronic unit 48 again sends an Ethernet event 220 from switch SWT 48 to computing unit 100b.

Inter-zone communication from untrusted zone Z1 to trusted zone Z2 is via ETH sensor 40 in trusted zone Z2 and/or via sensor 42 implemented by hardware filter rules and/or It is controlled by the ETH sensor 40 in the untrusted zone Z1 and/or by the host sensor 45 in the trusted zone Z2.

If an inter-zone communication or zone transition from Z1 to Z2 occurs on switch 48, only the bare minimum of data required in trusted zone Z2 is transmitted between the two zones Z1 and Z2.

Therefore, within the untrusted zone Z1, protocol defragmentation has already been carried out to the bare minimum, and within the framework of defragmentation, a plausibility check (for detection of anomalies) has also already been carried out. there is This is done via the Z1 Ethernet sensor 38 .

After the bare-bones data has been transmitted from the untrusted zone Z1 to the trusted zone Z2, the bare-bones data is validated by the Z2 Ethernet sensor 40 . Before each context change/Z1 task and Z2 task switch, additionally via the BS or SV host sensors 43, 45 it is checked whether invalid zone transitions and/or program flow changes have occurred. (eg, by examining the return address on the stack).

If no anomalies are detected, the ETH sensor 40 in trusted zone Z2 releases the data in trusted zone Z2 for use. These data are rated as trusted data (Trusted Data). If an anomaly is detected, ETH sensor 40 discards the data and/or generates event 220 . Additionally, the ETH sensor 40 communicates anomalies or related events 220 to the computing unit 100b of the trusted zone Z2 or the related event manager 30 of the trusted zone Z2. The sensor logic of ETH sensor 40 is within trusted zone Z2. This is because events must be evaluated by trusted instances.

Communication within zones Z1, Z2 or from trusted zone Z2 to untrusted zone Z1 may optionally be performed using ETH sensor 38 for untrusted zone Z1. In addition, these sensors are optional for inter-zone and intra-zone communication from Z2 to Z1, and in some cases a reduced sensor set can be used for this purpose ( For example, a default sensor that has less impact on performance).

Switch 48SWT forwards the communication of computing unit 100b of untrusted zone Z1 to further IDS instance 34 via communications adapter 32 . The communication adapter 32 resides within the computing unit 100b. The communications adapter periodically queries event reports 242 from event manager 30 and communicates them to further IDS instances 34 . If the communication to the further IDS instance 34 is via Ethernet (which is the preferred variant), this communication is from the communication adapter 32 of the main microcontroller or computing unit 100b via the switch 48 to the further IDS instance 34. It will be made to the IDS instance 34 .

FIG. 4 schematically shows a simplified block diagram of aspects of computing device 100b according to a further preferred embodiment. The computing device 100b, according to the invention, illustratively has four computing cores K1, K2, K3, K4, of which the first computing core K1 processes communication messages, in particular CAN messages. is configured as Therefore, in a further preferred embodiment, this first computing core K1 can also be referred to as a "CAN core". Further computational cores K2, K3 are provided for running application programs (possibly different instances), hence in a further preferred embodiment "application cores" or in English "Application Cores" K2, It can also be called K3. The fourth computational core K4 is configured to process Ethernet communication messages and can therefore also be referred to as Ethernet core or ETH core or English designation "ETH Core" K4 in a further preferred embodiment. . A first computational core K1 is assigned a first supervisor SV1, in particular a CAN lightweight supervisor, and a fourth computational core K4 is assigned a second supervisor SV2, in particular an ETH (Ethernet) lightweight supervisor. .

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

In a further preferred embodiment, the first computing core K1 is assigned an application program AP for transmission and/or reception of CAN messages, the reference I1 being the first instance, this first instance I1 is assigned to the first zone Z1 and is configured to receive CAN messages. Correspondingly, reference I2 denotes a second instance of this application program, which is assigned to the second zone Z2 and is adapted to receive CAN messages. Reference signs I3, I4 denote corresponding instances for transmitting CAN messages, each of which is likewise assigned to one of the two zones Z1, Z2. Furthermore, the computing core K1 may include a CAN sensor 60 arranged within the trusted zone Z2. Optionally, a CAN sensor 62 in the untrusted zone Z1 may be provided in the computational core K1.

In a further preferred embodiment, interrupt requests Rx, timers, SW can be processed by the first computing core K1, for example by executing corresponding interrupt routines.

In a further preferred embodiment, the fourth computational core K4 is assigned an application program for sending and/or receiving Ethernet messages, reference I1 being the first instance of this application program. , this first instance I1 is assigned to the first zone Z1 and is configured to receive Ethernet messages. Correspondingly, reference I2 denotes a second instance of this application program, which is assigned to the second zone Z2 and is adapted to receive Ethernet messages. References I3, I4 denote corresponding instances for transmitting Ethernet messages, each of which is likewise assigned to one of the two zones Z1, Z2.

In a further preferred embodiment the separation of the two zones Z1, Z2 within the computational cores K1, K4 is performed using at least one memory protection device SSE1, SSE4 respectively.

As already mentioned above, the two application cores K2, K3 are configured to execute application programs, which application programs or their respective instances are represented as rectangles within the respective application cores K2, K3. It is shown. In a further preferred embodiment, the second computational core K2 is assigned to the second zone Z2 and the third computational core K3 is assigned to the first zone Z1. Within the compute core K2 are illustratively DPI sensor 64 (deep package inspection for more detailed payload analysis), event manager 30, communication adapter 32, proxy 70, BSW stack 72 (BSW: Basis Software), V - CAN 74 (virtual CAN) and V-ETH 76 (virtual Ethernet) are provided. A DPI sensor 84, a communication adapter 32, a proxy 90, a BSW stack 92, a V-CAN 94 and a V-ETH 96 are illustratively provided in the computational core K3. As already explained, the communication adapter 32 exists in both the trusted zone Z2 and the untrusted zone Z1.

In a further preferred embodiment, the computing device 100b has a volatile memory, in particular a main memory (RAM) 1030b, which is for example divided into comparably different areas in the depiction according to FIG. 4, these areas being , respectively assigned to different computational cores K1, K2, K3, K4 or their zones Z1, Z2.

For example, the first area B1 of the main memory 1030b of the computing device 100b according to FIG. 4 is assigned to the first computing core K1, in this case the first partial area B1_1 is assigned to the first zone Z1, A second partial area B1_2 is assigned to a second zone Z2. The first partial area B1_1 is again divided into trusted and untrusted areas, separated by a memory protection device SSE. The second partial area B1_2 is again divided into at least one trusted and untrusted area, again separated by a memory protection device SSE. A comparable division into corresponding areas or sub-areas B4, B4_1, B4_2 is also possible for the fourth computational core K4 in a further preferred embodiment. The first partial area B4_1 is again divided into a trusted area Tb1b and an untrusted area Tb1a, separated by a memory protection device SSE. The second sub-region B4_2 is again divided into at least one trusted region Tb2a and an untrusted region Tb2b, again separated by a memory protection device SSE.

Further areas B2, B3 of the main memory 1030b can be allocated, for example, to application cores K2, K3 in a further preferred embodiment. In a further preferred embodiment, for example, the area B2 can be subdivided into a trusted area T and an untrusted area NT. In a further preferred embodiment, the same applies comparably for the third application core K3.

In a further preferred embodiment, one or more further memory protection devices, collectively denoted by the reference SSE', are provided according to preferred embodiments, for example with respect to read and/or write and/or execute rights. It may be provided to achieve separation of each.

In a further preferred embodiment, the computing device 100b functions for example as a gateway, i.e. as a network coupling element capable of coupling for example a CAN bus (see CAN core K1) to an Ethernet network (see ETH core K4). can be provided. In a further preferred embodiment, for example, the first computational core K1 can take over the function of a so-called fast routing engine for CAN messages and/or the fourth computational core K4 can serve as a so-called fast routing engine for Ethernet messages. It can assume the function of a so-called high-speed engine for

The SWT48 switch, especially the Ethernet switch, transmits Ethernet events to the compute core K4, which is responsible for processing Ethernet communications. Additionally, compute core K4 communicates with other IDS instances 34 .

In inter-zone communications, specifically communications from untrusted zone Z1 to trusted zone Z2, data can be pushed from the proxy 90 of untrusted zone Z1 to a separate buffer memory within the untrusted area of zone Z1. can. Sensors 60 assigned to trusted zone Z2 validate this data prior to use within trusted zone Z2. As long as no anomalies are detected, the sensors 60 of the trusted zone Z2 release their data for use to the trusted zone Z2 (Trusted Data). Sensors 60 assigned to trusted zone Z2 discard these data as long as an anomaly or an unexpected event is detected. Additionally, sensors 60 assigned to trusted zone Z2 communicate detected anomalies as events 220 to the event manager of trusted zone Z2. The logic of sensor 60 is located within trusted zone Z2. This is because the corresponding event must be evaluated by a trusted instance. Furthermore, communication can take place between the trusted zone Z2 and the untrusted zone Z1. In addition, communication from the trusted zone Z2 to the untrusted zone Z1 can also be easily performed. Additional sensors 62 may optionally be provided.

Communication from the untrusted zone Z1 to the trusted zone Z2 can also be monitored by sensors in the untrusted zone Z1 and in the trusted zone Z2, as already explained. Data that no longer exist after defragmentation or are no longer needed within the trusted zone Z2 are monitored by sensors 38, 62 located within the untrusted zone Z1. The sensors 40, 60 located in the trusted zone Z2 then monitor the data transmitted from the untrusted zone Z1 to the trusted zone Z2 after defragmentation. If something has already been detected by the sensors 38, 62 in the untrusted zone Z1, similarly the sensors 38, 62 located in the untrusted zone Z1 and the event manager 30 located in the trusted zone Z2 within the framework of the generated event 220, for example.

The event manager 30 of the trusted zone Z2 aggregates, reduces, prioritizes, formats, or persists incoming events 220 . The event manager 66 is located within the trusted zone Z2. This is because events must be processed, prioritized and stored by Trusted Instances.

Communication adapter 32 is partially located within trusted zone Z2. Communication adapter 32 controls communication with event manager 30, which is also located within trusted zone Z2. Additionally, the communications adapter 32 communicates with an HSM (Hardware Security Module, which can be used for authentication and/or encryption) to ensure a secure, authenticated, and confidential channel to the upper IDS instance 34. in charge of communication. Communication adapter 32 is partially located within trusted zone Z2. Because, likewise, the communication adapter must also communicate with trusted instances, such as the event manager 30 or HSM in trusted zone Z2.

The communication adapter 32 should be responsible for communication to other IDS instances 34, such as infotainment, via the switch SWT 48. This communication adapter is partly located in the untrusted zone Z1 in order to communicate with untrusted instances (infotainment, CCU).

By way of example, a communication flow is described in which event reports 242 are periodically sent to higher instances 34 . To this end, communication adapter 32 from trusted zone Z2 has presented events 226 selected in buffer memory 206 to event manager 30 in trusted zone Z2, illustratively described with reference to FIG. Please contact us to make it available. Event report 242 includes certain particularly reliable information regarding encryption and/or authentication, in particular variable size 254 and/or authentication information 256 and/or encryption portion 258 . These values can be provided by the security module 73 already described above as HSM (Hardware Security Module). This security module 73 is illustratively housed in a so-called BSW stack 72 and provides, for example, corresponding random numbers 273 or intervals of such random numbers as variable sizes 254 . The event manager 30 and/or communication adapter 32 of the trusted zone Z2 are responsible for this variable size 254 within the framework of the event report 242 . The event report 242 again arrives in plain text to the security module 73 which encrypts it with the key 258 and provides it to the communications adapter 32 in the trusted zone Z2. The event report 242 so encrypted now reaches the no longer trusted area Z1 via the communication adapter 32, namely the core K3. In response, event report 242 is written to the buffer in zone B3. Illustratively, the event report 242 is indicated by the corresponding arrow and can be communicated to the upper instance 34 via the Ethernet core K4 as previously described. For this purpose the event report 242 is transferred from the memory of the area B3 to the memory area B4_1, ie here in the Ethernet core K4. Further communication takes place from K4 via transmission process I3, for example via Ethernet switch 48, to higher level instances 34 connected via Ethernet.

Subsequent communication flows describe receipt of confirmation signals 408, 416 generated by higher instance 34 (as described in more detail below in connection with FIGS. 5-10). The corresponding acknowledgment signals 408, 416 reach Ethernet core K4 via Ethernet switch 48, where they reach untrusted zone Z1. Via the part of the communication adapter 32 that resides in the untrusted zone Z1, the data is first buffered in area B3, where the untrusted area NT. Communication adapter 32 in trusted zone Z2 has access to the data segregated therein. The communication adapter 32 in this trusted zone Z2 identifies encrypted data. Decryption is done here by the communication adapter 32 of the trusted zone Z2 sending the data to the security module 73 for decryption or by allocating access to the data to the corresponding security module 73. . Subsequently, the signal decrypted by the security module 73 is returned in plaintext again to the communication adapter 32 in the trusted zone Z2. Communication adapter 32 then identifies additional security-related information, such as, for example, variable size 254' and/or authentication information 256', as components of confirmation signals 408, 416 (see FIG. 5). . In a particularly preferred variant, variable size 254' of confirmation signals 408, 416 is transmitted by superior instance 34 and variable size 254 is transmitted by last event report 242 (also generated by security module 73). ) is configured for use as a variable size 254' for the confirmation signals 408,416. Accordingly, security module 73 performs a corresponding check whether variable size 254 ′ of verification signals 408 , 416 matches variable size 254 of last event report 242 , among other things. If this is the case, corresponding release information for confirmation signals 408, 416 can be generated. The communication adapter 32 of the trusted zone Z2 in this connection, for example, sends a signal 410 to the event manager 30 to delete the event 226 in the buffer memory 206 that was transmitted within the framework of the last event report 242 . Additionally, the corresponding authentication information 256' may also be used for verification or authentication of received confirmation signals 408, 416, as described.

In the following, between the event manager 30 and the communication adapter 32 in the controller or gateway 20 and between the communication adapter 32 and at least one further IDS instance 34 in the vehicle 18 and the further IDS instance The communication flow between 34 and backend 36 is exemplarily described based on FIGS. 5-10.

For example, in communication from a control device such as gateway 20 to a further IDS instance 34 (eg, a central event logger within vehicle 18), the further IDS instance 34 or event logger reads the unread entries or events stored in memory 206. 236 or selection event 226. The controller or gateway 20 sends event reports 242 to the further IDS on a periodic basis, preferably via so-called heartbeat signals (periodic signals that can be used to check the proper connection of the communication participants). It should be sent to instance 34. Heartbeat signals (including event reports 242) should be encrypted and genuine. Preferably, the transmitted information is authentic (possibly using authentication information 256) and preferably randomly or encrypted using a random number 273 so that the controller or gateway 20 and the further should be exchanged with the IDS instance 34. Preferably, event report 242 should have a fixed length 257 and should be encrypted and authenticated. Each encrypted event report 242 should be different from the preceding event report 242, even if the transmitted state has not changed.

Additionally, communication from the further IDS instance 34 to the controller or gateway 20 or associated communication adapter 32 should be enhanced by the following functionality. A data logger or IDS instance 34 should read events 236 or associated event reports 242 as soon as possible, especially to prevent memory or buffer memory 206 overflows. The event report 242 should be readable via the diagnostic interface, eg, upon request. Alternatively, event report 242 can be sent completely periodically. The event report 242 should be communicated or read out on a regular basis, preferably authentically and encrypted or disguised, even if the new selected event 226 is not available within the framework of the new event report 242. be. Controller or gateway 20 should respond to read request 240 with a fixed length, encrypted and authenticated response or event report 242 . Each encrypted response or event report 242 should be different from the preceding response or event report 242, even if the content has not changed. Illustratively, this is done by the constantly changing size 254 as previously described.

According to FIG. 5, the event manager 30 located within the trusted zone Z2 first selects the first selected event 226.1 and subsequently selects the second selected event 226.2. These are handled by the event manager 30 as described. These selection events 226.1 and 226.2 are thus stored in memory 206. FIG. The portion of communications adapter 32 that resides within trusted zone Z2 includes signal 400, which is a time-dependent interrupt signal (timer IRQ). Preferably, this time-dependent signal 400 is generated periodically, thereby periodically initiating the transmission of event reports 242 from the communications adapter 32 to further IDS instances 34 within the vehicle 18 . However, even if there are no new events 226.1, 226.2, a signal (in the form of a "normal" event report 242) is sent from the communication adapter 32 to the further IDS instance 34, as explained below. ) is transmitted (see signal 406). Particularly preferably, however, the transmission of the event report 242 is not triggered depending on the acquisition of the event 220 or the selection event 226, but rather is triggered periodically (by the elapse of the periodic time). This is particularly advantageous. This is because, even after that, transmissions to further IDS instances 34 and/or backends 36 are always periodic, ie after a certain period of time. This makes the operation of the event manager 30 or the operation of abnormality identification opaque to an attacker. Attackers never know if their attacks have been detected, what they have detected, or how systems for anomaly identification work.

The portion of communication adapter 32 that resides within trusted zone Z2 requests an event report 242 from event manager 30 after receiving signal 400 (Timer Interrupt) (signal 402). The event manager 30 generates a corresponding event report 242, which includes pre-selected events 226.1 and/or 226.2 (with their respective generic metadata 217 and event dependency metadata 216). and a modified size 254 are included. Additionally, corresponding fill data 255 is added, thereby achieving a fixed length 257 of the event report 242 (knowledge of the length of the authentication information 256 to be formed as well). Further, for example, event manager 30 generates authentication information 256 from modified information 254, selection events 226.1, 226.2 and fill data 255 using a particular algorithm. The authentication information 256 so formed completes the event report 242 . Encryption of the entire event report 242 is then performed using the key 258 . Encrypted event report 242 arrives as signal 404 to the portion of communication adapter 32 that resides within trusted zone Z2. Encryption (using modified information 254 and/or key 258) and authentication (by forming authentication information 256) can be performed at event manager 30 and/or at communication adapters if corresponding security requirements are met. 32 or as already described using the security module 73 (also located in the trusted zone Z2).

Alternatively, communications adapter 32 and/or security module 73 may rely on random number 273 to encrypt event report 242, for example. Particularly preferably, a new random number 273 is always generated for encryption, for example by hashing. This further complicates decryption of transmitted messages or encrypted event reports 242 . In some cases, communication adapter 32 is responsible for authentication using authentication information 256 and/or adding variable size 254 and/or eventual encryption of entire event report 242 using encryption 258. .

A corresponding signal 406 is sent based on the timer interrupt (signal 400 ) itself, even if no new event report 242 is provided by the event manager 30 due to the occurrence of a new selection event 226 . A dummy message having the data format of the event report 242 is then used, encrypted (using the key 258) by a random number or a constantly changing size 254, and transmitted to a further IDS instance 34. Dummy messages are also always encrypted with a constantly changing size 254 or new random number, so that other or encrypted messages (signal 406) are always periodic, even if no new selection event 226 occurs. is transmitted to This periodic transmission allows the functionality of the proper communication connection between the communication adapter 32 and the further IDS instance 34 to be checked. As already explained, the transmission of the event report 242 is through the portion of the communication adapter 32 located within the untrusted zone Z1.

After the message (signal 406) sent by the communication adapter 32 has been acquired by the further IDS instance 34, this further IDS instance 34 sends an acknowledgment signal (408) to the communication adapter 32, in particular located within the untrusted zone Z1. It is transmitted to the part of the communication adapter 32 that is connected. Further procedures have already been described in more detail in connection with FIG. After obtaining this confirmation signal 408, the portion of the communication adapter 32 located within the trusted zone Z2 deletes the buffered, possibly reduced selected event 226 or associated event report 242 for the event manager 30. or generate a request to overwrite again (signal 410).

In an alternative embodiment, upper instance 34 and/or backend 36 checks the authenticity of received encrypted event report 242 . For this purpose, the upper level instance 34 and/or the backend 36 decrypts the received message, in particular the encrypted event report 242 using the known key 258 . Event reports 242 are then available in plain text. Event report 242 is authenticated using a corresponding algorithm for forming authentication information 256 (also used for creation of authentication information 256 by event manager 30 or communication adapter 32). For this purpose, all data of the received and decrypted event report 242 (except authentication information 256) are again used to form corresponding authentication information 256' therefrom. A comparison is then made between the formed authentication information 256 ′ and the authentication information 256 received within the framework of the event report 242 . If there is a match, the received event report 242 is considered authentic. In this variation, further data communication with higher-level or lower-level instances can occur only after successful authentication. In this embodiment, a signal 408 (confirmation signal) is sent to the communications adapter 32 only if the authentication is successful, and the communications adapter 32 now responds to the selection events 226.1, 226.2 for overwriting. A release signal 410 is sent to the event manager 30 .

Preferably, response or confirmation signals 408, 416 should also have a fixed length 257'. Preferably, confirmation signal 408 should be authenticated and encrypted. Each response or acknowledgment signal 408 should be different for higher-level instances 34 and/or backends 36, even if the content has not changed.

An example of such confirmation signals 408, 416 can be seen from FIG. Confirmation signals 408 and 416 are similar in structure to event report 242 . Confirmation signals 408, 416 include variable size 254'. This variable size 254' changes with each newly transmitted confirmation signal 408,416. These variable sizes 254' can also be implemented by random numbers, counters, time, for example.

Particularly preferably, the variable size 254' of the confirmation signals 408, 416 is formed by using the variable size 254 of the event report 242 as previously transmitted and possibly generated by the security module 73. be able to. To this end, the higher instance 34,36 is arranged to extract the variable size 254 from the received event report 242 and insert it into the confirmation signal 408,416. Thereby, in a subsequent step, authentication of the confirmation signal 408, 416 also compares the received variable size 254' of the confirmation signal 408, 416 with the variable size 254 of the previously transmitted event report 242. It can be done by If there is a match, an inference is made with the confirmation signal 408, 416 of authenticity. Besides, this variable size 254' does not have to be self-generated in the upper instance 34,36. The release of memory 206 may follow.

Additionally, confirmation signals 408, 416 include specific data 255', for example, in the form of arbitrary patterns. Further, confirmation signals 408, 416 also include authentication information 256'. This authentication information 256', like the event report 242, can again be formed via a specific algorithm that utilizes the residual data of the confirmation signals 408, 416, specifically the variable size 254' and data 255'. . The authentication information 256' so formed completes the confirmation signals 408, 416 having a fixed length 257'. Encryption is then performed using key 258'. Optionally, this encryption 258' can be omitted.

The received instance (e.g., upper instance 34, backend 36) and/or communication adapter 32 or event manager 30 again decrypts (using key 258') and authenticates acknowledgment signals 408, 416. be able to. For this purpose, again, from the received data (variable size 254', data 255') the resulting authentication information 256'' using a corresponding known algorithm is determined and the obtained authentication It is compared with information 256'. If there is a match, it is based on authenticity. As long as the obtained authentication information 256' is valid, a signal 410 can be generated to free the memory 206. FIG. If the authentication information 256' is not correct, this signal 410 could not have been generated, so the selection event 226 contained in memory 206 is not (yet) deleted.

A further IDS instance 34 also periodically receives a timer interrupt signal 412 which is formed similarly to signal 400 as already described. Based on this interrupt signal 412, the further IDS instance 34 transmits a message, again encrypted (signal 414). This message optionally includes an event report 242 or an event report related to the vehicle (including further event reports) as transmitted from in front of communications adapter 32 via signal 406 . As with the communication adapter 32, the message is encrypted by the further IDS instance 34, in particular with a constantly changing size 254', for example a random number 273. For example, if communication adapter 32 did not transmit event report 242 because new selection event 226 did not occur, then again a dummy message having the same data format as event report 242 is used and encrypted and backed up. It is transmitted to end 36 (signal 414). Backend 36 sends further notifications or requests for overwriting such as acknowledgment signal 416 and/or events 236 buffered in buffer memory 206 to further IDS instances 34 . Confirmation signal 416 may be formed as described above.

After obtaining signal 410 regarding event release, event manager 30 further selects selected events 226.3 and 226.4. A further flow can be seen from FIG. Meanwhile, the event manager 30 selects one further event 226.5. A new timer interrupt (signal 420 ) arrives at communications adapter 32 . The adapter now requests an event report 242 for gateway 20 (signal 422). Event manager 30 sends event report 242 to communications adapter 32 based on selected events 226.3, 226.4, 226.5 (signal 424). After obtaining the event report 242, the communication adapter 32 sends the event report 242 encrypted and authenticated by the new variable size 254, such as a random number, to the additional IDS instance 34 (signal 426). This acquisition is confirmed by the further IDS instance 34 with an acknowledgment signal 428 . This confirmation signal 428 may be formed as described in connection with confirmation signal 408 (FIG. 5). After obtaining confirmation signal 428, communication adapter 32 again sends event manager 30 a request to overwrite or delete selected events 226.3, 226.4, 226.5 on which event report 242 is based. (signal 430). Between the transmission of signal 424 and the reception of signal 430, a further selection event 226.6 is selected in between. However, this selection event 226.6 is not yet overwritten. This is because the selected event 226.6 was not yet the basis for the event report 242 that was already transmitted to the communication adapter 32. Insofar, this signal 430 does not concern the overwriting of the selection event 226.6, but rather only the selection events 226.3, 226.4, 226.5 already transmitted within the framework of the last event report 242. It is about overwriting of .

Again, in the further IDS instance 34, a timer interrupt is generated (signal 432) as previously described. This causes the further IDS instance 34 to encrypt the newly received event report 242 in signal 426 and transmit it to the backend 36 (signal 434). After obtaining the corresponding message 434 , the backend 36 confirms with a corresponding confirmation signal 436 sent to the further IDS instance 34 . This confirmation signal 436 may be formed like confirmation signals 408 or 416 .

A further flow is shown in FIG. Newly, a further timer interrupt for communications adapter 32 is generated (signal 440). Here, communication adapter 32 transmits a request for transmission of event report 242 from trusted zone Z2 to event manager 30 (signal 442). Event manager 30, meanwhile, sends event report 242 containing selected event 226.6 (signal 444). Communication adapter 32 encrypts event report 242 using new variable size 254 and possibly using security module 73, and places this encrypted event report 242 in untrusted zone Z1. Transmit to further IDS instance 34 via the portion of communications adapter 32 that is present (signal 446). Upon getting this, the further IDS instance 34 sends an acknowledgment (signal 448) and upon getting this signal the communication adapter 32 tells the event manager 30 to overwrite the already transmitted event 226.6. or send a request to release (signal 450).

Again, a further IDS instance 34 receives the timer interrupt (signal 452). Here, encrypted event report 242 is transmitted to backend 36, possibly along with further event reports for further IDS systems associated with the vehicle. Backend 36 sends a confirmation signal and/or a request, such as to release or overwrite the corresponding event, to further IDS instance 34 (signal 456).

In the exemplary flow according to FIG. 8, no new selection event 226 occurred between the transmission of the last event report 242 and the new occurrence of the timer interrupt (signal 460). After obtaining timer interrupt 460, communication adapter 32 sends to event manager 30 a corresponding request signal 462 for a new event report 242 from trusted zone Z2. Event manager 30 generates event report 242 with dummy content (even though new selection event 226 occurred) and then sends it to communication adapter 32 (signal 464). This dummy content is identifiable as such by the further IDS instance 34 and/or by the backend 36 . Communications adapter 32 encrypts received event report 242 with dummy content, possibly using security module 73, within trusted zone Z2 using new variable size 254, and converts this encrypted and transmit and transmit authenticated event report 242 to further IDS instance 34 (signal 466). This transmission again takes place from the untrusted zone Z1. This acquisition is confirmed by a further IDS instance 34 (signal 468). Upon receiving this signal, communication adapter 32 sends a new request signal to event manager 30 to overwrite last selected event 226 (signal 470). This is done even if there is no new selection event 226 as in this situation.

Newly, a further IDS instance 34 gets a timer interrupt (signal 472). Here, the further IDS instance 34 encrypts the last obtained encrypted event report 242 transmitted from the communication adapter 32 and backs it up, possibly with further event reports from further IDS systems associated with the vehicle. Send to end 36 . The backend 36 sends confirmation signals 476 and/or requests for release of the underlying events, etc. to the further IDS instances 34 .

In the communication flow of FIG. 9, the communication adapter 32 newly acquires a timer interrupt (signal 480). This timer interrupt 480 can be a special signal. As such, communications adapter 32 requests an event summary (rather than one of regular event reports 242) from event manager 30 (signal 482). Event manager 30 sends the event summary to communication adapter 32 (signal 484). This is again done within the trusted zone Z2. In the event summary, high-level information can be included, for example, different counter states 231 for different event types 218, or the occurrence of new event types. Again, the event digest from communication adapter 32 is encrypted within trusted zone Z2, possibly using security module 73, with a new variable size 254, such as a random number, and sent to further IDS instance 34. is transmitted (signal 486). This transmission again takes place from the untrusted zone Z1. As soon as the IDS instance 34 obtains the encrypted event digest from the communication adapter 32, the further IDS instance 34 particularly preferably encrypts this event digest and forwards it to the backend 36. In this embodiment, for the transmission process between the further IDS instance 34 and the backend 36, no timer interrupt is provided to initiate the communication process. However, alternatively, here too, it can be initiated periodically like normal event report transmissions.

In the communication flow of FIG. 10, backend 36 sends a request for an event report to further IDS instance 34 (signal 490). A further IDS instance 34 sends an encrypted request for an event report to communications adapter 32 via, for example, a diagnostic interface (signal 492). This encryption can again be done via a variable size 254', e.g. a random number, which in particular varies from encryption to encryption. After obtaining request 492, communication adapter 32 in security-related zone Z2 sends an inquiry for event report 242 to event manager 30 (signal 494). After obtaining the corresponding query 494, event manager 30 sends event report 242 to communications adapter 32 (signal 496). The communication adapter 32 encrypts this event report 242 via a new variable size 254, e.g. Send to IDS instance 34 (signal 498). After obtaining the encrypted event report 242 , the further IDS instance 34 transmits this event report 242 to the backend 36 . Backend 36 confirms this acquisition with further IDS instance 34 (signal 492). The further IDS instance 34 confirms the acquisition of this confirmation signal 492 to the communication adapter 32 (signal 494). After obtaining the corresponding signal 494 , the communication adapter 32 sends to the event manager 30 a corresponding request to release or overwrite the event 220 transmitted within at least the last event report 242 .

The methods described may be implemented in a computing unit, computer or controller, in particular a controller of the vehicle 18 . Likewise, the method may be produced within the framework of a computer program arranged to carry out the method when run on a computer. Furthermore, the computer program may be stored on a machine-readable storage medium. Nevertheless, the program can be installed wirelessly, for example as "wireless" software, or wired via a diagnostic interface.

Claims (17)

A method for handling data anomalies, particularly in a motor vehicle, comprising:
at least one sensor (24, 26, 28) for anomaly identification acquires data (211);
The sensors (24, 26, 28) examine the acquired data (211) for anomalies and, if anomalies are identified, generate events (220, 221) depending on the associated data (211). and forwarded to an event manager (30), wherein
At least one trusted zone (Z2) and one untrusted zone (Z1) are provided, wherein at least one sensor (24, 26, 28, 40, 60) and/or said event manager (30) assigned to said trusted zone (Z2). at least one communication adapter (32) located within the same zone (Z2) as said event manager (30), said communication adapter (32) being at least partially created by said event manager (30) 2. The method of claim 1, for use in communicating event reports (242). Method according to claim 1 or 2, wherein said communication adapter (32) is also assigned to said untrusted zone (Z1). Said sensors (24, 26, 28) in said trusted zone (Z2) have at least data (211) from sensors (38, 62) located in said untrusted zone (Z1), especially defragmented The sensors (24, 26, 28) containing data and within the trusted zone (Z2) examine the acquired data (211) for anomalies and, if anomalies exist, an event (220). and/or the sensors (38, 62) in the untrusted zone (Z1) examine the acquired data (211) for anomalies and, if anomalies exist, generate an event ( 220). The transmission of the event report (242) is performed by a communication adapter (32) in the trusted zone (Z2) that is accessible and transmittable by the communication adapter (32) in the untrusted zone (Z1). 5. A method according to any one of claims 1 to 4, performed by bringing said event report (242) to a memory of a zone (Z1) that cannot be disabled. The event reports (242) include at least one size (254) and/or at least one authentication information (256) that varies for each event report (242) and/or are encrypted by encryption (258) 6. A method according to any one of claims 1 to 5, wherein A security module (73) assigned to said trusted zone (Z2) provides varying size (254) and/or authentication information (256) and/or encryption (258) for each said event report (242). 7. A method according to any one of claims 1 to 6, wherein After sending said event report (242), an acknowledgment signal (408, 416) is received, said acknowledgment signal (408, 416) is received by a communication adapter (32) in said untrusted zone (Z1), said 8. A method according to any one of claims 1 to 7, transferred to a communication adapter (32) of a zone (Z2) capable of transmitting. Said confirmation signals (408, 416) may have at least one size (254') and/or at least specific data or pattern (255') and/or at least one authentication information that varies for each confirmation signal (408, 416). (256') and/or comprising at least one fixed length (257') and/or encrypted using an encryption (258'). described method. The communication adapter (32) in the trusted zone (Z2) uses the security module (73) located in the security relevant zone (Z2) to transmit the received confirmation signal (408, 416) to a 10. A method according to any one of the preceding claims, decrypting and/or authenticating. The received confirmation signal (408, 416) is decoded by checking whether the variable size (256) of the transmitted event report (242) is included in the confirmation signal (408, 416). 11. A method according to any one of claims 1 to 10, wherein the method is authenticated and/or authenticated. Upon transmission of data from one zone (Z1) to the other zone (Z2), said sensors (24, 26, 28) check the data before use and in particular whether an event (220) has occurred. 12. Any one of claims 1 to 11, checking if and/or if no event (220) is detected, said data is released in said other zone (Z2) for use. The method described in . If an event (220) occurs, no data is transferred to said other zone (Z2) and/or said sensors (24, 26, 28) send said event (220) to said event manager (30). ), the method according to any one of claims 1 to 12. Said event manager (30) and/or said trusted zone (Z2) communication adapter (32) and/or said trusted zone (Z2) sensors (24, 26, 28) and/or security module (73) , a computer core (K2). At least one computing device (100a; 100b) is assigned a specific executable application program (AP) for one of at least two zones (Z1, Z2), said zones (Z1, Z2) being , characterizing the resources of said computing device (100b; 100b) that are available for the execution of corresponding application programs (AP), and optionally at least one of said application programs (AP) allocated to itself. 15. A method according to any one of claims 1 to 14, wherein the method is performed depending on which zone (Z1, Z2) is defined. Said method further comprises the step of exchanging first data between different zones (Z1, Z2) via a buffer memory, in particular a main memory, in particular a first zone (Z1) and a second zone ( Z2) exchanging said first data with: d1) copying said first data to a first buffer memory area allocated to said first zone (Z1); d2) checking said copied first data and, in particular depending on said checking, d3) transferring said first data to said first zone (Z1) assigned to said first zone (Z1); 16. A method according to any one of the preceding claims, comprising copying from a buffer memory area to a second buffer memory area allocated to said second zone (Z2). Apparatus for carrying out the method according to at least one of claims 1 to 16.

Images