[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2021197822A1 - Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug - Google Patents

Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug Download PDF

Info

Publication number
WO2021197822A1
WO2021197822A1 PCT/EP2021/056539 EP2021056539W WO2021197822A1 WO 2021197822 A1 WO2021197822 A1 WO 2021197822A1 EP 2021056539 W EP2021056539 W EP 2021056539W WO 2021197822 A1 WO2021197822 A1 WO 2021197822A1
Authority
WO
WIPO (PCT)
Prior art keywords
zone
event
data
trustworthy
communication adapter
Prior art date
Application number
PCT/EP2021/056539
Other languages
English (en)
French (fr)
Inventor
Manuel Jauss
Roland Steffen
Mustafa Kartal
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to JP2022558498A priority Critical patent/JP7467670B2/ja
Priority to CN202180024770.8A priority patent/CN115398427A/zh
Publication of WO2021197822A1 publication Critical patent/WO2021197822A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209—Architectural arrangements, e.g. perimeter networks or demilitarized zones

Definitions

  • the invention relates to a method for handling an anomaly in data, in particular in a motor vehicle.
  • a device and a method for treating an anomaly in a communication network, in particular a motor vehicle, are already known from DE 102018209407 A1.
  • At least one detector analyzes a data stream in the communication network, the at least one detector recognizing at least one anomaly by a rule-based anomaly detection method when at least one parameter for a data packet of the data stream deviates from a target value, the at least one detector providing information about at least one detected anomaly via the Communication network sends.
  • the automatic creation of a protocol, history or report should take place in the event of high event rates and / or long-lasting attacks without overload and rejection of corresponding services.
  • the logging entries or corresponding event reports should be authentic, with integrity and available. If possible, a history of a complete (long-lasting) attack that is not deterministic for the attacker should be created. Manipulation and, in particular, deletion by an attacker should be avoided. Outside of a control unit, the logging entries should be protected against unauthorized analysis.
  • the logger is designed to provide the event reports reliably for example, send via an interface to an external node.
  • the event entries can be deleted locally, particularly preferably after an in particular authenticated confirmation by the receiving entity.
  • the logger should also send a so-called heartbeat signal, which indicates a network connection. The collection of events should be possible in order to reduce the number of logging entries to be processed.
  • IDS or IDPS systems Intrusion Detection System, intrusion detection, a system for the automated detection of attacks on computer networks or computer interfaces; or IDPS: Intrusion Detection Prevention System, if an intrusion attempt is detected, the corresponding data is not forwarded and thus the intrusion attempt prevented), deterministic behavior and the limited resources of the embedded systems are often problematic. In contrast, it is desirable to specify an improved method for anomaly detection. This object is achieved by the features of the independent claim.
  • the manipulation protection can be further increased with the aid of a 2-stage security concept.
  • the arrangement of the sensor and / or event manager in the trustworthy zone as a trustworthy entity makes access to sensitive data and manipulation possibilities more difficult.
  • At least one communication adapter is arranged in the same zone as the event manager, the communication adapter serving to communicate an event report at least partially created by the event manager.
  • the communication adapter can check a data transfer to the other zone, while it can communicate with the event manager and / or sensor within the security-relevant zone.
  • the communication adapter is also assigned to an untrustworthy zone. This part is used to communicate with the higher-level IDS instance, which are generally untrustworthy instances.
  • the senor in the trustworthy zone contains at least data, in particular defragmented data, from a sensor which is arranged in the untrustworthy zone, the sensor in the trustworthy zone checking the received data for anomalies and at If an anomaly is present, an event is generated and / or the sensor in the untrustworthy zone receives the Checks data for anomalies and generates an event if there is an anomaly.
  • the event report is sent by the communication adapter in the trustworthy zone bringing the event report to a memory in the untrustworthy zone, which the communication adapter in the untrustworthy zone can access and send. In this way, a secure data transfer from one zone to the other can be ensured.
  • the event report includes at least one variable that changes for each event report and / or at least one piece of authentication information and / or is encrypted by encryption. This allows the higher-level instance to check whether the data is authentic. To this end, it is particularly expedient to provide that the authentication information is formed by further information contained in the event report.
  • a security module assigned to the trustworthy zone provides a variable for each event report and / or authentication information and / or encryption. This enables a secure, authentic and confidential connection to be established with a higher-level entity.
  • the confirmation signal comprises at least one variable variable for each confirmation signal and / or at least certain data or patterns and / or at least one piece of authentication information and / or at least one constant length and / or is encrypted with an encryption . Due to the variable size, the confirmation signal always looks significantly different from the attacker, especially after encryption, and is therefore not interpretable.
  • the additional variable signal ensures that it is up-to-date, since an elderly incident report cannot be used.
  • the authentication information ensures that the confirmation signal comes from a real higher-level entity and was not generated by an attacker. This means that the local event report can be deleted in a trustworthy manner.
  • the communication adapter of the trustworthy zone decrypts and / or authenticates the received confirmation signal using a security module arranged in the security-relevant zone.
  • the further verification in the trusted zone further improves the security of the communication.
  • the sensor checks the data before use, in particular whether an event has occurred and / or that, in the event that no event was detected, the Data are released for use in the other zone. This further reduces the possibilities for manipulation.
  • the event manager and / or the communication adapter of the trustworthy zone and / or the sensor of the trustworthy zone and / or the security module are implemented on a computer core. This means that all security-relevant functions can be implemented on one computer core, which further increases security.
  • At least one computing device is assigned certain executable application programs to one of the at least two zones, the zones characterizing resources of the computing device that can be used for executing a relevant application program, optionally executing at least one of the application programs as a function the zone assigned to it.
  • the above-mentioned assignments between zones and functions can be used to ensure that only security-relevant functions are carried out in the trustworthy zone.
  • the method steps have the following: exchanging first data between different zones via a buffer memory, in particular working memory, wherein in particular exchanging the first data between the first zone and the second zone has the following steps: d1) copying the first data into a first buffer memory area assigned to the first zone, d2) checking the copied first data, and, in particular depending on the check, d3) copying the first data from the first buffer memory area assigned to the first zone into a second buffer memory area assigned to the second zone. This ensures that secure data exchange between the zones is preferred.
  • Fig. 1 schematically components of an intrusion detection
  • FIG. 2 shows an exemplary structure or interaction of received data, the event derived therefrom, the structure of the associated selected event and an event report,
  • Fig. 4 schematically shows a simplified block diagram of aspects according to a further preferred embodiment
  • Event manager communication adapter, further IDS instance and backend.
  • anomalies deviations from normal behavior, which for various reasons can occur in real operation in data 211 (for example data of a communication system or system data) of a networked system in particular, are referred to as anomalies.
  • causes for this can be, for example, the following types: Defective or completely failed sensors provide incorrect or no data at all, components of the system are damaged, the system has been manipulated by external as well as local or physical attacks (e.g. a hacker attack).
  • IDS intrusion detection system
  • IDPS intrusion detection system
  • IDS denotes a system which monitors data 211 for anomalies.
  • This can be, for example, data 211 in the data connection in a communication network via which the control device 20, such as a gateway, communicates on different communication channels (for example via bus systems such as 25 or Internet 27).
  • other data 211 for example system data within a control device (or host 29 or microcontroller or processor arranged therein, or within a chip) should also be checked for anomalies by this IDS system.
  • Anomalies in the data 211 are detected by suitable means Sensors 24, 26, 28.
  • the sensors 24, 26, 28 are adapted to the respective source of the data 211 (in the exemplary embodiment bus systems 25, 27 or host 29).
  • a control device such as a gateway 20 is arranged in a vehicle 18.
  • the control device or the gateway 20 comprises processor (s), memory, main memory (for example as part of a host system 29) and interfaces for communication via a communication network.
  • the gateway 20 processes, for example, instructions for the data connection.
  • the communication produces data 211 in the form of data packets.
  • Data 211 for example system data, also arise during the operation of the host 29.
  • setpoint values are maintained, for example with regard to recipient and destination address, compliance with the correct program sequence (for example for host 29), time stamp, frequency of occurrence or frequency of data 211 of specific data packets.
  • the data 211 of the data packets are exchanged between further control devices or components in the vehicle 18 (not shown in detail) in order to fulfill the specific tasks.
  • the gateway 20 is used to couple several communication systems or interfaces such as a CAN bus 25, an Ethernet connection 27 and a data connection to the host system 29, which is part of the control device 20 or the gateway.
  • other communication systems for example further wired bus systems such as LIN, CAN-FD etc. or wireless networks (for example WLAN or Bluetooth) can be coupled to one another for the purpose of data exchange through the gateway 20.
  • an intrusion detection IDS or anomaly detection is used in one Control device to monitor all data 211 (data 211 received by communication system as well as data 211 generated within control device 20 by host 29) for corresponding anomalies
  • the functionality of the anomaly detection or intrusion detection IDS described above can be implemented in any control device or any electronic components Communication modules in the Internet (IOT Internet of Things) or be equipped with the functions described in networked production systems.
  • a communication component such as the control device or the gateway 20 comprises at least one anomaly detection 22.
  • the anomaly detection 22 extends over at least one untrustworthy zone Z1 and over at least one trustworthy zone Z2.
  • a communication adapter 32 is located both in the trustworthy zone Z2 and in the untrustworthy zone Z1.
  • At least one sensor 24, 26, 28 is located in the trustworthy zone Z2.
  • the event manager 30 is also located in the trustworthy zone.
  • the data 211 incoming via the interfaces of the respective communication systems 25, 27, 29 are each conducted via so-called sensors 24, 26, 28 for anomaly detection or intruder detection, IDS sensors for short.
  • Corresponding sensors 24, 26, 28 are arranged in gateway 20.
  • Such sensors 24, 26, 28 serve to detect whether the data 211 received represents an anomaly.
  • corresponding filter algorithms or rule sets are stored in the sensors 24, 26, 28, which serve to detect and classify anomalies. If an anomaly is detected by a sensor 24, 26, 28, the corresponding data packet of the data 211 is classified as an event 220 (an attempted intrusion).
  • the sensors 24, 26, 28, depending on the source 25, 27, 29, can classify and recognize different anomalies as events 220 (assignment of the respective event 220 to specific event types 218).
  • the sensors 24, 26, 28 compile certain event-dependent metadata 216 as an associated event 220.
  • the event-dependent metadata 216 can also contain data or data components of the anomalous data 211.
  • the event 220 generated in this way is forwarded to an event manager 30.
  • the sensors 24, 26, 28 are generally designed so that if there is no anomaly, the associated data 211 of a communication system (for example bus systems 25, 27) are forwarded to the destination address. If an anomaly is detected, the sensors 24, 26, 28 could be designed in such a way that the associated data 211 of a communication system (for example bus system 25, 27) cannot be forwarded to the destination address.
  • the sensors 24, 26, 28 can also be used to reduce events 220 (reduced event or pre-reduced event 221). This reduction could reduce the load on the event manager 30, for example by only forwarding a small portion of useful data from data 211 or data packets containing anomalies. This is particularly advantageous with large amounts of data, such as those that occur with Ethernet connections.
  • IDS CAN sensors 24 are used for anomaly detection in a CAN bus 25, IDS Ethernet sensors 26 in an Ethernet system 27 and IDS host sensors 28 in a host system 29.
  • IDS sensors can also be provided that are able to detect anomalies in the respective sources or anomaly sources and, if necessary, to classify them.
  • the IDS CAN sensors 24 detect incidents 220 of associated event types 218, such as invalid CAN ID's, invalid messages frequencies, invalid message length or the like.
  • the IDS Ethernet sensors 26 detect relevant events 220 of associated event types 218 for the Ethernet 27, such as invalid addresses or MAC addresses, invalid message frequencies, invalid message lengths or the like.
  • the IDS host sensors 28 detect events 220 of associated event types 218 that are relevant for the host system 29, such as, for example, invalid code executions, corruption of programs, batch counters or the like. At least one sensor 24, 26, 28 is arranged in the trustworthy zone Z2.
  • events 220 for further event types 218 can be taken into account as events 220 for further event types 218.
  • events 220 or event types 218 that can be assigned to the firewall, such as loss of the frame due to a full buffer memory, filter violation (stateless / stateful), limitation of the transmission rate active or inactive, monitoring mode activated or deactivated, context change.
  • Further anomalies that affect the host system 29 can also be taken into account as events 220 with associated event types 218, for example CPU load too high, memory access violation, error in code execution, ECU reset detected, log entries in the non-volatile memory corrupted, overflow of the logging memory, rejection of an event, MAC address port change, etc.
  • the event manager 30 is used to further process the incoming events 220 or the event-dependent metadata 215 contained in the respective event 220 Events 220 and / or the storage or persistence or permanent storage of the selected and / or reduced events 220, 221.
  • the event manager 30 decides which incoming events 220 are to be processed further. Those selected from the incoming events 220 are referred to as selected events 226. The corresponding selection should be made as non-deterministic as possible.
  • the event manager 30 provides the incoming events 220 or the selected events 226 particularly preferably with further generic metadata 217. the associated time stamp or time signal 224 or the like can be added as part of the generic metadata 217. Furthermore, it is ensured that even in the event of a so-called event burst, a sufficient number of meaningful events 220 can be stored as selected events 226.
  • the event manager 30 is arranged in the trustworthy zone Z2.
  • the event manager 30 exchanges signals with a communication adapter 32 for intrusion or anomaly detection.
  • the communication adapter 32 functions as a communication means for data exchange between the event manager 30 and further components 34, 36 outside the anomaly detection 22 of the control device or gateway 20 of the vehicle 18) and / or a backend 36 (preferably outside of the Vehicle 18).
  • the further IDS instance 34 can only be provided as an option.
  • the communication adapter 32 is arranged in both zones Z1, Z2.
  • the event manager 30 could undertake a random reduction and prioritization of events 220, 221 that is not determininistic and disguised for an attacker.
  • a non-volatile storage of selected events 226 could be carried out randomly, not deterministically for the attacker and in a disguised manner.
  • the randomly controlled selection could, for example, be based on a random number 273 that is individual for a specific control device.
  • the event manager 30 can also store the counter readings 231 of the event counters 204 on a random basis.
  • the event manager 30 also stores the added generic metadata 217 as selected events 226 in a random manner in addition to the event-dependent metadata 216.
  • the communication adapter 32 could undertake a random, non-deterministic and disguised uploading or sending of an event report 242 to other IDS instances 34 for an attacker.
  • the randomly controlled upload could, for example, be based on a random number 273 that is individual for a specific control device (or gateway 20).
  • specific events 220 could be transmitted cyclically and in encrypted form within the scope of the event report 242. But even if there are no new events 220, so-called dummy events could be transmitted cyclically and encrypted in the format of an event report 242. This serves to protect against eavesdropping or to conceal the data exchange based on chance between the communication adapter 32 and further IDS entities 34 or the backend 36.
  • the processed reduced events 221 are forwarded from the sensor 26 to the event manager 30.
  • the event manager 30 thus does not receive complete data streams of these net frames from this sensor 26, but only reduced events 221 with reduced data size.
  • the reduction of the events 221 to be forwarded was described by way of example using an IDS Ethernet sensor 26. In principle, however, this could also be implemented in other IDS sensors 24, 26, 28. Due to the high information content in In an Ethernet frame with high transmission rates, however, such events 220 would quickly lead to an overflow of the buffer memory 206. In the case of IDS CAN sensors 24, corresponding data 211 occurs anyway at a lower data rate and a lower data volume, so that complete events 220 can tend to be passed on and stored here.
  • FIG. 2 it is shown by way of example how data 211 from the sensor 24, 26, 28 are further processed in the event of a detected anomaly and sent to the event manager 30 until the latter sends an event report 242 via the communication adapter 32.
  • a data packet of data 211 is shown in FIG. 2a as it could occur, for example, in a network frame (for example CAN, Ethernet).
  • the data 211 has a header 214 which includes, for example, the source address and the destination address (for example MACa, MACb).
  • the data 211 include useful data 213.
  • the senor 24, 26, 28 could optionally select a useful data area 219 at random, which is forwarded to the event manager 30.
  • the sensor 24, 26, 28 has determined that it is an anomaly according to a certain type of event 218 (event ID or event ID,
  • the sensor 24, 26, 28 therefore generates event-dependent metadata 216 as shown in FIG. 2b.
  • event-dependent metadata 216 Depending on the event type 218 (or ID), different information about the anomaly can be stored in the event-dependent metadata 216.
  • the source and destination address (MACa, MACb), the event type 218 and the selected useful data area 219, among other things, are used as event-dependent metadata 216.
  • event-dependent useful data 213 could also be forwarded to the event manager 30 in full as part of the event 220.
  • the event 220 could also not include any event-dependent user data 213, for example if the host 29 is used as the source.
  • event-dependent metadata 216 can be part of the event 220 for different event types 218.
  • the event-dependent metadata 216 could, for example, include the context, for example in the size of 32 bits.
  • the event-dependent metadata 216 could include, for example, the accessed address (for example 32 bits), the program counter (for example 32 bits), the task ID (for example 8 bits).
  • the event-dependent metadata 216 could include, for example, the reason for the reset (for example 8 bits), for example POR (point of return), software reset, exceptions, etc.
  • Subsequent Ethernet-related events 220 could be logged as event-dependent metadata 216, such as static / state-dependent filter violations (specific rule ID or ID for specific event type 218 (e.g. 16 bits), an ID of the filter rule that caused event 220 if available, physical port address, physical port ID via which the frame was received, source address (e.g. MAC address, e.g. 48 bit), destination address (e.g. MAC address, e.g. 48 bit), possibly IP address of the source or destination, Determination of the UDP / TCP port (e.g. 16 bit) if available in the frame, optional).
  • specific rule ID or ID for specific event type 218 e.g. 16 bits
  • ID of the filter rule that caused event 220 if available
  • physical port address e.g. 48 bit
  • destination address e.g. MAC address, e.g. 48 bit
  • IP address of the source or destination e.g. 16 bit
  • Determination of the UDP / TCP port
  • static / state-dependent filter violations could also be logged, such as rule ID, physical port, frame (number of bytes), certain number of bytes of the received frame are stored, selected user data area 219 (certain number of bytes) selected user data area 219 of the bytes of the original Frames, user data area 219 - index (for example 16 bits), start byte of the selected user data area 219 in the original frame.
  • Ethernet-related events could also be contained in the events 220 transmitted to the event manager 30, such as for the event type 218 "Transmission rate limited (active / inactive)" the rule ID with the associated ID of the filter rule that caused the event 220, for the Event type 218 “Change of context” the context (for example 32 bit), for event type 218 “Address hopping” or “MAC hopping” the old port (physical port ID that was originally assigned to the address), the new port (physical port ID where the address was recently observed), the address, preferably MAC address.
  • event types 218 without metadata 216 can also occur, such as "loss of frame due to full buffer” etc.
  • the forwarding of event-dependent useful data 213 thus depends in particular on the source of the data 211 with the associated event type 218.
  • the metadata 216 is transmitted to the event manager 30 as an event 220 or reduced event 221 (due to the random selection or reduction of the useful data area 219 to be transmitted in the sensor 24, 26, 28).
  • generic metadata 217 are added to the event-dependent metadata 216 so that the metadata 215 shown in FIG. 2c arise.
  • These generic metadata 217 are usually generated in the event manager 30. These are, for example, output signals from event counters 204, that is to say current counter readings 231, how many global event 220 or how many event of a specific event type 218 the current event 220 is.
  • the generic metadata 217 can include, for example, a time signal 224 indicating when this event 220 occurred.
  • the metadata 217 could include the length 232 (size of the data) the event-dependent metadata 216 or the complete metadata 215 have. This is advantageous for the later memory management of the buffer memory 206.
  • the following generic metadata 217 is proposed as an example. This could, for example, be an event type 218 in the context of an event ID (for example 8 bits). This event ID of event type 218 is unique and can, for example, comprise a TLV-based coding (TLV: Type-Length-Value type-length-value).
  • the generic metadata 217 include the length 232, for example between 8 and 16 bits in size. The size of the data (metadata 215) follows the length field in bytes, up to a maximum of 255 bytes. Again, TLV-based coding could be provided. Also included is the time signal 224, a time stamp (for example 64 bits).
  • the time 224 is given, for example, in the form of an absolute time value that has elapsed since a reference point in time such as January 1, 1970 (in milliseconds) for the purpose of specifying a unique time stamp.
  • the generic metadata 217 counter readings 231 or output values 231 of the event type counter 204 (for example 32 bits) and / or the counter reading 231 of the global (event) counter 204 (for example 32 bits), a sum of all counter readings 231 of the event counters 204 for each event type 218.
  • the event-dependent metadata 216 are adopted as they were formed by the respective sensor 24, 26, 28.
  • This event 220 with the corresponding metadata 215 formed both by the sensor 24, 26, 28 and by the event manager 30 is stored in the buffer memory 206 of the event manager 30.
  • further events 226 selected or reduced by the event manager 30 designated as 215_1, 215_8, 215_190 in the exemplary embodiment according to FIG.
  • an event report 242 is now generated. This includes the selected events 226 stored in the buffer memory 206 (in the example 215_ 1, 215_8,
  • the event report 242 also includes authentication information 256.
  • the authentication between communication adapter 32 or event manager 30 and the unit receiving the event report 242 can also take place.
  • the event report 242 has a fixed length 258. To achieve this fixed length 258, the data 254, 215_ 1, 215_8,
  • the shown data of the event report 242 is encrypted 258 as indicated in FIG. 2d.
  • the event report 242 encrypted in this way by the encryption 258 is sent by the communication adapter 32 and decrypted and authenticated by the further IDS entity 34 or backend 36 as described.
  • FIG. 3 schematically shows a computing core 102a of a switch SWT 48 according to further preferred embodiments, which comprises an operating system BS and / or supervisor SV and which is itself assigned to two zones Z1, Z2.
  • the anomaly detection 22 is based on a 2-zone concept in which certain applications are assigned to an untrustworthy zone Z1 and a trustworthy zone Z2.
  • the anomaly detection 22 can in particular be used, for example, for an embedded system and / or a control device, in particular for a vehicle, in particular a motor vehicle.
  • Preferred embodiments relate to a method for operating a computing device assigned to anomaly detection 22, which has the following steps: Assignment of one or more application programs AP1, AP2 that can be executed by the computing device to one of at least two zones Z1, Z2, with zones Z1, Z2 Characterize resources of the computing device that can be used for executing a relevant application program AP1, AP2, optionally executing at least one of the application programs AP1, AP2 depending on the zone Z1, Z2 assigned to it, the method further alternatively comprising: using a supervisor SV for assigning of computing time resources for different application programs and / or instances of application programs, the supervisor SV and / or a functionality corresponding to the supervisor SV being implemented at least in part by means of a supervisor instance SVI which is controlled by the at least two zones Z1, Z2 is independent.
  • trust boundaries can thereby be defined, for example between trustworthy and untrustworthy entities / units / domains.
  • first application programs for the computing device of an untrustworthy first zone Z1 (English: non-trustworthy zone, NT) and second application programs for the computing device of a trustworthy second zone Z2 (English: trustworthy zone, (T) Z) are assigned.
  • the supervisor instance SVI can be formed, for example, by a (dedicated) computing core and / or a hardware security module HSM and / or a trusted platform module TPM, or the functionality of the supervisor instance SVI can be implemented using at least one of these elements can be realized.
  • the method for operating the computing device further comprises: controlling, in particular limiting, of at least one of the following elements: a) reading rights on the memory assigned to the computing device, b) writing rights on the memory assigned to the computing device, c) execution rights ("Execution rights") on the memory allocated to the computing device, depending on at least one zone Z1, Z2.
  • an application program of an untrustworthy zone Z1 accesses the memory (s) (in particular, for example, access to the memory area assigned to the trustworthy zone Z2 by the untrustworthy zone Z1) Represents a risk of possible manipulation of the memory contents by the application program of the untrustworthy zone Z1.
  • the computing device can, for example, execute the following scenario: If a first application program AP1 is to receive data from a, for example, untrustworthy first zone Z1 - for example remote service requests from the Internet - and process or forward this data accordingly within the trustworthy zone Z2 - for example, to execute the corresponding service ("remote service") - the data is received within the first zone Z1 by the Z1 proxy AP1J1 of the application program AP1, with the corresponding Z2-Proxy_l2 carries out the following steps, for example: a data verification of the data classified as untrustworthy by the Z2-Proxy_l2, in particular by default, and - in the case of successful data- Verification - the processing or forwarding of the data now classified as trustworthy (after data verification) within the second zone Z2.
  • the method further comprises: exchanging first data between different zones via a buffer memory, in particular working memory, wherein in particular exchanging the first data between the first zone Z1 and the second zone Z2 comprises the following steps: copying the first data into a first buffer memory area assigned to the first zone, checking the copied first data and, in particular depending on the check, copying the first data from the first buffer memory area assigned to the first zone Z1 into a second buffer memory area assigned to the second zone Z2.
  • the computing core 102a according to FIG. 3 can be used, for example, for a network switch, for example to send and / or receive Ethernet data packets.
  • Corresponding instances of application programs AP are identified by the reference symbols 11 (receiving Ethernet packets, execution in zone Z1), I2 (receiving Ethernet packets, execution in zone Z2), I3 (sending Ethernet packets, execution in zone Z1), I4 ( Sending Ethernet packets, execution in zone Z2) marked.
  • Another application program AP5 which, for example, carries out management tasks for the network switch 48, runs only in the second zone Z2 defined as trustworthy, but not in the first zone Z1 defined as untrustworthy.
  • Ethernet sensors 38 are arranged in the first zone Z1, which is defined as untrustworthy.
  • Ethernet sensors 40 are arranged in the second zone Z2 defined as trustworthy.
  • host sensors 42 are arranged in the first zone Z1 defined as untrustworthy.
  • the host sensors 43 of the untrustworthy zone Z1 can optionally be provided.
  • Host sensors 45 are arranged in the second zone Z2 defined as trustworthy.
  • the sensors can therefore be arranged in the trustworthy and / or untrustworthy zone Z1, Z2.
  • a RAM 1030 which in further preferred embodiments can be divided up, is assigned to the computing core 102a.
  • a switching engine eg coupling network
  • TCAM ternary content-addressable memory
  • ACL access control list
  • the switching engine SE or the TCAM / ACL module are hardware modules 42.
  • Corresponding filter rules can be configured in the TCAM / ACL module so that the TCAM / ACL module is used as a sensor in order to detect anomalies .
  • the correspondingly configured filter rules in this hardware module 42 correspond to those of the sensors 24, 26, 28 described. If this filter rule detects an anomaly, an event 220 can be generated and / or the anomaly can be blocked. If an event 220 is generated, an interrupt can be triggered by the hardware module 42 so that the anomaly can be logged as an event 220 on the software side.
  • CAN hardware transceivers on a main controller, where filter rules for the sensors can be configured in hardware.
  • an interrupt 44 is indicated, which can be triggered, for example, in terms of software, in terms of hardware, as described, or by a timer.
  • the components mentioned are part of the electronics unit 48 or the switch.
  • a computing unit 100b main controller
  • the processing unit 100b is able to communicate with other IDS entities 34. The communication could take place from the processing unit 100 b to other IDS entities 34, for example via CAN or from the computing unit 100 b via the switch 48 to other IDS entities 34.
  • the electronics unit 48 in turn sends Ethernet events 220 from the switch SWT 48 to the Computing unit 100 b.
  • the inter-zone communication from the untrustworthy zone Z1 to the trustworthy zone Z2 is via the ETH sensors 40 of the trustworthy zone Z2 and / or via the sensors 42 implemented by hardware filter rules and / or by ETH sensors 40 of the untrustworthy ones Zone Z1 and / or the host sensors 45 of the trusted zone Z2 controlled. If the inter-zone communication or the zone transition from Z1 to Z2 takes place on the switch 48, only the necessary minimum of data that is required in the trustworthy zone Z2 is transmitted between the two zones Z1 and Z2.
  • the log is defragmented to the necessary minimum in the untrustworthy zone Z1; plausibility checks are also carried out during the defragmentation (to detect anomalies). This is done via the Z1 Ethernet sensors 38.
  • the necessary minimum of data is checked for plausibility by the Z2 Ethernet sensors 40.
  • the host sensors 43, 45 of the BS or SV also check whether there is no invalid zone transition and / or change in the program sequence (e.g. by checking the Return address on the stack) has taken place.
  • the ETH sensor 40 In the event that no anomalies were detected, the ETH sensor 40 enables the trustworthy zone Z2 to use the data in the trustworthy zone Z2. The data are classified as trustworthy data. In the event that anomalies have been detected, the ETH sensor 40 discards the data and / or generates an event 220. In addition, the ETH sensor 40 communicates the anomalies or the associated event 220 to the computing unit 100b of the trustworthy zone Z2 or to the associated event manager 30 of the trusted zone Z2. The sensor logic of the ETH sensor 40 is in the trustworthy zone Z2, since the events must be evaluated by a trustworthy entity.
  • the switch 48 SWT forwards the communication of the processing unit 100b of the untrustworthy zone Z1 via the communication adapter 32 to the further IDS entities 34.
  • the communication adapter 32 is located in the processing unit 100b. It cyclically requests the event report 242 from the event manager 30 and communicates it to the other IDS entities 34. If the communication takes place via Ethernet to the other IDS entities 34 (which is the preferred variant), then this would be from the communication adapter 32 of the main microcontroller or computing unit 100b to the further IDS entities 34 via switch 48.
  • FIG. 4 schematically shows a simplified block diagram of aspects of a computing device 100b in accordance with further preferred embodiments.
  • the computing device 100b has, by way of example, four computing cores K1, K2, K3, K4, of which the first computing core K1 is designed to process communication messages, in particular CAN messages. Therefore, in further preferred embodiments, the first computing core K1 can also be referred to as a “CAN core”.
  • the further computing cores K2, K3 are provided for executing (possibly different instances of) application programs and in further preferred embodiments can therefore also be referred to as “application cores” K2, K3.
  • the fourth computation core K4 is designed to process Ethernet communication messages and can therefore, in further preferred embodiments, also be referred to as the Ethernet core or ETH core or, in English, “ETH core” K4.
  • a first supervisor SV1 in particular a CAN lightweight supervisor, is assigned to the first computing core K1
  • a second supervisor SV2, in particular an ETH (Ethernet) lightweight supervisor is assigned to the fourth computing core K4.
  • the first computing core K1 is assigned to two zones Z1, Z2.
  • the fourth computing core K4 is also assigned to two zones Z1, Z2.
  • the first computing core K1 is an application program AP for sending and / or receiving CAN Messages assigned, the reference numeral 11 denoting a first instance of this application program, which first instance 11 is assigned to the first zone Z1 and is designed to receive CAN messages.
  • the reference symbol I2 denotes a second instance of this application program which is assigned to the second zone Z2 and is designed to receive CAN messages.
  • the reference symbols I3, I4 denote corresponding entities for sending CAN messages, which are each also assigned to one of the two zones Z1, Z2.
  • the computing core K1 can include CAN sensors 60 which are arranged in the trustworthy zone Z2.
  • CAN sensors 62 can also be provided in the untrustworthy zone Z1 in the computing core K1.
  • the interrupt requests Rx, timer, SW can be processed by the first computing core K1, for example by executing a corresponding interrupt routine.
  • the fourth computing core K4 is assigned an application program for sending and / or receiving Ethernet messages, the reference numeral 11 denoting a first instance of this application program, which first instance 11 is assigned to the first zone Z1 and for receiving Ethernet messages is trained.
  • the reference symbol I2 denotes a second instance of this application program which is assigned to the second zone Z2 and is designed to receive Ethernet messages.
  • the reference symbols I3, I4 denote corresponding entities for sending Ethernet messages, which are each also assigned to one of the two zones Z1, Z2.
  • the two zones Z1, Z2 are separated within the computing cores K1, K4 using at least one memory protection device SSE1, SSE4.
  • the two application cores K2, K3 are designed to execute application programs, which or their individual instances are indicated as rectangles within the relevant application cores K2, K3.
  • the second computing core K2 is assigned to the second zone Z2, and the third computing core K3 is assigned to the first zone Z1.
  • DPI sensors 64 deep package inspection for a more detailed payload analysis
  • event manager 30 communication adapter 32
  • proxies 70 BSW stack 72
  • BSW basic software
  • V-CAN 74 virtual CAN
  • V -ETH 76 virtual Ethernet
  • DPI sensors 84 In the computing core K3, DPI sensors 84, communication adapters 32, proxies 90, BSW stack 92, V-CAN 94 and V-ETH 96 are provided by way of example. As already described, the communication adapter 32 is located both in the trusted zone Z2 and in the untrusted zone Z1.
  • the computing device 100b has a volatile memory, in particular a main memory (RAM) 1030b, which, for example, is divided into different areas in a manner comparable to the illustration according to FIG. whose zones Z1, Z2 are assigned.
  • RAM main memory
  • a first area B1 of the main memory 1030b of the computing device 100b according to FIG. 13 is assigned to the first computing core K1, a first subarea B1_1 being assigned to the first zone Z1 and a second subarea B1_2 to the second zone Z2.
  • the first sub-area B1_1 is in turn divided into a trustworthy area and an untrustworthy area, separated by a memory protection device SSE.
  • the second sub-area B 1_2 is in turn subdivided into at least one trustworthy area and one untrustworthy area, again separated by a memory protection device SSE.
  • a comparable division into corresponding areas or sub-areas B4, B4_1, B4_2 is also possible for the fourth computation kernel K4 in further preferred embodiments.
  • the first sub-area B4_1 is in turn divided into a trustworthy area Tb1b and an untrustworthy area Tb1a, separated by a memory protection device SSE.
  • the second sub-area B4_2 is in turn divided into at least one trustworthy area Tb2a and one untrustworthy area Tb2b, again separated by a memory protection device SSE.
  • further areas B2, B3 of the main memory 1030b are, for example, the application cores K2, K3 assignable.
  • the area B2 can be further divided into a trustworthy area T and a non-trustworthy area NT.
  • the same can also apply to the third application core K3.
  • one or more further memory protection devices which are collectively designated with the reference symbol SSE ', can be provided in order to implement a respective separation according to preferred embodiments with regard to, for example, read rights and / or write rights and / or execution rights.
  • the computing device 100b can, for example, provide the functionality of a gateway, i.e. a network coupling element that can, for example, couple a CAN bus (cf. CAN Core K1) to an Ethernet network (cf. ETH Core K4) .
  • a gateway i.e. a network coupling element that can, for example, couple a CAN bus (cf. CAN Core K1) to an Ethernet network (cf. ETH Core K4) .
  • the first computing core K1 can assume the function of a so-called high-speed routing engine for CAN messages, and / or the fourth computing core K4 the function of a so-called high-speed engine for Ethernet messages.
  • the switch SWT 48 in particular an Ethernet switch, transmits Ethernet events to the computing core K4, which is responsible for handling the Ethernet communication.
  • the computing core K4 communicates with other IDS entities 32.
  • the data can be shifted from the proxy 90 of the untrusted zone Z1 to an isolated buffer memory in the untrusted area of the zone Z1.
  • the sensor 60 assigned to the trustworthy zone Z2 validates this data before use in the trustworthy zone Z2. If no anomalies are detected, the sensor 60 enables the trustworthy zone Z2 to use this data for the trustworthy zone Z2 (trusted data). If anomalies or unexpected events are detected, the sensor 60, which is assigned to the trustworthy zone Z2, discards the data. In addition, the sensor 60 communicates, the Trusted zone Z2 is assigned, the detected anomalies as event 220 to the event manager of the trustworthy zone Z2.
  • the logic of the sensor 60 is arranged in the trustworthy zone Z2 because the corresponding events must be evaluated by a trustworthy entity. Furthermore, communication can take place between trustworthy zone Z2 and untrustworthy zone Z1. In addition, communication from the trustworthy zone Z2 to the untrustworthy zone Z1 can easily take place. Further sensors 62 can optionally be provided.
  • Communication from the untrustworthy zone Z1 to the trustworthy zone Z2 can - as already stated - also be monitored by sensors in the untrustworthy zone Z1 and the trustworthy zone Z2. Data that are no longer available after the defragmentation or are not required in the trustworthy zone Z2 are monitored by sensors 38, 62 arranged in the untrustworthy zone Z1. The sensors 40, 60 arranged in the trustworthy zone Z2 then monitor the data which is transmitted after the defragmentation (the necessary minimum of data) from the untrustworthy zone Z1 into the trustworthy zone Z2.
  • the event manager 30 of the trustworthy zone Z2 aggregates, reduces or prioritizes, formats or persists incoming events 220.
  • the event manager 66 is arranged in the trustworthy zone Z2, since the events must be processed, prioritized and stored by a trustworthy instance.
  • the communication adapter 32 is partly arranged in the trustworthy zone Z2.
  • the communication adapter 32 controls the communication with the event manager 30, which is also arranged in the trustworthy zone Z2.
  • the communication adapter 32 takes over the communication to an HSM (Hardware Security Module, which the Authentication and / or encryption) to ensure a secure, authenticated and confidential channel to the higher-level IDS instance 34.
  • the communication adapter 32 is partly arranged in the trustworthy zone Z2 because it also has to communicate with trustworthy entities such as, for example, the event manager 30 of the trustworthy zone Z2 or the HSM.
  • the communication adapter 32 is intended to take over the communication to other IDS entities 34 such as, for example, infotainment via the switch SWT 48. Since it communicates with untrustworthy entities (infotainment, CCU), it is partially arranged in the untrustworthy zone Z1.
  • a communication sequence is decided in which the event report 242 is sent cyclically to the higher-level entity 34.
  • the communication adapter 32 from the trustworthy zone Z2 asks the event manager 30 in the trustworthy zone Z2 to provide selected events 226 in the buffer memory 206 as described by way of example in connection with FIG.
  • the event report 242 contains certain particularly trustworthy information with regard to encryption and / or authentication, in particular the variable variable 254 and / or the authentication information 256 and / or the encryption 258.
  • These variables can be provided by the security module 73, which has already been described above as HSM (Hardware Security Module).
  • the security module 73 for example accommodated in the so-called BSW stack 72, supplies, for example, a corresponding random number 273 or a section of such a random number as a variable variable 254 Event report 242.
  • the event report 242 arrives in plain text again at the security module 73, which carries out the encryption by the key 258 and makes it available to the communication adapter 32 of the trustworthy zone Z2.
  • the event report 242 encrypted in this way now reaches the no longer trustworthy area Z1, that is to say to the core K3, via the communication adapter 32. Accordingly, the event report 242 is put into the buffer written in zone B3.
  • the event report 242 could, as already stated, be communicated to the higher-level entity 32 via the Ethernet core K4, as indicated by the corresponding arrow.
  • the event report 242 is transferred from the memory in the area B3 to the memory area B4_1, so it is now in the Ethernet core K4.
  • the further communication takes place from K4 via the transmission process I3, for example via the Ethernet switch 48 etc. to the higher-level entity 32 connected via Ethernet.
  • the following communication sequence describes the receipt of a confirmation signal 408, 416 that was generated by the higher-level entity 34 (as described in more detail below in connection with FIGS. 5-10).
  • the corresponding confirmation signal 408, 416 arrives via the Ethernet switch 48 to the Ethernet core K4 and there into the untrustworthy zone Z1.
  • the data are first buffered in the area B3, there in the untrustworthy area NT.
  • the communication adapter 32 of the trustworthy zone Z2 has access to the data isolated there.
  • the communication adapter 32 of the trusted zone Z2 recognizes that the data is encrypted.
  • the decryption now takes place in that the communication adapter 32 of the trustworthy zone Z2 sends the data for decryption to the security module 73 or assigns the corresponding security module 73 access to the data.
  • the signal decrypted by the security module 73 then arrives back in plain text at the communication adapter 32 of the trustworthy zone Z2.
  • the communication adapter 32 recognizes that further security-relevant information such as the variable variable 254 'and / or authentication information 256' are part of the confirmation signal 408, 416 (see FIG. 5).
  • the variable variable 254 'of the confirmation signal 408, 416 was formed by the higher-level entity 34 in such a way that the variable variable 254 as transmitted by the last event report 242 (and also generated by the security module 73) as variable variable 254' for the confirmation signal 408, 416 was used.
  • the security module 73 thus carries out a corresponding check as to whether the variable variable 254 'of the confirmation signal 408, 416 corresponds to the variable size 254, in particular of the last event report 242. If this is the case, corresponding release information for the confirmation signal 408, 416 can be generated.
  • the communication adapter 32 of the trustworthy zone Z2 sends, for example, a signal 410 to the event manager 30 to delete the events 226 in the buffer memory 206 transmitted as part of the last event report 242.
  • the corresponding authentication information 256 ′ could additionally also be used for a verification or authentication of the received confirmation signal 408, 416 as described.
  • the communication from the control device such as the gateway 20 to further IDS instance (s) 34 should ensure that the further IDS instance 34 or the event logger have unread entries or events 236 or selected events 226 stored in memory 206 are informed.
  • the control device or the gateway 20 should send an event report 242 on a regular basis to the further IDS instance 34, preferably via a so-called heartbeat signal (cyclical signal which can be used to check a proper connection between the communication participants).
  • the heartbeat signal (including the event report 242) should be encrypted and authentic.
  • the transmitted information should preferably be exchanged authentically (possibly using the authentication information 256) and encrypted, preferably randomly or using a random number 273 between the control device or gateway 20 and the further IDS entity 34.
  • the event report 242 should be of a fixed length 257, should be encrypted and authenticated. Each encrypted event report 242 should be different from the previous event reports 242, even if the transmitted status has not changed.
  • the communication from the further IDS instance 34 to the control device or gateway 20 or the associated communication adapter 32 should also be characterized by the following functionalities.
  • the data logger or the IDS instance 34 should record the events 236 or associated event reports 242 as quickly as possible in order to prevent the memory or buffer memory 206 in particular from overflowing.
  • the event reports 242 should be able to be read out via a diagnostic interface, for example on request. Alternatively, the event report 242 could be sent completely cyclically.
  • the event reports 242 should be communicated or read out on a regular basis, preferably authentically and encrypted or camouflaged, even if no new selected events 226 are available in the context of a new event report 242.
  • the control device or gateway 20 should respond to a read request 240 with a response or an event report 242 with a fixed length, encrypted and authenticated.
  • Each encrypted response or event report 242 is intended to differ from the previous responses or event reports 242, even if the content has not changed. This is done, for example, by the constantly changing size 254, as already described.
  • the event manager 30 arranged in the trustworthy zone Z2 first selects a first selected event 226.1 and then a second selected event 226.2. These are processed by the event manager 30 as described.
  • the selected events 226.1, 226.2 are therefore stored in the memory 206.
  • the part of the communication adapter 32 located in the trustworthy zone Z2 contains a signal 400, a time-dependent interrupt signal (timer IRQ).
  • the time-dependent signal 400 is preferably formed cyclically, so that the transmission of an event report 242 from the communication adapter 32 to further IDS entities 34 in the vehicle 18 is thereby initiated cyclically.
  • a signal in the form of a “normal” event report 242 is sent from the communication adapter 32 to the further IDS instance 34 as described below (compare signal 406).
  • the transmission of an event report 242 is not triggered as a function of the receipt of an event 220 or selected event 226, but rather cyclically (by the lapse of the cycle time). This is particularly advantageous, since the transmission to further IDS instances 34 and / or the backend 36 is always carried out cyclically, that is, after a certain time has elapsed.
  • the behavior of the event manager 30 or anomaly detection is thus opaque to an attacker. The attacker never knows whether his attack was detected, what was detected and how the anomaly detection system works.
  • the part of the communication adapter 32 located in the trustworthy zone Z2 requests an event report 242 from the event manager 30, signal 402 selected events 226.1 and / or 226.2 (with respective generic metadata 217 and event-dependent metadata 216) and a changed size 254.
  • Corresponding filler data 255 are also added so that the fixed length 257 of the event report 242 is reached (with knowledge of the length of the authentication information 256 still to be created).
  • the event manager 30 generates authentication information 256 from the changed information 254, the selected events 226.1, 226.2 and the filler data 255 using a specific algorithm.
  • the authentication information 256 formed in this way completes the event report 242.
  • the complete event report 242 is then encrypted with the key 258.
  • the encrypted event report 242 reaches the part of the communication adapter 32 located in the trustworthy zone Z2 as a signal 404 the changed information 254 and / or the key 258) and authentication (formation of the authentication information 256) could be in the event manager 30 and / or in the communication adapter 32 or using the security module 73 (also arranged in the trustworthy zone Z2) as already described take place when the corresponding safety requirements are met.
  • the communication adapter 32 and / or the security module 73 could encrypt the event report 242, for example as a function of a random number 273.
  • a new random number 273 is always formed for encryption, for example by hashing. This makes it difficult Furthermore, the decryption of a transmitted message or the encrypted event report 242.
  • the communication adapter 33 takes over the authentication using the authentication information 256 and / or the addition of the variable variable 254 and / or the final encryption of the entire event report 242 with the encryption 258.
  • a corresponding signal 406 is sent to the timer interrupt (signal 400) even if no new event report 242 is made available by the event manager 30 due to the occurrence of new selected events 226. Then a dummy message with the data format of an event report 242 is used and encrypted by a random number or the constantly changing size 254 (using the key 258) is transmitted to the further IDS entity 34. Dummy messages are also always encrypted by constantly changing sizes 254 or new random numbers, so that even if new selected events 226 do not occur, other or encrypted messages (signal 406) are always transmitted cyclically. As a result of the cyclical transmission, the functioning of a proper communication connection between the communication adapter 32 and the further IDS entity 34 can be checked. As already described, the event report 242 is sent via that part of the communication adapter 32 arranged in the untrustworthy zone Z1.
  • the further IDS entity 34 sends a confirmation signal (408) to the communication adapter 32, in particular to that part of the communication adapter 32 located in the untrustworthy zone Z1
  • a confirmation signal (408)
  • the part of the communication adapter 32 arranged in the trustworthy zone Z2 generates a request to the event manager 30 to delete or overwrite the temporarily stored, possibly reduced, selected events 226 or associated event reports 242 (signal 410).
  • the superordinate entity 34 and / or the backend 36 checks the authenticity of the received encrypted event report 242.
  • the superordinate entity 34 and / or the backend 36 decrypts the received message, namely the encrypted event report 242, using the known key 258.
  • Event report 242 is then available in plain text.
  • the event report 242 is authenticated using the corresponding algorithm (which was also used by the event manager 30 or communication adapter 32 to create the authentication information 256) to form the authentication information 256.
  • all the data of the received and decrypted event report 242 (with the exception of the authentication information 256) are used again and a corresponding authentication information 256 'is formed therefrom.
  • the authentication information 256 'formed is then compared with the authentication information 256 received in the context of the event report 242. If there is a match, the received event report 246 is considered authentic.
  • the signal 408 (confirmation signal) is only sent to the communication adapter 32 when the authentication is successful, which then sends the signal 410 to the event manager 30 to enable the overwriting of the selected events 226.1, 226.2.
  • the response or the confirmation signal 408, 416 should preferably also have a fixed length 257 ‘.
  • the confirmation signal 408 should preferably be authenticated and encrypted. Each response or confirmation signal 408 by the higher-level entity 34 and / or the backend 36 should differ, even if the content has not changed.
  • the confirmation signal 408, 416 has a similar structure to the event report 242.
  • the confirmation signal 408, 416 comprises a variable variable 254 '.
  • the variable variable 254 ' changes for each newly sent confirmation signal 408, 416.
  • the variable variable 254' could again, for example, can be realized by a random number, a counter, a time.
  • variable variable 254 of the confirmation signal 408, 416 could particularly preferably be formed in that the variable variable 254 of the event report 242 is transmitted as just above and, if necessary, generated by the security module 73, is used.
  • the higher-level entity 34, 36 is set up to extract the variable variable 254 from the received event report 242 and to insert it into the confirmation signal 408, 416.
  • Authentication of the confirmation signal 408, 416 could thus also take place in a subsequent step by comparing the received variable variable 254 ‘of the confirmation signal 408, 416 with the variable variable 254 of the previously sent event report 242. If there is a match, an authentic confirmation signal 406, 408 is inferred.
  • the variable variable 254 ‘does not have to be generated in the higher-level instance 34, 36 itself. This can be followed by the release of the memory 206.
  • the confirmation signal 408, 416 also includes certain data 255, for example in the form of any pattern.
  • the confirmation signal 408, 416 also includes authentication information 256 ‘.
  • the authentication information 256 ‘could be formed similarly to the event report 242 again via a specific algorithm that accesses the remaining data of the confirmation signal 408, 416, namely the variable variable 254‘ and the data 255 ‘.
  • the authentication information 256 formed in this way completes the confirmation signal 408, 416. It has a fixed length 257 ‘. Encryption then takes place using a key 258 ‘. This encryption 258 ‘could optionally also be dispensed with.
  • the receiving entities for example the higher-level entity 34, the backend 36 and / or the communication adapter 32 or the event manager 30 are in turn able to decrypt the confirmation signal 408, 412 (using the key 258 ') and to authenticate it.
  • the received data (variable size 254 ', data 255') is again derived from this using a correspondingly known algorithm resulting authentication information 256 'is determined and compared with the received authentication information 256'. If they match, authenticity is assumed. If the received authentication information 256 ′ is correct, the signal 410 for enabling the memory 206 could be generated. If the authentication information 256 'is not in order, this signal 410 could not be generated, so that the selected events 226 contained in the memory 206 are not (yet) deleted.
  • the further IDS instance 34 also receives a timer interrupt signal 412 cyclically, which is formed similarly to the signal 400 as already described. In response to this interrupt signal 412, the further IDS instance 34 in turn sends an encrypted message, signal 414.
  • This message may contain the event report 242 or a vehicle-related event report (including further event reports) as transmitted via signal 406 in front of the communication adapter 32.
  • the message is encrypted by the further IDS instance 34, in particular by a constantly changing variable 254 'such as a random number 273.
  • the communication adapter 32 has not transmitted an event report 242, because, for example, no new selected event 226 occurred, In turn, a dummy message with the same data format as an event report 242 is used and transmitted in encrypted form to the backend 36 (signal 414).
  • the backend 36 sends a confirmation signal 416 and / or a further message or request to overwrite the events 236 or the like temporarily stored in the buffer memory 206 to the further IDS entity 34.
  • the confirmation signal 416 can be formed as described above.
  • the event manager 30 After receiving the signal 410 relating to the event release, the event manager 30 selects further selected events 226.3 and 226.4. The further process can be seen in FIG. 6. In the meantime, the event manager 30 also selected a further event 226.5. Again, a timer interrupt (signal 420) arrives at the communication adapter 32. This now requests an event report 242 for the gateway 20 (signal 422). The event manager 30 sends to the communication adapter 32 an event report 242 which is based on the selected events 226.3, 226.4, 226.5, signal 424. After Receipt of the event report 242, the communication adapter 32 sends the event report 242 encrypted and authenticated by a new variable 254 such as a random number to the further IDS entity 34, signal 426.
  • a new variable 254 such as a random number
  • the receipt is confirmed by the further IDS entity 34 with a confirmation signal 428.
  • the actuation signal 428 can be formed as described in connection with actuation signal 408 ( Figure 5).
  • the communication adapter 32 again sends a request to the event manager 30 to overwrite or delete the selected events 226.3, 226.4, 226.5 on which the event report 242 is based, signal 430.
  • a further selected event 226.6 is selected in the meantime.
  • this selected event 226.6 must not yet be overwritten, since this selected event 226.6 was not yet the basis for an event report 242 already transmitted to the communication adapter 32.
  • the signal 430 does not relate to overwriting the selected event 226.6, but rather merely overwriting those selected events 226.3, 226.4, 226.5 that were already transmitted in the context of the last event report 242.
  • a timer interrupt also occurs in the further IDS instance 34 (signal 432), as already described.
  • This causes the further IDS entity 34 to transmit the event report 242 newly received in signal 426 in encrypted form to the backend 36, signal 434.
  • the receipt of the corresponding message 434 is acknowledged by the backend 36 with a corresponding confirmation signal 436, which is sent to the further IDS entity 34 is sent.
  • the confirmation signal 436 could be formed like the confirmation signal 408 or 416.
  • the further sequence is shown in FIG. Another timer interrupt occurs for the communication adapter 32, signal 440.
  • the communication adapter 32 then sends a request from the trusted zone Z2 to the event manager 30 to send an event report 242, signal 442.
  • the event manager 30 sends an event report 242 that contains the Intermediate selected event 226.6 includes, signal 444.
  • the communication adapter 32 encrypts the event report 242 using a new variable variable 256, possibly using the security module 73, and sends the encrypted event report 242 via the part of the communication adapter 32 located in the untrustworthy zone Z1 to the further IDS entity 34, signal 446.
  • the further IDS entity 34 Upon receipt, the further IDS entity 34 sends a confirmation, signal 448, upon receipt of which the communication adapter 32 sends a request to the event manager 30 to overwrite or release the events 226.6 already transmitted, 450.
  • the further IDS instance 34 again receives a timer interrupt, signal 452.
  • the encrypted event report 242 is then transmitted to the backend 36 in a vehicle-related manner together with further event reports from further IDS systems.
  • the backend 36 sends a confirmation signal and / or a request to release or overwrite etc., signal 456, to the further IDS instance (s) 34.
  • no new selected event 226 has occurred between the sending of the last event report 242 and the new occurrence of a timer interrupt (signal 460).
  • the communication adapter 32 After receiving the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 for a new event report 242 to the event manager 30 from the trustworthy zone Z2.
  • the event manager 30 generates - although a new selected event 226 has occurred - an event report 242 with a dummy content , which is then sent to the communication adapter 32, signal 464.
  • This dummy content can be recognized as such by the further IDS instances 34 and / or by the backend 36.
  • the communication adapter 32 encrypts in the trustworthy zone Z2, possibly using the security module 73, the received event report 242, which has a dummy content, with a new changed size 254, sends and sends the encrypted and authenticated event report 242 to the further IDS instance 34, signal 466.
  • the sending takes place again from the untrustworthy zone Z1.
  • the receipt is confirmed by the further IDS instance 34, signal 468.
  • the communication adapter 32 again sends a request signal to the event manager 30 to overwrite the last selected events 226, signal 470. This takes place itself when there are no new selected events 226 as in this constellation.
  • the further IDS instance 34 again receives a timer interrupt, signal 472.
  • the further IDS instance 34 then encrypts the most recently received encrypted event report 242 as transmitted by the communication adapter 32 and sends it, if necessary, with further event reports from further IDS systems to the backend 36 in relation to the vehicle
  • the backend 36 sends a confirmation signal 476 and / or a request to release the underlying events etc. to the further IDS entity 34.
  • communication adapter 32 again receives a timer interrupt, signal 480.
  • This timer interrupt 480 can be a special signal so that communication adapter 32 requests an event summary from event manager 30 (and not one of the usual event reports 242), signal 482.
  • the event manager 30 sends the event summary to the communication adapter 32, signal 484. This takes place again in the trustworthy zone Z2.
  • the event summary can contain higher-level information such as the various counter readings 231 for the various event types 218, or the occurrence of a new event type etc.
  • Security module 73 encrypted in the security-relevant zone Z2 and transmitted to further IDS instances 34, signal 486. The transmission takes place again from the non-security-relevant zone Z1.
  • the further IDS instance 34 sends the event summary on to the backend 36, particularly preferably in encrypted form.
  • no timer interrupt for initiating the communication process is provided for the transmission process between the further IDS instance 34 and the backend 36.
  • this could in turn be initiated cyclically as well as the transmission of a customary event report.
  • the backend 36 sends a request for an event report to the further IDS instance 34, signal 490.
  • the further IDS instance 34 sends an encrypted request for an event report, for example via a diagnostic interface, to the communication adapter 32, signal 492.
  • the encryption can again take place via the variable variable 254 ', such as a random number, for example, which changes in particular for each encryption.
  • the communication adapter 32 in the security-relevant zone Z2 sends a request for an event report 242 to the event manager 30, signal 494.
  • the event manager 30 sends the event report 242 to the communication adapter 32, signal 496 Communication adapter 32 encrypts the event report 242, for example using a new variable 254 such as a random number, possibly using the security module 73, and sends it from the non-security-relevant zone Z1 to the further IDS instance 34, signal 498.
  • the encrypted event report 242 sends the further IDS instance 34 the event report 242 to the backend 36.
  • the receipt acknowledges the 36 backend to the further IDS instance 34, signal 492.
  • the receipt of the acknowledgment signal 492 confirms the further IDS instance 34 the communication adapter 32, signal 494.
  • the communication adapter 32 After receiving the appropriate Signal 494, the communication adapter 32 sends a corresponding request to the event manager 30 to release or overwrite at least the events 220 transmitted in the context of the last event report 242.
  • the described methods can be implemented in a processing unit, computer or controller, in particular in a control unit of a vehicle 18.
  • the method can likewise be created in the context of a computer program that is set up to carry out the method when it is carried out on a computer.
  • the computer program can be stored on a machine-readable storage medium.
  • the program can be uploaded as software "over-the-air" wirelessly or via diagnostic interfaces using cables.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Es wird ein Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug, vorgeschlagen, wobei mindestens ein Sensor (24,26, 28) zur Anomalieerkennung Daten (211) erhält erhält, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht und bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und an einen Ereignismanager (30) weiterleitet, wobei eine zumindest eine vertrauenswürdige Zone (Z2) und eine nicht vertrauenswürdige Zone (Z1) vorgesehen werden, wobei zumindest ein Sensor (24,26, 28; 40, 60) und der Ereignismanager (30) der vertrauenswürdigen Zone (Z2) zugeordnet sind.

Description

Beschreibung
Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem
Kraftfahrzeug
Technisches Gebiet
Die Erfindung betrifft ein Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug.
Stand der Technik
Aus der DE 102018209407 A1 sind bereits eine Vorrichtung und ein Verfahren zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk, insbesondere eines Kraftfahrzeugs bekannt. Wenigstens ein Detektor analysiert einen Datenstrom im Kommunikationsnetzwerk, wobei der wenigstens eine Detektor wenigstens eine Anomalie durch ein regelbasiertes Anomalieerkennungsverfahren erkennt, wenn wenigstens ein Parameter für ein Datenpaket des Datenstroms von einem Sollwert abweicht, wobei der wenigstens eine Detektor Information über wenigstens eine erkannte Anomalie über das Kommunikationsnetzwerk sendet.
Die automatische Erstellung eines Protokolls, Historie oder Bericht (Logging) insbesondere bei erkannten Anomalien bzw. Ereignissen soll bei hohen Ereignis- Raten und/oder langanhaltenden Angriffen ohne Überlast und Ablehnung entsprechender Services erfolgen. Die Einträge des Loggings bzw. entsprechender Ereignisberichte sollen authentisch, integer und verfügbar sein. Wenn möglich soll eine für den Angreifer nicht deterministische Historie über einen kompletten (langen andauernden) Angriff erstellt werden. Manipulationen und insbesondere das Löschen durch einen Angreifer soll vermieden werden. Außerhalb eines Steuergeräts sollen die Logging-Einträge vor unberechtigter Analyse geschützt werden. Der Logger soll die Ereignisberichte zuverlässig beispielsweise über eine Schnittstelle zu einem externen Knoten senden. Nach einer erfolgreichen Übertragung an den externen Knoten können die Ereignis- Einträge lokal gelöscht werden, besonders bevorzugt nach einer insbesondere authentifizierten Bestätigung durch die empfangende Instanz. Weiterhin sollte der Logger ein sogenanntes Heartbeat-Signal senden, welches eine Netzverbindung anzeigt. Die Ansammlung von Ereignissen sollte möglich sein, um die Anzahl der zu bearbeitenden Logging-Einträge zu reduzieren.
Unter normalen Betriebsbedingungen werden Ereignisse (Events) nicht oder kaum getriggert, beispielsweise in der Größenordnung von einem Ereigns pro Stunde. Im schlimmsten Fall hat ein Angreifer die volle Kontrolle über eine Schnittstelle, insbesondere Ethernet-Schnittstelle. Bei einer vollen Bandbreite von beispielsweise 100 Mbit könnte ein Angreifer maximal 128.000 UDP (User Datagram Protocol, ein Netzwerkprotokoll)-Frames pro Sekunde senden. Jeder solcher Frames könnte möglicherweise ein Ereignis (erkannte Anomalie in einem Datenstrom) triggern. Solch ein Angriff wird mit einer Häufigkeit von einer Attacke über die Lebensdauer eines Fahrzeugs angenommen. Die erlaubte Anzahl der sogenannten Schreibzyklen eines Speichers, insbesondere eines Flash- Speichers, ist begrenzt und muss berücksichtigt werden. Ebenfalls ist die Anzahl der aktiven Betriebsstunden begrenzt. Ebenfalls ist die Verfügbarkeit des übergeordneten externen Daten-Loggers begrenzt. Deshalb müssen entsprechende Logging-Events bzw. Ereignisberichte zwischengespeichert werden. Sämtliche Logging-Einträge bzw. Ereignisberichte sollten zu dem übergeordneten Daten-Logger transferiert werden können zumindest einmal am Tag.
Für herkömmliche IDS-oder IDPS-Systeme (Intrusion Detection System, Eindringungserkennung, ein System zur automatisierten Erkennung von Angriffen auf Computernetzwerke bzw. Rechnerschnittstellen; bzw. IDPS: Intrusion Detection Prevention System, bei einem erkannten Eindringungsversuch werden entsprechende Daten nicht weitergeleitet und damit der Eindringungsversuch unterbunden) sind oftmals deterministisches Verhalten und die begrenzten Ressourcen der eingebetteten Systeme problematisch. Wünschenswert ist es demgegenüber ein verbessertes Verfahren zur Anomalieerkennung anzugeben. Diese Aufgabe wird gelöst durch die Merkmale des unabhängigen Anspruchs.
Offenbarung der Erfindung
Dies wird durch das Verfahren nach dem unabhängigen Anspruch erreicht.
Dadurch, dass zumindest eine vertrauenswürdige Zone und eine nicht vertrauenswürdige Zone vorgesehen werden, wobei zumindest ein Sensor und der Ereignismanager der vertrauenswürdigen Zone zugeordnet sind, kann mithilfe eines 2-stufiges Sicherheitskonzepts der Manipulationsschutz weiter erhöht werden. Insbesondere die Anordnung von Sensor und/oder Ereignismanager in der vertrauenswürdigen Zone als vertrauenswürdige Instanz erschwert Zugriffsmöglichkeiten auf sensible Daten und Manipulationsmöglichkeiten.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zumindest ein Kommunikationsadapter in derselben Zone angeordnet ist wie der Ereignismanager, wobei der Kommunikationsadapter der Kommunikation eines von dem Ereignismanager zumindest teilweise erstellten Ereignisberichts dient. Damit kann der Kommunikationsadapter die Überprüfung eines Datentransfers in die andere Zone vornehmen, während er innerhalb der sicherheitsrelevanten Zone mit Ereignismanager und/oder Sensor kommunizieren kann.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Kommunikationsadapter auch einer nicht vertrauenswürdigen Zone zugeordnet wird. Über diesen Teil erfolgt die Kommunikation mit der übergeordneten IDS Instanz, die in der Regel nicht vertrauenswürdige Instanzen darstellen.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Sensor in der vertrauenswürdigen Zone zumindest Daten, insbesondere defragmentierte Daten, von einem Sensor enthält, der in der nicht vertrauenswürdigen Zone angeordnet ist, wobei der Sensor in der vertrauenswürdigen Zone die erhaltenen Daten auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis erzeugt und/oder wobei der Sensor in der nicht vertrauenswürdigen Zone die erhaltenen Daten auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis erzeugt. Damit gelangen in die vertrauenswürdige Zone lediglich Daten, die unbedingt für die Weiterverarbeitung im Ereignismanager benötigt werden. Die Manipulationsmöglichkeiten werden dadurch weiter reduziert.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass ein Versenden des Ereignisberichts erfolgt, indem der Kommunikationsadapter in der vertrauenswürdigen Zone den Ereignisbericht in einen Speicher der nicht vertrauenswürdigen Zone bringt, auf den der Kommunikationsadapter in der nicht vertrauenswürdigen Zone zugreifen und verschicken kann. Auf diese Art und Weise kann ein sicherer Datentransfer von der einen in die andere Zone sichergestellt werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Ereignisbericht zumindest eine sich für jeden Ereignisbericht verändernde Größe und/oder zumindest eine Authentifizierungs-Information umfasst und/oder durch eine Verschlüsselung verschlüsselt wird. Dadurch kann die übergeordnete Instanz prüfen, ob es sich um authentische Daten handelt. Besonders zweckmäßig ist hierzu vorgesehen, dass die Authentifizierungs-Information gebildet wird durch weitere im Ereignisbericht enthaltene Informationen.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass ein der vertrauenswürdigen Zone zugeordnetes Sicherheitsmodul eine sich für jeden Ereignisbericht veränderliche Größe und/oder eine Authentifizierungs-Information und/oder eine Verschlüsselung bereitstellt. Dadurch kann eine sichere, authentische und vertrauliche Verbindung mit einer übergeordneten Instanz hergestellt werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass nach Versenden des Ereignisberichts ein Bestätigungssignal empfangen wird, welches von dem Kommunikationsadapter der nicht vertrauenswürdigen Zone empfangen und an den Kommunikationsadapter der vertrauenswürdigen Zone weitergeleitet wird. Über das Bestätigungssignal kann der ordnungsgemäße Abschluss einer Übersendung des Ereignisberichts überprüft und weitere Maßnahmen wie beispielsweise das Leeren des Speichers veranlasst werden In einer zweckmäßigen Weiterbildung ist vorgesehen, dass das Bestätigungssignal zumindest eine für jedes Bestätigungssignal veränderliche Größe und/oder zumindest bestimmte Daten bzw. Pattern und/oder zumindest eine Authentifizierungs-Information und/oder zumindest eine konstante Länge umfasst und/oder mit einer Verschlüsselung verschlüsselt wird. Durch die veränderliche Größe sieht das Bestätigungssignal insbesondere nach Verschlüsselung immer signifikant unterschiedlich aus gegenüber dem Angreifer und ist damit nicht interpretierbar. Durch das zusätzliche veränderliche Signal wird die Aktualität sichergestellt, da nicht auf einen Altenereignisbericht zurückgegriffen werden kann. Die Authentifizierungs-Information stellt sicher, dass das Bestätigungssignal von einer echten übergeordneten Instanz stammt, und nicht von einem Angreifer erzeugt wurde. Somit kann der lokale Ereignisbericht vertrauenswürdig gelöscht werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Kommunikationsadapter der vertrauenswürdigen Zone das empfangene Bestätigungssignal unter Verwendung eines in der sicherheitsrelevanten Zone angeordneten Sicherheitsmoduls entschlüsselt und/oder authentifiziert. Durch die weitere Überprüfung in der vertrauenswürdigen Zone wird die Sicherheit der Kommunikation weiter verbessert. Besonders zweckmäßig ist hierzu vorgesehen, dass das empfangene Bestätigungssignal entschlüsselt und/oder authentifiziert wird, indem überprüft wird, ob die veränderliche Größe des verschickten Ereignisberichts in dem Bestätigungssignal enthalten ist. Somit muss auch für das Bestätigungssignal keine neue veränderliche Größe generiert werden, sondern es kann besonders zweckmäßigerweise die insbesondere durch ein Sicherheitsmodul in der vertrauenswürdigen Zone generierte veränderliche Größe, die im Rahmen des Ereignisbericht mitgeschickt wurde, auch für das Bestätigungssignal verwendet werden.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass bei einer Übertragung von Daten von einer Zone in die andere Zone der Sensor die Daten vor einer Benutzung überprüft, insbesondere ob ein Ereignis aufgetreten ist und/oder dass für den Fall, dass kein Ereigniss detektiert wurde, die Daten für die Benutzung in der anderen Zone freigegeben werden. Dadurch werden die Manipulationsmöglichkeiten weiter verringert. Besonders zweckmäßig ist hierzu vorgesehen, dass bei einem Auftreten eines Ereignisses die Daten nicht in die andere Zone transferiert werden und/oder der Sensor das Ereignis an den Ereignismanager weiterleitet.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Ereignismanager und/oder der Kommunikationsadapter der vertrauenswürdigen Zone und/oder der Sensor der vertrauenswürdigen Zone und/oder das Sicherheitsmodul auf einem Rechnerkern implementiert sind. Somit können alle sicherheitsrelevanten Funktionen auf einem Rechnerkern implementiert werden, was die Sicherheit weiter erhöht.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass zumindest einer Recheneinrichtung bestimmte ausführbaren Anwendungsprogramme zu einer von den wenigstens zwei Zonen zugeordnet werden, wobei die Zonen Ressourcen der Recheneinrichtung charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms nutzbar sind, optional Ausführen wenigstens eines der Anwendungsprogramme in Abhängigkeit der ihm zugeordneten Zone. Durch die genannten Zuordnungen zwischen Zonen und Funktionen kann sichergestellt werden, dass nur sicherheitsrelevante Funktionen in der vertrauenswürdigen Zone ausgeführt werden. Dies kann bevorzugt auch dadurch erfolgen, indem die Verfahrensschritte folgendes aufweisen: Austauschen von ersten Daten zwischen verschiedenen Zonen über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone und der zweiten Zone folgende Schritte aufweist: d1) Kopieren der ersten Daten in einen der ersten Zone zugeordneten ersten Pufferspeicherbereich, d2) Überprüfen der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, d3) Kopieren der ersten Daten aus dem der ersten Zone zugeordneten ersten Pufferspeicherbereich in einen der zweiten Zone zugeordneten zweiten Pufferspeicherbereich. Damit wird sichergestellt, wie ein sicherer Datenaustausch zwischen den Zonen bevorzugt verläuft.
Weitere vorteilhafte Ausgestaltungen ergeben sich aus der folgenden Beschreibung und der Zeichnung. In der Zeichnung zeigt
In der Zeichnung zeigt: Fig. 1 schematisch Komponenten einer Eindringungserkennung,
Fig.2 einen beispielhaften Aufbau bzw. Wechselwirkung von empfangenen Daten, daraus abgeleitetem Ereignis, Aufbau des zugehörigen selektierten Ereignisses sowie einen Ereignisbericht,
Fig. 3 schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß einerweiteren bevorzugten Ausführungsform,
Fig. 4 schematisch ein vereinfachtes Blockdiagramm von Aspekten gemäß einerweiteren bevorzugten Ausführungsform,
Fig. 5-10 unterschiedliche Kommunikationsabläufe zwischen
Ereignismanager, Kommunikationsadapter, weiterer IDS Instanz sowie Backend.
Im Zusammenhang mit Aspekten der folgenden Ausführungen werden im Folgenden Abweichungen von einem Normalverhalten, die aus verschiedenen Gründen in einem realen Betrieb in Daten 211 (beispielsweise Daten eines Kommunikationssystems oder Systemdaten) eines insbesondere vernetzten Systems können, als Anomalie bezeichnet. Ursachen dafür können beispielsweise folgender Art sein: Defekte oder ganz ausgefallene Sensoren liefern falsche oder gar keine Daten, Bauteile des Systems sind beschädigt, das System wurde durch externe, aber auch lokale bzw. physikalische Angriffe (z. B. einen Hackerangriff) manipuliert.
Die Erkennung von Anomalien in Daten 211 wird mittels eines sogenannten Intrusion Detection Systems, IDS oder IDPS, umgesetzt. Mit IDS wird im Folgenden ein System bezeichnet, das Daten 211 auf Anomalien überwacht. Hierbei kann es sich beispielsweise um Daten 211 bei der Datenverbindung in einem Kommunikationsnetz, über welches das Steuergerät 20 wie beispielsweise ein Gateway auf unterschiedlichen Kommunikationskanälen (beispielsweise über Bussysteme wie 25 oder Internet 27) kommuniziert, handeln. Jedoch sollen auch andere Daten 211, beispielsweise Systemdaten innerhalb eines Steuergeräts (bzw. darin angeordneten Host 29 bzw. Mikrocontroller oder Prozessor oder innerhalb eines Chips) auf Anomalien durch dieses IDS System überprüft werden. Die Detektion von Anomalien der Daten 211 erfolgt durch geeignete Sensoren 24, 26, 28. Die Sensoren 24, 26, 28 sind an die jeweilige Quelle der Daten 211 (im Ausführungsbeispiel Bussysteme 25, 27 oder Host 29) angepasst.
Gemäß Figur 1 ist ein Steuergerät wie beispielsweise ein Gateway 20 in einem Fahrzeug 18 angeordnet. Das Steuergerät bzw. das Gateway 20 umfasst Prozessor(en), Speicher, Arbeitsspeicher (beispielsweise als Bestandteil eines Host-Systems 29) und Schnittstellen für eine Kommunikation über ein Kommunikationsnetzwerk. Das Gateway 20 arbeitet beispielsweise Instruktionen zur Datenverbindung ab. Durch die Kommunikation entstehen Daten 211 in Form von Datenpaketen. Auch bei dem Betrieb des Hosts 29 entstehen Daten 211, beispielsweise Systemdaten. In einem Normalzustand werden Sollwerte beispielsweise bezüglich Empfänger-und Zieladresse, Einhaltung von korrektem Programmablauf (beispielsweise für Host 29), Zeitstempel, Auftretenshäufigkeit oder Frequenz von Daten 211 bestimmter Datenpakete eingehalten. Die Daten 211 der Datenpakete werden zur Erfüllung der spezifischen Aufgaben zwischen weiteren nicht näher gezeigten Steuergeräten oder Komponenten im Fahrzeug 18 ausgetauscht. Das Gateway 20 dient der Kopplung mehrerer Kommunikationssysteme bzw. Schnittstellen wie beispielsweise ein CAN-Bus 25, eine Ethernet-Verbindung 27 sowie eine Datenverbindung zu dem Host-System 29, welches Bestandteil des Steuergeräts 20 bzw. des Gateways ist. Jedoch auch andere Kommunikationssysteme (beispielsweise weitere drahtgebundene Bussysteme wie LIN, CAN-FD etc. bzw. drahtlose Netzwerke (beispielsweise WLAN oder Bluetooth) können durch das Gateway 20 miteinander zum Zwecke des Datenaustauschs gekoppelt werden. Generell dient eine Eindringungserkennung IDS bzw. Anomalieerkennung in einem Steuergerät dazu, sämtliche Daten 211 (durch Kommunikationssystem empfangene Daten 211 ebenso wie innerhalb des Steuergeräts 20 durch den Host 29 generierte Daten 211) auf entsprechende Anomalien zu überwachen. Im Ausführungsbeispiel wird der IDS-Funktionsmechanismus beispielhaft für das Gateway 20 beschrieben. Generell können jedoch die beschriebenen Funktionalitäten der Anomalieerkennung bzw. Eindringungserkennung IDS in jedem beliebigen Steuergerät oder beliebigen elektronischen Komponenten implementiert werden. Insbesondere ist die Verwendung nicht auf ein Fahrzeug 18 beschränkt. Vielmehr können beliebige Kommunikationskomponenten, beispielsweise Kommunikationsmodule im Internet (IOT Internet of Things) oder bei vernetzten Produktionssystemen mit den beschriebenen Funktionalitäten ausgestattet werden.
Eine Kommunikationskomponente wie Steuergerät bzw. das Gateway 20 umfasst zumindest eine Anomalieerkennung 22. Die Anomalieerkennung 22 erstreckt sich über zumindest eine nicht vertrauenswürdige Zone Z1 sowie über zumindest eine vertrauenswürdige Zone Z2. Insbesondere ein Kommunikationsadapter 32 ist sowohl in der vertrauenswürdigen Zone Z2 wie auch in der nicht vertrauenswürdigen Zone Z1 angesiedelt. Zumindest ein Sensor 24,26, 28 befindet sich in der vertrauenswürdigen Zone Z2. Auch der Ereignismanager 30 ist in der vertrauenswürdigen Zone angesiedelt.
Die über die Schnittstellen der jeweiligen Kommunikationssysteme 25, 27, 29 eingehenden Daten 211 werden jeweils über sogenannte Sensoren 24, 26, 28 zur Anomalieerkennung oder Eindringlingserkennung, kurz IDS Sensoren, geführt. So sind in dem Gateway 20 entsprechende Sensoren 24, 26, 28 angeordnet. Solche Sensoren 24, 26, 28 dienen der Erkennung, ob erhaltene Daten 211 eine Anomalie darstellt. Hierzu sind in den Sensoren 24, 26, 28 entsprechende Filteralgorithmen bzw. Regelsätze hinterlegt, die der Detektion und Klassifikation von Anomalien dienen. Wird eine Anomalie durch einen Sensor 24, 26, 28 ermittelt, wird das entsprechende Datenpaket der Daten 211 als Ereignis 220 (eines versuchten Eindringens) klassifiziert. Generell können die Sensoren 24, 26, 28 je nach Quelle 25, 27, 29 unterschiedliche Anomalien als Ereignisse 220 klassifizieren (Zuordnung des jeweiligen Ereignisses 220 zu bestimmten Ereignisarten 218) und erkennen. In Abhängigkeit von der jeweiligen Ereignisart 218 (unterschiedliche Arten von Anomalien in den Daten 211) stellen die Sensoren 24, 26, 28 bestimmte ereignisabhängige Metadaten 216 als zugehöriges Ereignis 220 zusammen. Außerdem können die ereignisabhängigen Metadaten 216 auch Daten oder Datenbestandteile der anomalen Daten 211 enthalten. Das so generierte Ereignis 220 wird an einen Ereignismanager 30 weitergeleitet. Die Sensoren 24, 26, 28 sind in der Regel ausgestaltet, dass bei einer nicht bestehenden Anomalie die zugehörigen Daten 211 eines Kommunikationssystems (beispielsweise Bussysteme 25, 27) an die Bestimmungsadresse weitergeleitet werden. Bei einer erkannten Anomalie könnten die Sensoren 24, 26, 28 so ausgestaltet sein, dass die zugehörigen Daten 211 eines Kommunikationssystems (beispielsweise Bussystem 25, 27) nicht an die Bestimmungsadresse weitergeleitet werden. Alternativ können die Sensoren 24, 26, 28 auch dafür verwendet werden, Ereignisse 220 zu reduzieren (reduziertes Ereignis bzw. vorreduziertes Ereignis 221). Durch diese Reduzierung könnte der Ereignismanager 30 entlastet werden, beispielsweise indem lediglich ein kleiner Teil von Nutzdaten von Anomalien enthaltenden Daten 211 bzw. Datenpaketen weitergeleitet werden. Dies ist insbesondere bei großen Datenmengen wie sie bei Ethernet-Verbindungen auftreten von Vorteil.
So dienen beispielsweise IDS CAN Sensoren 24 der Anomalieerkennung bei einem CAN-Bus 25, IDS Ethernet Sensoren 26 bei einem Ethernet-System 27 sowie IDS Host Sensoren 28 bei einem Host-System 29. Je nach unterschiedlichen Kommunikationswegen und Kommunikationsprotokollen können auch weitere IDS Sensoren vorgesehen werden, die in der Lage sind, Anomalien bei den jeweiligen Quellen bzw. Anomaliequellen zu detektieren und gegebenenfalls zu klassifizieren.
Die IDS CAN Sensoren 24 detektieren relevante Ereignisse 220 von zugehörigen Ereignisarten 218 wie beispielsweise ungültige CAN-ID's, ungültige Nachrichtenhäufigkeiten, ungültige Nachrichtenlängen oder ähnliches. Die IDS Ethernet Sensoren 26 detektieren für das Ethernet 27 relevante Ereignisse 220 von zugehörigen Ereignisarten 218 wie beispielsweise ungültige Adressen bzw. MAC Adressen, ungültige Nachrichtenhäufigkeiten, ungültige Nachrichtenlängen oder ähnliches. Die IDS Host Sensoren 28 detektieren für das Host System 29 relevante Ereignisse 220 von zugehörigen Ereignisarten 218 wie beispielsweise ungültige Codeausführungen, Korrumpierung von Programmen, Stapelzählern oder Ähnliches. Zumindest einen Sensor 24, 26, 28 ist in der vertrauenswürdigen Zone Z2 angeordnet.
Nachfolgende weitere Anomalien können als Ereignisse 220 berücksichtigt werden für weitere Ereignisarten 218. Beispielsweise sind dies Ereignisse 220 bzw. Ereignisarten 218, die der Firewall zuzuordnen sind wie beispielsweise Verlust des Frames aufgrund eines vollen Pufferspeichers, Filterverletzung (stateless/stateful), Begrenzung der Übertragungsrate aktiv bzw. inaktiv, Überwachungsmodus aktiviert bzw. deaktiviert, Kontextwechsel. Auch weitere Anomalien, die das Host System 29 betrifft, können als Ereignisse 220 berücksichtigt werden mit zugehörigen Ereignisarten 218 wie beispielsweise CPU Belastung zu hoch, Speicherzugriffsverletzung, Fehler bei der Code- Ausführung, ECU Rücksetzung detektiert, Log-Einträge im nichtflüchtigen Speicher korrumpiert, Overflow des Logging-Speichers, Zurückweisung eines Ereignisses, MAC Adressport Änderung etc.
Der Ereignismanager 30 dient der Weiterverarbeitung der eingehenden Ereignisse 220 bzw. der in dem jeweiligen Ereignis 220 enthaltenen ereignisabhängigen Metadaten 215. Insbesondere dient der Ereignismanager 30 der Aggregierung, Formatierung bzw. Aufbereitung der Ereignisse 220 und/oder der Priorisierung und/oder Reduzierung/Selektierung der Ereignisse 220 und/oder dem Abspeichern bzw. Persistieren bzw. dauerhaften Abspeichern der ausgewählten und/oder reduzierten Ereignisse 220, 221. Insbesondere entscheidet der Ereignismanager 30, welche eingehenden Ereignisse 220 weiterverarbeitet werden sollen. Die von den eingehenden Ereignissen 220 ausgewählten werden als selektierte Ereignisse 226 bezeichnet. Die entsprechende Auswahl soll möglichst nicht deterministisch erfolgen. Weiterhin versieht der Ereignismanager 30 die eingehenden Ereignisse 220 bzw. die selektierten Ereignisse 226 besonders bevorzugt noch mit weiteren generischen Metadaten 217. Dadurch können die von unterschiedlichen Sensoren 24, 26, 28 übermittelten Ereignisse 220 übergeordnet betrachtet werden, indem beispielsweise die Anzahl der aufgetretenen Ereignisse, der zugehörige Zeitstempel bzw. Zeitsignal 224 oder Ähnliches im Rahmen der generischen Metadaten 217 hinzugefügt werden. Weiterhin wird sichergestellt, dass selbst bei einem sogenannten Ereignis-Burst hinreichend viele und aussagekräftige Ereignisse 220 als selektierte Ereignisse 226 gespeichert werden können. Der Ereignismanager 30 ist in der vertrauenswürdigen Zone Z2 angeordnet.
Der Ereignismanager 30 tauscht Signale aus mit einem Kommunikationsadapter 32 der Eindringungs- bzw. Anomalieerkennung. Der Kommunikationsadapter 32 fungiert als Kommunikationsmittel zum Datenaustausch zwischen dem Ereignismanager 30 und weiteren Komponenten 34, 36 außerhalb der Anomalieerkennung 22 des Steuergeräts bzw. Gateways 20. Konkret dient der Kommunikationsadapter 32 als Schnittstelle zum Datenaustausch zwischen dem Ereignismanager 30 und weiteren IDS Instanzen 34 (vorzugsweise innerhalb des Fahrzeugs 18) und/oder einem Backend 36 (vorzugsweise außerhalb des Fahrzeugs 18). Die weitere IDS Instanz 34 kann lediglich optional vorgesehen werden. Der Kommunikationsadapter 32 ist in beiden Zonen Z1, Z2 angeordnet.
Zur Erhöhung der Sicherheit könnte der Ereignismanager 30 eine zufallsbasierte, für einen Angreifer nicht determininistische und verschleierte Reduzierung und Priorisierung von Ereignissen 220, 221 vornehmen. So könnte zufallsbasiert, für den Angreifer nicht determininistisch und verschleiert ein nicht flüchtiges Speichern selektierter Ereignisse 226 vorgenommen werden. Die zufallsgesteuerte Auswahl könnte beispielsweise auf einer für ein bestimmtes Steuergerät individuellen Zufallszahl 273 basieren. Ebenfalls kann der Ereignismanager 30 eine zufallsbasierte Speicherung der Zählerstände 231 der Ereigniszähler 204 erfolgen. Der Ereignismanager 30 speichert auch zufallsabhängig neben den ereignisabhängigen Metadaten 216 die hinzugefügten generischen Metadaten 217 als selektierte Ereignisse 226 ab.
Der Kommunikationsadapter 32 könnte zur Erhöhung der Sicherheit eine zufallsbasierte, für einen Angreifer nicht determininistisches und verschleiertes Hochladen bzw. Versenden eines Ereignisberichts 242 zu anderen IDS Instanzen 34 vornehmen. Das zufallsgesteuerte Hochladen könnte beispielsweise auf einer für ein bestimmtes Steuergerät (bzw. Gateway 20) individuellen Zufallszahl 273 basieren. So könnten bestimmte Ereignisse 220 im Rahmen des Ereignisberichts 242 zyklisch und verschlüsselt übertragen werden. Doch auch wenn keine neuen Ereignisse 220 vorliegen, könnten sogenannte Dummy-Ereignisse im Format eines Ereignisberichts 242 zyklisch und verschlüsselt übertragen werden. Dies dient der Abhörsicherheit bzw. zufallsbasierten Verschleierung des Datenaustauschs zwischen dem Kommunikationsadapter 32 und weiteren IDS Instanzen 34 bzw. dem Backend 36.
Die bearbeiteten reduzierten Ereignisse 221 werden von dem Sensor 26 an den Ereignismanager 30 weitergeleitet. Damit erhält der Ereignismanager 30 von diesem Sensor 26 nicht komplette Datenströme dieser Net-Frames, sondern lediglich reduzierte Ereignisse 221 mit reduzierter Datengröße. Die Reduzierung der weiterzuleitenden Ereignisse 221 wurde anhand eines IDS Ethernet Sensors 26 beispielhaft beschrieben. Prinzipiell könnte dies jedoch auch in anderen IDS Sensoren 24, 26, 28 realisiert sein. Aufgrund des hohen Informationsgehalts in einem Ethernet-Frame mit hohen Übertragungsraten würden jedoch gerade solche Ereignisse 220 schnell zu einem Überlauf des Pufferspeichers 206 führen. Bei IDS CAN Sensoren 24 treten entsprechende Daten 211 ohnehin mit niedrigerer Datenrate und geringerem Datenvolumen auf, sodass hier tendenziell komplette Ereignisse 220 weitergegeben und abgespeichert werden können.
Beispielhaft wird in Verbindung mit Figur 2 gezeigt, wie Daten 211 vom Sensor 24, 26, 28 im Falle einer erkannten Anomalie weiterverarbeitet und an den Ereignismanager 30 geschickt werden, bis dieser einen Ereignisbericht 242 über den Kommunikationsadapter 32 verschickt.
Beispielhaft ist in Figur 2a ein Datenpaket von Daten 211 gezeigt wie sie beispielsweise bei einem Netzwerk- Fra me (beispielsweise CAN, Ethernet) auftreten könnten. Die Daten 211 weisen einen Header 214 auf, der beispielsweise die Quelladresse und die Zieladresse (beispielsweise MACa, MACb) umfasst. Außerdem umfassen die Daten 211 Nutzdaten 213.
Wie nachfolgend näher ausgeführt wird könnte der Sensor 24, 26, 28 optional einen Nutzdatenbereich 219 zufällig auswählen, der an den Ereignismanager 30 weitergeleitet wird. Der Sensor 24, 26, 28 hat ermittelt, dass es sich um eine Anomalie gemäß einer bestimmten Ereignisart 218 (event-ID bzw. Ereignis-ID,
ID) handelt. Daher generiert der Sensor 24, 26, 28 ereignisabhängige Metadaten 216 wie in Figur 2b dargestellt. Je nach Ereignisart 218 (bzw. ID) können bei den ereignisabhängigen Metadaten 216 unterschiedliche Informationen der Anomalie hinterlegt sein. Im Ausführungsbeispiel werden als ereignisabhängige Metadaten 216 unter anderem Quell- und Zieladresse (MACa, MACb), die Ereignisart 218 und der ausgewählte Nutzdatenbereich 219 verwendet.
Alternativ könnten auch die ereignisabhängigen Nutzdaten 213 komplett im Rahmen des Ereignisses 220 an den Ereignismanager 30 weitergeleitet werden.
Alternativ könnte auch das Ereignis 220 keine ereignisabhängigen Nutzdaten 213 umfassen, beispielsweise wenn als Quelle der Host 29 verwendet ist. Hierbei kann es sich um Ereignisarten 218 wie beispielsweise Informationen zum Verlust des Datenrahmens aufgrund eines vollen Puffers, Aktivierung bzw. Deaktivierung des Beobachtungsmodus, Belastung der CPU ist zu hoch, Einträge des nichtflüchtigen Speichers 208 sind korrumpiert, Overflow des Logging-Puffers, Ereignisreduzierung aktiv etc oder ähnliches handeln.
Weiterhin können für unterschiedliche Ereignisarten 218 weitere ereignisabhängige Informationen im Rahmen der ereignisabhängigen Metadaten 216 Bestandteil des Ereignisses 220 sein. Bei der Ereignisart 218 „Wechsel des Kontexts“ könnten die ereignisabhängigen Metadaten 216 beispielsweise den Kontext umfassen, beispielsweise in der Größe von 32 Bit. Bei der Ereignisart 218 „Speicherzugriffsverletzung“ oder „Verletzung bei der Ausführung eines Codes“ könnten die ereignisabhängigen Metadaten 216 beispielsweise die zugegriffene Adresse (beispielsweise 32 Bit), den Programmzähler (beispielsweise 32 Bit), die Task-ID (beispielsweise 8 Bit) umfassen. Bei der Ereignisart 218 „detektierter Reset eines Steuergeräts“ könnten die ereignisabhängigen Metadaten 216 beispielsweise den Grund des Resets (beispielsweise 8 Bit), beispielsweise POR (Point of Return), Software Reset, Ausnahmen etc. umfassen.
Nachfolgende Ethernet-bezogene Ereignisse 220 könnten als ereignisabhängige Metadaten 216 geloggt werden wie beispielsweise statische/zustandsabhängige Filterverletzungen (bestimmte Regel-ID bzw. ID für bestimmte Ereignisart 218 (beispielsweise 16 Bit), eine ID der Filter-Regel, die das Ereignis 220 hervorrief falls verfügbar, physikalische Portadresse, physikalische Port-ID, über die der Frame erhalten wurde, Quelladresse (z.B. MAC-Adresse, beispielsweise 48 Bit), Zieladresse (z.B. MAC-Adresse, beispielsweise 48 Bit), eventuell IP-Adresse von Quelle oder Ziel, Bestimmung des UDP/TCP-Ports (beispielsweise 16 Bit) falls im Frame vorhanden, optional). Alternativ könnten statische/zustandsabhängige Filterverletzungen mitprotokolliert werden wie beispielsweise Regel-ID, physikalischer Port, Frame (Anzahl der Bytes) bestimmte Anzahl von Bytes des empfangenen Frames werden gespeichert, ausgewählter Nutzdatenbereich 219 (bestimmte Anzahl von Bytes) ausgewählter Nutzdatenbereich 219 der Bytes des Original-Frames, Nutzdatenbereich 219 - Index (beispielsweise 16 Bit), Startbyte des ausgewählten Nutzdatenbereichs 219 im Original-Frame. Auch weitere Ethernet-bezogene Ereignisse könnten in den an den Ereignismanager 30 übermittelten Ereignissen 220 enthalten sein wie beispielsweise für die Ereignisart 218 „Übertragungsrate begrenzt (aktiv/inaktiv)“ die Regel-ID mit zugehöriger ID der Filterregel, die das Ereignis 220 verursacht hat, für die Ereignisart 218 „Änderung des Kontexts“ der Kontext (beispielsweise 32 Bit), für die Ereignisart 218 „Adress-Hopping“ bzw. „MAC Hopping“ der alte Port (physikalische Port-ID, die der Adresse ursprünglich zugeordnet wurde), der neue Port (physikalische Port-ID, wo die Adresse kürzlich beobachtet wurde), die Adresse, vorzugsweise MAC-Adresse. Es können jedoch auch Ereignisarten 218 ohne Meta-Daten 216 auftreten wie beispielsweise „Verlust des Frames aufgrund vollen Puffers“ etc.
Die Weiterleitung von ereignisabhängigen Nutzdaten 213 hängt somit insbesondere von der Quelle der Daten 211 mit der zugehörigen Ereignisart 218 ab. Die Metadaten 216 werden als Ereignis 220 bzw. reduziertes Ereignis 221 (aufgrund der zufallsabhängigen Auswahl bzw. Reduzierung des zu übertragenden Nutzdatenbereichs 219 im Sensor 24, 26, 28) an den Ereignismanager 30 übertragen.
Sollte der Ereignismanager 30 dieses Ereignis 220, 221 zur Weiterverarbeitung auswählen (selektiertes Ereignis 226) wie nachfolgend näher erläutert, so werden zu den ereignisabhängigen Metadaten 216 noch generische Metadaten 217 hinzugefügt, sodass die in Figur 2c gezeigten Metadaten 215 entstehen. Diese generischen Metadaten 217 werden in der Regel im Ereignismanager 30 generiert. Es handelt sich beispielsweise um Ausgangssignale der Ereigniszähler 204, also aktuelle Zählerstände 231, um das wievielte globale Ereignis 220 bzw. um das wievielte Ereignis einer bestimmten Ereignisart 218 es sich bei dem aktuellen Ereignis 220 handelt. Außerdem können die generischen Metadaten 217 beispielsweise ein Zeitsignal 224 umfassen, wann dieses Ereignis 220 aufgetreten ist. Außerdem könnten die Metadaten 217 umfassen, welche Länge 232 (Größe der Daten) die ereignisabhängigen Metadaten 216 bzw. die kompletten Metadaten 215 aufweisen. Dies ist für das spätere Speichermanagement des Pufferspeichers 206 von Vorteil.
Beispielhaft werden nachfolgende generische Metadaten 217 vorgeschlagen. Dies könnte beispielsweise eine Ereignisart 218 im Rahmen einer Ereignis-ID (beispielsweise 8 Bit) sein. Diese Ereignis-ID der Ereignisart 218 ist eindeutig und kann beispielsweise eine TLV- basierte Kodierung (TLV: Type-Length-Value Typ-Länge-Wert) umfassen. Die generischen Metadaten 217 umfassen die Länge 232, beispielsweise zwischen 8 und 16 Bit groß. Die Größe der Daten (Metadaten 215) folgt nach dem Längenfeld in Bytes, maximal 255 Bytes. Wiederum könnte eine TLV-basierte Kodierung vorgesehen werden. Weiterhin enthalten ist das Zeitsignal 224, ein Zeitstempel (beispielsweise 64 Bits). Die Zeit 224 ist beispielsweise angegeben in der Form eines absoluten Zeitwerts, der seit einem Bezugszeitpunkt wie dem 1. Januar 1970 verstrichen ist (in Millisekunden) zur Angabe eines eindeutigen Zeitstempels. Weiterhin können die generischen Metadaten 217 Zählerstände 231 bzw. Ausgangswerte 231 der Ereignis-Typ- Zähler 204 (beispielsweise 32 Bit) und/oder den Zählerstand 231 des globalen (Ereignis)Zählers 204 (beispielsweise 32 Bit), eine Summe aller Zählerstände 231 der Ereigniszähler 204 für jede Ereignisart 218, umfassen.
Die ereignisabhängigen Metadaten 216 werden so übernommen, wie sie der jeweilige Sensor 24, 26, 28 gebildet hat. Dieses Ereignis 220 mit den entsprechenden sowohl vom Sensor 24, 26, 28 wie auch vom Ereignismanager 30 gebildeten Metadaten 215 wird in dem Pufferspeicher 206 des Ereignismanagers 30 abgelegt. In ähnlicher Art und Weise werden noch weitere - wie nachfolgend näher erläutert - vom Ereignismanager 30 selektierte bzw. reduzierte Ereignisse 226 (im Ausführungsbeispiel gemäß Figur 2d exemplarisch als 215_1, 215_8 , 215_190 bezeichnet) im Pufferspeicher 206 abgelegt.
Aus in dem Pufferspeicher 206 abgelegten selektierten Ereignissen 226 (im Ausführungsbeispiel gemäß Figur 2d exemplarisch als 215_ 1 , 215_8, 215_190 bezeichnet (Metadaten 215 Ereignis Nr. 1, Metadaten 215 Ereignis Nr. 8, Metadaten 215 Ereignis Nr. 190 als Beispiele für selektierte Ereignisse 226) wird nun ein Ereignisbericht 242 generiert. Dieser umfasst die in dem Pufferspeicher 206 abgelegten selektierten Ereignisse 226 (im Beispiel 215_ 1 , 215_8,
215_190). Vorangestellt wird diesen selektierten Ereignissen 226 eine gegenüber jedem Ereignisbericht 242 veränderte Größe 254 (beispielsweise Zufallszahl, Zeit oder Zähler etc.). Außerdem umfasst der Ereignisbericht 242 eine Authentifizierungs-Information 256. Darüber kann die Authentifizierung zwischen Kommunikationsadapter 32 bzw. Ereignismanager 30 und der den Ereignisbericht 242 empfangenden Einheit (IDS Instanz 34, Backend 36 oder Ähnliches) erfolgen. Der Ereignisbericht 242 umfasst eine feste Länge 258. Um diese feste Länge 258 zu erreichen, werden die Daten 254, 215_ 1 , 215_8,
215_190, 256 noch aufgefüllt durch sogenannte Fülldaten 255. Diese Fülldaten 255 beinhalten keine ereignisrelevanten Informationen. Vor einer Übertragung werden die gezeigten Daten des Ereignisberichts 242 mit einer Verschlüsselung 258 versehen wie in der Figur 2d angedeutet. Der so durch die Verschlüsselung 258 verschlüsselte Ereignisbericht 242 wird vom Kommunikationsadapter 32 verschickt, und von der weiteren IDS Instanz 34 oder Backend 36 entschlüsselt und authentifiziert wie beschrieben.
Fig. 3 zeigt schematisch einen Rechenkern 102a eines Switches SWT 48 gemäß weiteren bevorzugten Ausführungsformen, der ein Betriebssystem BS und/oder Supervisor SV umfasst und der selbst zwei Zonen Z1 , Z2 zugeordnet ist.
Die Anomalieerkennung 22 basiert auf einem 2-Zonen-Konzept, bei dem bestimmte Anwendungen einer nicht vertrauenswürdigen Zone Z1 und einer vertrauenswürdigen Zone Z2 zugeordnet werden. Die Anomalieerkennung 22 kann insbesondere z.B. für ein eingebettetes System und/oder ein Steuergerät, insbesondere für ein Fahrzeug, insbesondere Kraftfahrzeug, verwendet werden.
Bevorzugte Ausführungsformen beziehen sich auf ein Verfahren zum Betreiben einer der Anomalieerkennung 22 zugeordneten Recheneinrichtung, das die folgenden Schritte aufweist: Zuordnen von einem oder mehreren durch die Recheneinrichtung ausführbaren Anwendungsprogrammen AP1, AP2 zu einer von wenigstens zwei Zonen Z1, Z2 wobei die Zonen Z1, Z2 Ressourcen der Recheneinrichtung charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms AP1, AP2 nutzbar sind, optional Ausführen wenigstens eines der Anwendungsprogramme AP1 , AP2 in Abhängigkeit der ihm zugeordneten Zone Z1, Z2, wobei das Verfahren weiter alternativ aufweist: Verwenden eines Supervisors SV zum Zuweisen von Rechenzeitressourcen für unterschiedliche Anwendungsprogramme und/oder Instanzen von Anwendungsprogrammen, wobei der Supervisor SV und/oder eine dem Supervisor SV entsprechende Funktionalität zumindest teilweise mittels einer Supervisor-Instanz SVI realisiert ist, die von den wenigstens zwei Zonen Z1, Z2 unabhängig ist. Bei weiteren bevorzugten Ausführungsformen können dadurch z.B. Vertrauensgrenzen (englisch: Trust Boundaries) definiert werden, z.B. zwischen vertrauenswürdigen und nicht-vertrauenswürdigen Instanzen/ Einheiten/Domänen. Auf diese Weise können beispielsweise erste Anwendungsprogramme für die Recheneinrichtung einer nicht vertrauenswürdigen ersten Zone Z1 (englisch: non-trustworthy zone, NT) und zweite Anwendungsprogramme für die Recheneinrichtung einer vertrauenswürdigen zweiten Zone Z2 (englisch: trustworthy zone, (T)Z) zugeordnet werden. Bei weiteren bevorzugten Ausführungsformen kann die Supervisor-Instanz SVI z.B. durch einen (dedizierten) Rechenkern und/oder ein Hardware-Sicherheitsmodul HSM und/oder ein Trusted-Platform-Modul TPM gebildet sein bzw. kann die Funktionalität der Supervisor-Instanz SVI mittels wenigstens einem dieser Elemente realisiert werden.
Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren zum Betreiben der Recheneinrichtung weiter aufweist: Steuern, insbesondere Begrenzen, von wenigstens einem der folgenden Elemente: a) Leserechte auf der Recheneinrichtung zugeordneten Speicher, b) Schreibrechte auf der Recheneinrichtung zugeordneten Speicher, c) Ausführungsrechte ("Exekutionsrechte") auf der Recheneinrichtung zugeordneten Speicher, in Abhängigkeit wenigstens einer Zone Z1, Z2. Dadurch ist vorteilhaft sichergestellt, dass nur solche Anwendungsprogramme AP Zugriff auf den bzw. die genannten Speicher erhalten, die einer entsprechenden Zone Z1, Z2 zugeordnet sind. Beispielsweise kann damit bei weiteren bevorzugten Ausführungsformen verhindert werden, dass ein Anwendungsprogramm einer nicht vertrauenswürdigen Zone Z1 auf den bzw. die Speicher zugreift (insbesondere z.B. Zugriff auf den der vertrauenswürdigen Zone Z2 zugeordneten Speicherbereich durch die nicht- vertrauenswürdigen Zone Z1), was ggf. ein Risiko bezüglich einer möglichen Manipulation des Speicherinhalts durch das Anwendungsprogramm der nicht vertrauenswürdigen Zone Z1 darstellt.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung z.B. das folgende Szenario ausführen: Soll ein erstes Anwendungsprogramm AP1 Daten aus einer, z.B. nicht-vertrauenswürdigen ersten, Zone Z1 empfangen - bspw. Remote Service Requests ("Dienstanfragen aus der Ferne") aus dem Internet - und diese Daten entsprechend innerhalb der vertrauenswürdigen Zone Z2 prozessieren oder weiterleiten - bspw. zur Ausführung des entsprechenden Diensts ("Remote Service") - so erfolgt innerhalb der ersten Zone Z1 durch den Z1 -Proxy AP1J1 des Anwendungsprogramms AP1 das Empfangen der Daten, wobei der korrespondierende Z2-Proxy_l2 z.B. folgende Schritte ausführt: eine Daten-Verifikation der von dem Z2-Proxy_l2, insbesondere defaultmäßig, nicht vertrauenswürdig eingestuften Daten sowie - im Falle einer erfolgreichen Daten- Verifikation - die Prozessierung oder Weiterleitung der nun (nach Daten- Verifikation) als vertrauenswürdig eingestuften Daten innerhalb der zweiten Zone Z2. Bei weiteren bevorzugten Ausführungsformen ist vorgesehen, dass das Verfahren weiter aufweis: Austauschen von ersten Daten zwischen verschiedenen Zonen über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone Z1 und der zweiten Zone Z2 folgende Schritte aufweist: Kopieren der ersten Daten in einen der ersten Zone zugeordneten ersten Pufferspeicherbereich, Überprüfen der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, Kopieren der ersten Daten aus dem der ersten Zone Z1 zugeordneten ersten Pufferspeicherbereich in einen der zweiten Zone Z2 zugeordneten zweiten Pufferspeicherbereich. Diese kurz skizzierten Funktionalitäten des 2-Zonen-Konzepts werden nun für die Anomalieerkennung 22 wie nachfolgend beschrieben implementiert.
Der Rechenkern 102a gemäß Figur 3 kann z.B. für einen Netzwerkswitch verwendet werden, z.B. um Ethernet-Datenpakete zu senden und/oder zu empfangen. Entsprechende Instanzen von Anwendungsprogrammen AP sind mit den Bezugszeichen 11 (Empfangen von Ethernetpaketen, Ausführung in der Zone Z1), I2 (Empfangen von Ethernetpaketen, Ausführung in der Zone Z2), I3 (Senden von Ethernetpaketen, Ausführung in der Zone Z1), I4 (Senden von Ethernetpaketen, Ausführung in der Zone Z2) gekennzeichnet. Ein weiteres Anwendungsprogramm AP5, das z.B. Managementaufgaben für den Netzwerkswitch 48 ausführt, läuft nur in der als vertrauenswürdig definierten zweiten Zone Z2, nicht jedoch in der als nicht vertrauenswürdig definierten ersten Zone Z1. Weiterhin sind Ethernet Sensoren 38 in der als nicht vertrauenswürdig definierten ersten Zone Z1 angeordnet. Weitere Ethernet Sensoren 40 sind in der als vertrauenswürdig definierten zweiten Zone Z2 angeordnet. Außerdem sind Host Sensoren 42 in der als nicht vertrauenswürdig definierten ersten Zone Z1 angeordnet. Die Host Sensoren 43 der nicht vertrauenswürdigen Zone Z1 können optional vorgesehen sein. Host Sensoren 45 sind in der als vertrauenswürdig definierten zweiten Zone Z2 angeordnet. Je nach Anwendungsfall können also die Sensoren in der vertrauenswürdigen und/oder nicht vertrauenswürdigen Zone Z1, Z2 angeordnet werden. Dem Rechenkern 102a ist ein RAM 1030 zugeordnet, das bei weiteren bevorzugten Ausführungsformen aufgeteilt sein kann. Optional ist eine Switching- Engine (z.B. Koppelnetz) vorgesehen und/oder ein TCAM (ternary content- adressable memory)-Modul bzw. ein ACL (Access-Control-List)-Modul. Bei der Switching-Engine SE bzw. dem TCAM/ACL-Modul handelt es sich um Hardwaremodule 42. In dem TCAM/ACL-Modul können entsprechende Filterregeln konfiguriert werden, sodass das TCAM/ACL-Modul als Sensor genutzt wird, um Anomalien zu detektieren. Die entsprechend konfigurierten Filterregeln in diesem Hardware-Modul 42 entsprechen denjenigen der beschriebenen Sensoren 24, 26, 28. Wird durch diese Filterregel eine Anomalie detektiert, kann ein Ereignis 220 generiert werden und/oder die Anomalie geblockt werden. Im Falle der Generierung eines Ereignisses 220 kann ein Interrupt durch das Hardware-Modul 42 ausgelöst werden, damit die Anomalie als Ereignis 220 softwareseitig geloggt werden kann. Gleiches gilt auch für CAN- Hardware-Transceiver auf einem Main-Controller, wo Filterregeln der Sensoren in Hardware konfiguriert werden können.
Weiterhin ist ein Interrupt 44 angedeutet, der beispielsweise softwaremäßig, hardwaremäßig wie beschrieben oder durch einen Timer ausgelöst werden kann. Die genannten Komponenten sind Bestandteil der Elektronikeinheit 48 bzw. des Switches. Außerhalb der Elektronikeinheit 48 bzw. Switch ist eine Recheneinheit 100b (Main Controller) vorgesehen, die über einen Kommunikationskanal 52 Daten austauscht mit der Elektronikeinheit 48 bzw. Switch. Weiterhin ist die Recheneinheit 100b in der Lage, mit anderen IDS Instanzen 34 zu kommunizieren. Die Kommunikation könnte von der Recheneinheit 100 b zu anderen IDS-Instanzen 34 erfolgen, beispielsweise über CAN oder von der Recheneinheit 100b über den Switch 48 zu anderen IDS-Instanzen 34. Die Elektronikeinheit 48 wiederum sendet Ethernet Ereignisse 220 von dem Switch SWT 48 an die Recheneinheit 100 b.
Die Inter-Zonen-Kommunikation von der nicht-vertrauenswürdigen Zone Z1 zu der vertrauenswürdigen Zone Z2 wird über die ETH Sensoren 40 der vertrauenswürdigen Zone Z2 und/oder über die durch Hardware-Filterregeln realisierten Sensoren 42 und/oder durch ETH Sensoren 40 der nicht vertrauenswürdigen Zone Z1 und/oder die Host-Sensoren 45 der vertrauenswürdigen Zone Z2 gesteuert. Erfolgt die Inter-Zonen-Kommunikation bzw. die Zonen-Transition von Z1 nach Z2 auf dem Switch 48, so wird zwischen den beiden Zonen Z1 und Z2 lediglich das notwendige Minimum an Daten, die in der vertrauenswürdigen Zone Z2 benötigt werden, übertragen.
Deshalb erfolgt bereits in der nicht vertrauenswürdigen Zone Z1 eine Defragmentierung des Protokolls auf das notwendige Minimum, im Rahmen der Defragmentierung werden (zur Detektion von Anomalien) ebenfalls bereits Plausibilisierungen durchgeführt. Dies erfolgt über die Z1 -Ethernet-Sensoren 38.
Nach dem Übertragen des notwendigen Minimums an Daten aus der nicht vertrauenswürdigen Zone Z1 an die vertrauenswürdige Zone Z2 wird das notwendige Minimum an Daten durch die Z2-Ethernet-Sensoren 40 plausibilisiert. Vor jedem Kontext-Wechsel/ dem Umschalten der Z1- und Z2-Task wird zusätzlich über die Host-Sensoren 43, 45 des BS bzw. SV überprüft, ob keine invalide Zonen-Transition und/oder Veränderung des Programmablaufs (bspw. durch Überprüfung der Rücksprungadresse auf dem Stack) stattgefunden hat.
Für den Fall, dass keine Anomalitäten detektiert wurden, gibt der ETH Sensor 40 der vertrauenswürdigen Zone Z2 die Nutzung der Daten in der vertrauenswürdigen Zone Z2 frei. Die Daten werden als vertrauenswürdige Daten eingestuft (Trusted Data). Für den Fall, dass Anomalien detektiert wurden, verwirft der ETH Sensor 40 die Daten und/oder erzeugt ein Ereignis 220. Außerdem kommuniziert der ETH Sensor 40 die Anomalitäten bzw. das zugehörige Ereignis 220 an die Recheneinheit 100b der vertrauenswürdigen Zone Z2 bzw. an den zugehörigen Ereignismanager 30 der vertrauenswürdigen Zone Z2. Die Sensorlogik des ETH Sensors 40 liegt in der vertrauenswürdigen Zone Z2, da die Ereignisse durch eine vertrauenswürdige Instanz ausgewertet werden müssen.
Kommunikationen innerhalb der Zonen Z1, Z2 bzw. von der vertrauenswürdigen Zone Z2 zur nicht vertrauenswürdigen Zone Z1 können erfolgen unter optionaler Verwendung von ETH Sensoren 38 für die nicht vertrauenswürdige Zone Z1. Weiterhin sind für die Inter-Zonen-Kommunikation von Z2 nach Z1 sowie die Intra-Zonen-Kommunikation die Sensoren optional, ggf. kann hierfür auch ein reduzierter Sensor-Satz zum Einsatz kommen (bspw. Default-Sensoren mit geringer Implikation auf Performance). Der Switch 48 SWT leitet die Kommunikation der Recheneinheit 100b der nicht vertrauenswürdigen Zone Z1 über den Kommunikationsadapter 32 zu den weiteren IDS Instanzen 34 weiter. Der Kommunikationsadapter 32 befindet sich in der Recheneinheit 100b. Er fragt zyklisch den Ereignisbericht 242 vom Ereignismanager 30 an und kommunizert diesen an die weiteren IDS Instanzen 34. Wenn die Kommunikation über Ethernet an die weiteren IDS Instanzen 34 erfolgt (was die bevorzugte Variante ist), dann würde diese vom Kommunikationsadapter 32 des Haupt-Mikrocontrollers bzw. Recheneinheit 100b über den Switch 48 an die weiteren IDS-Instanzen 34 erfolgen.
Fig. 4 zeigt schematisch ein vereinfachtes Blockdiagramm von Aspekten einer Recheneinrichtung 100b gemäß weiteren bevorzugten Ausführungsformen. Die Recheneinrichtung 100b weist vorliegend beispielhaft vier Rechenkerne K1, K2, K3, K4 auf, von denen der erste Rechenkern K1 zur Verarbeitung von Kommunikationsnachrichten, insbesondere CAN-Nachrichten, ausgebildet ist. Daher kann bei weiteren bevorzugten Ausführungsformen der erste Rechenkern K1 auch als "CAN-Core" bezeichnet werden. Die weiteren Rechenkerne K2, K3 sind zur Ausführung von (gegebenenfalls unterschiedlichen Instanzen von) Anwendungsprogrammen vorgesehen und können bei weiteren bevorzugten Ausführungsformen daher auch als "Anwendungskerne" bzw. englisch "Application Cores" K2, K3 bezeichnet werden. Der vierte Rechenkern K4 ist zur Verarbeitung von Ethernet- Kommunikationsnachrichten ausgebildet und kann daher bei weiteren bevorzugten Ausführungsformen auch als Ethernet-Kern bzw. ETH-Kern bzw. englisch als "ETH Core" K4 bezeichnet werden. Dem ersten Rechenkern K1 ist ein erster Supervisor SV1, insbesondere ein CAN lightweight Supervisor, zugeordnet, und dem vierten Rechenkern K4 ist ein zweiter Supervisor SV2, insbesondere ein ETH (Ethernet) lightweight Supervisor, zugeordnet.
Bei weiteren bevorzugten Ausführungsformen ist der erste Rechenkern K1 zwei Zonen Z1 , Z2 zugeordnet. Bei weiteren bevorzugten Ausführungsformen ist auch der vierte Rechenkern K4 zwei Zonen Z1 , Z2 zugeordnet.
Bei weiteren bevorzugten Ausführungsformen ist dem ersten Rechenkern K1 ein Anwendungsprogramm AP zum Senden und/oder Empfangen von CAN- Nachrichten zugeordnet, wobei das Bezugszeichen 11 eine erste Instanz dieses Anwendungsprogramms bezeichnet, welche erste Instanz 11 der ersten Zone Z1 zugeordnet und zum Empfangen von CAN-Nachrichten ausgebildet ist. Das Bezugszeichen I2 bezeichnet demgegenüber eine zweite Instanz dieses Anwendungsprogramms, welche der zweiten Zone Z2 zugeordnet und zum Empfangen von CAN-Nachrichten ausgebildet ist. Die Bezugszeichen I3, I4 bezeichnen entsprechende Instanzen zum Senden von CAN-Nachrichten, die jeweils ebenfalls einer der beiden Zonen Z1, Z2 zugeordnet sind. Weiterhin kann der Rechenkern K1 CAN Sensoren 60 umfassen, die in der vertrauenswürdigen Zone Z2 angeordnet sind. Optional können in dem Rechenkernen K1 auch CAN Sensoren 62 in der nicht vertrauenswürdigen Zone Z1 vorgesehen sein.
Bei weiteren bevorzugten Ausführungsformen können die Unterbrechungsanforderungen Rx, Timer, SW durch den ersten Rechenkern K1 bearbeitet werden, beispielsweise durch Ausführen einer entsprechenden Unterbrechungsroutine.
Bei weiteren bevorzugten Ausführungsformen ist dem vierten Rechenkern K4 ein Anwendungsprogramm zum Senden und/oder Empfangen von Ethernet- Nachrichten zugeordnet, wobei das Bezugszeichen 11 eine erste Instanz dieses Anwendungsprogramms bezeichnet, welche erste Instanz 11 der ersten Zone Z1 zugeordnet und zum Empfangen von Ethernet-Nachrichten ausgebildet ist. Das Bezugszeichen I2 bezeichnet demgegenüber eine zweite Instanz dieses Anwendungsprogramms, welche der zweiten Zone Z2 zugeordnet und zum Empfangen von Ethernet-Nachrichten ausgebildet ist. Die Bezugszeichen I3, I4 bezeichnen entsprechende Instanzen zum Senden von Ethernet-Nachrichten, die jeweils ebenfalls einer der beiden Zonen Z1 , Z2 zugeordnet sind.
Bei weiteren bevorzugten Ausführungsformen wird eine Trennung der beiden Zonen Z1, Z2 innerhalb der Rechenkerne K1, K4 jeweils unter Verwendung mindestens einer Speicherschutzeinrichtung SSE1, SSE4 bewerkstelligt.
Wie vorstehend bereits erwähnt sind die beiden Anwendungskerne K2, K3 zur Ausführung von Anwendungsprogrammen ausgebildet, die bzw. deren einzelne Instanzen als Rechtecke innerhalb der betreffenden Anwendungskerne K2, K3 angedeutet sind. Bei weiteren bevorzugten Ausführungsformen ist der zweite Rechenkern K2 der zweiten Zone Z2 zugeordnet, und der dritte Rechenkern K3 ist der ersten Zone Z1 zugeordnet. In dem Rechenkern K2 sind beispielhaft DPI Sensoren 64 (Deep Package Inspection für eine tiefergehende Payload- Analyse), Ereignismanager 30, Kommunikationsadapter 32, Proxies 70, BSW Stack 72 (BSW: Basis Software), V-CAN 74 (virtueller CAN) sowie V-ETH 76 (virtueller Ethernet) vorgesehen. In dem Rechenkernen K3 sind beispielhaft DPI Sensoren 84, Kommunikationsadapter 32, Proxies 90, BSW Stack 92, V-CAN 94 sowie V-ETH 96 vorgesehen. Wie bereits beschrieben befindet sich der Kommunikationsadapter 32 sowohl in der vertrauenswürdigen Zone Z2 wie in der nicht vertrauenswürdigen Zone Z1.
Bei weiteren bevorzugten Ausführungsformen weist die Recheneinrichtung 100b einen flüchtigen Speicher, insbesondere einen Arbeitsspeicher (RAM) 1030b auf, der beispielsweise vergleichbar zu der Darstellung gemäß Figur 4, in unterschiedliche Bereiche aufgeteilt ist, welche jeweils unterschiedlichen Rechenkernen K1, K2, K3, K4 bzw. deren Zonen Z1, Z2 zugeordnet sind.
Beispielsweise ist ein erster Bereich B1 des Arbeitsspeichers 1030b der Recheneinrichtung 100b gemäß Figur 13 dem ersten Rechenkern K1 zugeordnet, wobei ein erster Teilbereich B1_1 der ersten Zone Z1 und ein zweiter Teilbereich B1_2 der zweiten Zone Z2 zugeordnet ist. Der erste Teilbereich B1_1 ist wiederum unterteilt in einen vertrauenswürdigen Bereich und in einen nicht vertrauenswürdigen Bereich, getrennt durch eine Speicherschutzeinrichtung SSE. Der zweite Teilbereich B 1_2 ist wiederum unterteilt in zumindest einen vertrauenswürdigen Bereich und in einen nicht vertrauenswürdigen Bereich, wiederum getrennt durch eine Speicherschutzeinrichtung SSE. Eine vergleichbare Aufteilung in entsprechende Bereiche bzw. Teilbereiche B4, B4_1, B4_2 ist bei weiteren bevorzugten Ausführungsformen auch für den vierten Rechenkern K4 möglich. Der erste Teilbereich B4_1 ist wiederum unterteilt in einen vertrauenswürdigen Bereich Tb1b und in einen nicht vertrauenswürdigen Bereich Tb1a, getrennt durch eine Speicherschutzeinrichtung SSE. Der zweite Teilbereich B4_2 ist wiederum unterteilt in zumindest einen vertrauenswürdigen Bereich Tb2a und in einen nicht vertrauenswürdigen Bereich Tb2b, wiederum getrennt durch eine Speicherschutzeinrichtung SSE.
Weitere Bereiche B2, B3 des Arbeitsspeichers 1030b sind bei weiteren bevorzugten Ausführungsformen beispielsweise den Anwendungskernen K2, K3 zuordenbar. Bei weiteren bevorzugten Ausführungsformen ist beispielsweise der Bereich B2 weiter aufteilbar in einen vertrauenswürdigen Bereich T und in einen nicht-vertrauenswürdigen Bereich NT. Vergleichbares kann bei weiteren bevorzugten Ausführungsformen auch für den dritten Anwendungskern K3 gelten.
Bei weiteren bevorzugten Ausführungsformen können ein oder mehrere weitere Speicherschutzeinrichtungen, die kollektiv mit dem Bezugszeichen SSE' bezeichnet sind, vorgesehen sein, um eine jeweilige Trennung gemäß bevorzugten Ausführungsformen hinsichtlich beispielsweise Leserechten und/oder Schreibrechte und/oder Ausführungsrechte zu realisieren.
Bei weiteren bevorzugten Ausführungsformen kann die Recheneinrichtung 100b beispielsweise die Funktionalität eines Gateway bereitstellen, also eines Netz- Kopplungselements, das beispielsweise einen CAN-Bus (vgl. den CAN Core K1) mit einem Ethernet-Netzwerk (vgl. den ETH Core K4) koppeln kann. Bei weiteren bevorzugten Ausführungsformen kann beispielsweise der erste Rechenkern K1 die Funktion einer sogenannten highspeed routing engine für CAN-Nachrichten übernehmen, und/oder der vierte Rechenkern K4 die Funktion einer sogenannten highspeed engine für Ethernet-Nachrichten.
Der Switch SWT 48, insbesondere ein Ethernet-Switch, übermittelt Ethernet- Ereignisse an den Rechenkern K4, der für das Handling der Ethernet- Kommunikation zuständig ist. Außerdem kommuniziert der Rechenkern K4 zu anderen IDS Instanzen 32.
Bei einer Kommunikation zwischen den Zonen, nämlich von der nicht vertrauenswürdigen Zone Z1 zu der vertrauenswürdigen Zone Z2, können die Daten von dem Proxy 90 der nicht vertrauenswürdigen Zone Z1 zu einem isolierten Pufferspeicher im nicht vertrauenswürdigen Bereich der Zone Z1 geschoben werden. Der der vertrauenswürdigen Zone Z2 zugeordnete Sensor 60 validiert diese Daten vor der Benutzung in der vertrauenswürdigen Zone Z2. Sofern keine Anomalien detektiert werden, gibt der Sensor 60 der vertrauenswürdigen Zone Z2 die Nutzung dieser Daten für die vertrauenswürdige Zone Z2 frei (Trusted Data). Sofern Anomalien bzw. unerwartete Ereignisse detektiert werden, verwirft der Sensor 60, der der vertrauenswürdigen Zone Z2 zugeordnet ist, die Daten. Außerdem kommuniziert der Sensor 60, der der vertrauenswürdigen Zone Z2 zugeordnet ist, die detektierten Anomalien als Ereignis 220 an den Ereignismanager der vertrauenswürdigen Zone Z2. Die Logik des Sensors 60 ist in der vertrauenswürdigen Zone Z2 angeordnet, weil die entsprechenden Ereignisse durch eine vertrauenswürdige Instanz evaluiert werden müssen. Weiterhin kann eine Kommunikation zwischen vertrauenswürdiger Zone Z2 und nicht vertrauenswürdiger Zone Z1 stattfinden. Außerdem kann eine Kommunikation von der vertrauenswürdigen Zone Z2 zu der nicht vertrauenswürdigen Zone Z1 ohne weiteres erfolgen. Weitere Sensoren 62 können optional vorgesehen werden.
Eine Kommunikation von der nicht vertrauenswürdigen Zone Z1 in die vertrauenswürdige Zone Z2 kann - wie bereits ausgeführt - auch durch Sensoren in der nicht vertrauenswürdigen Zone Z1 und der vertrauenswürdigen Zone Z2 überwacht werden. Daten, die nach der Defragmentierung nicht mehr vorhanden bzw. in der vertrauenswürdigen Zone Z2 nicht benötigt werden, werden durch in der nicht vertrauenswürdigen Zone Z1 angeordneten Sensoren 38, 62 überwacht. Die in der vertrauenswürdigen Zone Z2 angeordneten Sensoren 40, 60 überwachen dann die Daten, die nach der Defragmentierung (das notwendige Minimum an Daten) von der nicht vertrauenswürdigen Zone Z1 in die vertrauenswürdige Zone Z2 übertragen wird. Wird bereits durch die Sensoren 38, 62 der nicht vertrauenswürdigen Zone Z1 etwas detektiert, muss ebenfalls eine Kommunikation von den in der nicht vertrauenswürdigen Zone Z1 angeordneten Sensoren 38, 62 and den in der vertrauenswürdigen Zone Z2 angeordneten Ereignismanager 30 beispielsweise im Rahmen generierte Ereignisse 220 möglich sein.
Der Ereignismanager 30 der vertrauenswürdigen Zone Z2 aggregiert, reduziert oder priorisiert, formatiert oder persistiert eingehende Ereignisse 220. Der Ereignismanager 66 ist in der vertrauenswürdigen Zone Z2 angeordnet, da die Ereignisse durch eine Vertrauensinstanz (Trusted Instanz) verarbeitet, priorisiert und gespeichert werden müssen.
Der Kommunikationsadapter 32 ist zum Teil in der vertrauenswürdigen Zone Z2 angeordnet. Der Kommunikationsadapter 32 steuert die Kommunikation mit dem Ereignismanager 30, der ebenfalls in der vertrauenswürdigen Zone Z2 angeordnet ist. Außerdem übernimmt der Kommunikationsadapter 32 die Kommunikation zu einem HSM (Hardware Security Modul, das der Authntifizierung und/oder der Verschlüsselung dienen kann), um einen sicheren, authentifizierten und vertraulichen Kanal zu der übergeordneten IDS Instanz 34 sicherzustellen. Der Kommunikationsadapter 32 ist zum Teil in der vertrauenswürdigen Zone Z2 angeordnet, weil er ebenfalls mit vertrauenswürdigen Instanzen wie beispielsweise dem Ereignismanager 30 der vertrauenswürdigen Zone Z2 oder dem HSM kommunizieren muss.
Der Kommunikationsadapter 32 soll die Kommunikation zu anderen IDS Instanzen 34 wie beispielsweise Infotainment über den Switch SWT 48 übernehmen. Da er mit nicht vertrauenswürdigen Instanzen (Infotainment, CCU) kommuniziert, ist er teilweise in der nicht vertrauenswürdigen Zone Z1 angeordnet.
Beispielhaft wird ein Kommunikationsablauf beschieden, in dem der Ereignisbericht 242 zyklisch an die übergeordnete Instanz 34 gesendet wird. Hierzu frägt der Kommunikationsadapter 32 aus der vertrauenswürdigen Zone Z2 bei dem Ereignismanager 30 in der vertrauenswürdigen Zone Z2 an, in dem Pufferspeicher 206 selektierte Ereignisse 226 wie in Verbindung mit Figur 2 beispielhaft beschrieben zur Verfügung zu stellen. In dem Ereignisbericht 242 sind bestimmte besonders vertrauenswürdige Informationen hinsichtlich Verschlüsselung und/oder Authentifizierung, insbesondere die veränderliche Größe 254 und/oder die Authentifizierungs-Information 256 und/oder die Verschlüsselung 258 enthalten. Diese Größen können von dem Sicherheitsmodul 73, welches oben bereits als HSM (Hardware Security Modul) beschrieben wurde, bereitgestellt werden. Das Sicherheitsmodul 73, beispielhaft im sogenannten BSW Stack 72 untergebracht, liefert beispielsweise eine entsprechende Zufallszahl 273 bzw. Abschnitt einer solchen Zufallszahl als veränderliche Größe 254. Der Ereignismanager 30 und/oder der Kommunikationsadapter 32 der vertrauenswürdigen Zone 22 übernimmt diese veränderliche Größe 254 im Rahmen des Ereignisberichts 242. Der Ereignisbericht 242 gelangt im Klartext wieder an das Sicherheitsmodul 73, welches die Verschlüsselung durch den Schlüssel 258 vornimmt und dem Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 zur Verfügung stellt. Der so verschlüsselte Ereignisbericht 242 gelangt nun über den Kommunikationsadapter 32 in den nicht mehr vertrauenswürdigen Bereich Z1, also an den Kern K3. Entsprechend wird der Ereignisbericht 242 in den Puffer der Zone B3 geschrieben. Beispielhaft könnte der Ereignisbericht 242 wie bereits ausgeführt über den Ethernet-Core K4 an die übergeordnete Instanz 32 kommuniziert werden wie der entsprechende Pfeil angedeutet. Hierzu wird der Ereignisbericht 242 aus dem Speicher im Bereich B3 an den Speicherbereich B4_1 transferiert, ist also nun im Ethernet-Core K4. Die weitere Kommunikation erfolgt von K4 über den Sendevorgang I3 beispielsweise über den Ethernet- Switch 48 etc. an die über Ethernet angebundene übergeordnete Instanz 32.
Der nachfolgende Kommunikationsablauf beschreibt den Empfang eines Bestätigungssignals 408, 416, das von der übergeordneten Instanz 34 generiert wurde (wie nachfolgend in Verbindung mit den Figuren 5-10 näher beschrieben). Das entsprechende Bestätigungssignal 408, 416 gelangt über den Ethernet Switch 48 an den Ehernet-Core K4 und dort in die nicht vertrauenswürdige Zone Z1. Über den in dem nicht vertrauenswürdigen Bereich Z1 angesiedelten Teil des Kommunikationsadapters 32 werden die Daten zunächst in den Bereich B3, dort in den nicht vertrauenswürdigen Bereich NT, gepuffert. Auf die dort isolierten Daten hat der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 Zugriff. Der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 erkennt, dass es sich um verschlüsselte Daten handelt. Die Entschlüsselung erfolgt nun, indem der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 die Daten zur Entschlüsselung an das Sicherheitsmodul 73 sendet bzw. dem entsprechenden Sicherheitsmodul 73 Zugriff auf die Daten zuweist.
Anschließend gelangt das von dem Sicherheitsmodul 73 entschlüsselte Signal im Klartext wieder zurück an den Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2. Dann erkennt der Kommunikationsadapter 32, dass weitere sicherheitsrelevante Informationen wie beispielsweise die veränderliche Größe 254‘ und/oder eine Authentifizierungs-Information 256‘ Bestandteil des Bestätigungssignals 408, 416 sind (vergleiche Figur 5). In einer besonders bevorzugten Variante wurde die veränderliche Größe 254‘ des Bestätigungssignals 408, 416 durch die übergeordnete Instanz 34 so gebildet, dass die veränderliche Größe 254 wie durch den letzten Ereignisbericht 242 übermittelt (und ebenfalls durch das Sicherheitsmodul 73 generiert) als veränderliche Größe 254‘ für das Bestätigungssignal 408, 416 verwendet wurde. Somit führt das Sicherheitsmodul 73 eine entsprechende Überprüfung durch, ob die veränderliche Größe 254‘ des Bestätigungssignals 408, 416 mit der veränderlichen Größe 254 insbesondere des letzten Ereignisberichts 242 übereinstimmt. Ist dies der Fall, so kann eine entsprechende Freigabeinformation für das Bestätigungssignal 408, 416 generiert werden. Der Kommunikationsadapter 32 der vertrauenswürdigen Zone Z2 sendet in diesem Zusammenhang beispielsweise ein Signal 410 an den Ereignismanager 30, die im Rahmen des letzten Ereignisberichts 242 übertragenen Ereignisse 226 im Pufferspeicher 206 zu löschen. Weiterhin könnte zusätzlich auch die entsprechende Authentifizierungs-Information 256‘ für eine Verifizierung bzw. Authentifizierung des empfangenen Bestätigungssignals 408,416 wie beschrieben verwendet werden.
Nachfolgend werden die Kommunikationsabläufe zwischen Ereignismanager 30 und Kommunikationsadapter 32 innerhalb des Steuergeräts bzw. Gateways 20, sowie zwischen Kommunikationsadapter 32 und zumindest einerweiteren IDS Instanz 34 innerhalb des Fahrzeugs 18 sowie zwischen der weiteren IDS Instanz 34 und dem Backend 36 anhand der Figuren 5-10 beispielhaft beschrieben.
Die Kommunikation vom Steuergerät wie beispielsweise das Gateway 20 zu weitere(n) IDS Instanz(en) 34 (beispielsweise ein zentraler Ereignis-Logger innerhalb des Fahrzeugs 18) sollte sicherstellen, dass die weitere IDS Instanz 34 oder der Ereigniss-Logger über nicht ausgelesene Einträge bzw. im Speicher 206 gespeicherte Ereignisse 236 bzw. selektierte Ereignisse 226 informiert wird. Das Steuergerät bzw. das Gateway 20 soll einen Ereignisbericht 242 auf regulärer Basis zu der weiteren IDS Instanz 34 schicken, bevorzugt über ein sogenannten Heartbeat-Signal (zyklisches Signal, welches zur Überprüfung einer ordnungsgemäßen Verbindung der Kommunikationsteilnehmer verwendet werden kann). Das Heartbeat-Signal (inklusive des Ereignisberichts 242) soll verschlüsselt und authentisch sein. Vorzugsweise sollen die übermittelten Informationen authentisch (gegebenenfalls unter Verwendung der Authentifizierungsinformation 256) und verschlüsselt, vorzugsweise zufällig bzw. unter Verwendung einer Zufallszahl 273 zwischen Steuergerät bzw. Gateway 20 und der weiteren IDS Instanz 34 ausgetauscht werden. Vorzugsweise sollte der Ereignisbericht 242 eine feste Länge 257 aufweisen, sollte verschlüsselt und authentifiziert werden. Jeder verschlüsselte Ereignisbericht 242 sollte sich von den vorhergehenden Ereignisberichten 242 unterscheiden, selbst wenn der übermittelte Status sich nicht verändert hat. Die Kommunikation von der weiteren IDS Instanz 34 zum Steuergerät bzw. Gateway 20 bzw. dem zugehörigen Kommunikationsadapter 32 sollte sich außerdem durch nachfolgende Funktionalitäten auszeichnen. Der Daten-Logger bzw. die IDS Instanz 34 sollte die Ereignisse 236 bzw. zugehörige Ereignisberichte 242 so schnell wie möglich einiesen, um ein Überlaufen insbesondere des Speichers bzw. Pufferspeichers 206 zu verhindern. Die Ereignisberichte 242 sollten über ein Diagnoseinterface ausgelesen werden können, beispielsweise auf Anforderung. Alternativ könnte der Ereignisbericht 242 komplett zyklisch verschickt werden. Die Ereignisberichte 242 sollten auf regulärer Basis, vorzugsweise authentisch und verschlüsselt bzw. getarnt kommuniziert bzw. ausgelesen werden, selbst wenn keine neuen selektierten Ereignisse 226 im Rahmen eines neuen Ereignisberichts 242 verfügbar sind.
Das Steuergerät bzw. Gateway 20 sollte auf eine Ausleseanforderung 240 mit einer Antwort bzw. einem Ereignisbericht 242 mit einer fixen Länge, verschlüsselt und authentifiziert antworten. Jede verschlüsselte Antwort bzw. Ereignisbericht 242 soll sich von den vorhergehenden Antworten bzw. Ereignisberichten 242 unterscheiden, selbst wenn sich der Inhalt nicht geändert hat. Beispielhaft erfolgt dies durch die stets veränderte Größe 254 wie bereits beschrieben.
Gemäß Figur 5 selektiert der in der vertrauenswürdigen Zone Z2 angeordnete Ereignismanager 30 zunächst ein erstes selektiertes Ereignis 226.1 sowie anschließend ein zweites selektiertes Ereignis 226.2. Diese werden vom Ereignismanager 30 wie beschrieben verarbeitet. Die selektierten Ereignisse 226.1, 226.2 sind also im Speicher 206 abgelegt. Der in der vertrauenswürdigen Zone Z2 angesiedelte Teil des Kommunikationsadapters 32 enthält ein Signal 400, ein zeitabhängiges Interruptsignal (Timer IRQ). Vorzugsweise ist das zeitabhängige Signal 400 zyklisch gebildet, sodass dadurch zyklisch die Übersendung eines Ereignisberichts 242 von dem Kommunikationsadapter 32 an weitere IDS Instanzen 34 im Fahrzeug 18 eingeleitet wird. Doch selbst bei keinen neuen Ereignissen 226.1, 226.2 wird wie nachfolgend beschrieben ein Signal (in Form eines „normalen“ Ereignisberichts 242) von dem Kommunikationsadapter 32 an die weitere IDS Instanz 34 geschickt (vergleiche Signal 406). Besonders bevorzugt wird jedoch die Übersendung eines Ereignisberichts 242 nicht in Abhängigkeit von dem Erhalt eines Ereignisses 220 bzw. selektierten Ereignisses 226 getriggert, sondern zyklisch (durch Zeitablauf der Zykluszeit). Dies ist besonders vorteilhaft, da auch später die Übertragung an weitere IDS Instanzen 34 und/oder das Backend 36 immer zyklisch, also nach Ablauf einer bestimmten Zeit erfolgt. Damit ist für einen Angreifer das Verhalten des Ereignismanagers 30 bzw. Anomalieerkennung undurchsichtig. Der Angreifer weiß nie, ob sein Angriff detektiert wurde, was detektiert wurde und wie das System zur Anomalieerkennung arbeitet.
Nachdem der Kommunikationsadapter 32 das Signal 400 (Timer Interrupt) empfangen hat, fordert der in der vertrauenswürdigen Zone Z2 angesiedelte Teil des Kommunikationsadapter 32 einen Ereignisbericht 242 von dem Ereignismanager 30 an, Signal 402. Der Ereignismanager 30 erstellt den entsprechenden Ereignisbericht 242, der die zuvor selektierten Ereignisse 226.1 und/oder 226.2 (mit jeweiligen generischen Metadaten 217 und ereignisabhängigen Metadaten 216) sowie eine veränderte Größe 254 umfasst. Weiterhin werden entsprechende Fülldaten 255 hinzugefügt, sodass die feste Länge 257 des Ereignisberichts 242 erreicht wird (in Kenntnis der Länge der noch zu bildenden Authentifizierungs-Information 256). Weiterhin generiert beispielsweise der Ereignismanager 30 aus der veränderten Information 254, den selektierten Ereignissen 226.1,226.2 sowie den Fülldaten 255 eine Authentifizierungs-Information 256 unter Verwendung eines bestimmten Algorithmus. Die so gebildete Authentifizierungs-Information 256 komplettiert den Ereignisbericht 242. Anschließend erfolgt die Verschlüsselung des kompletten Ereignisberichts 242 mit dem Schlüssel 258. Der verschlüsselte Ereignisbericht 242 gelangt als Signal 404 an den in der vertrauenswürdigen Zone Z2 angesiedelten Teil des Kommunikationsadapters 32. Verschlüsselung (unter Verwendung der veränderten Information 254 und/oder des Schlüssels 258) und Authentifizierung (Bildung der Authentifizierung-Information 256) könnten im Ereignismanager 30 und/oder im Kommunikationsadapter 32 bzw. unter Verwendung des Sicherheitsmoduls 73 (ebenfalls in der vertrauenswürdigen Zone Z2 angeordnet) wie bereits beschrieben erfolgen, wenn die entsprechenden Sicherheitserfordernisse erfüllt sind.
Alternativ könnte der Kommunikationsadapter 32 und/oder das Sicherheitsmodul 73 den Ereignisbericht 242 verschlüsseln beispielsweise in Abhängigkeit von einer Zufallszahl 273. Besonders bevorzugt wird zur Verschlüsselung immer eine neue Zufallszahl 273 gebildet, beispielsweise durch Hashing. Dies erschwert weiter die Entschlüsselung einer übertragenen Nachricht bzw. des verschlüsselten Ereignisberichts 242. Gegebenenfalls übernimmt der Kommunikationsadapter 33 die Authentifizierung unter Verwendung der Authentifizierungsinformation 256 und/oder das Hinzufügen der veränderlichen Größe 254 und/oder das abschließende Verschlüsseln des gesamten Ereignisberichts 242 mit der Verschlüsselung 258.
Ein entsprechendes Signal 406 wird auf den Timer Interrupt (Signal 400) selbst dann geschickt, wenn kein neuer Ereignisbericht 242 durch Auftreten neuer selektierter Ereignisse 226 vom Ereignismanager 30 zur Verfügung gestellt wird. Dann wird eine Dummy-Nachricht mit dem Datenformat eines Ereignisberichts 242 verwendet und durch eine Zufallszahl bzw. die stets veränderte Größe 254 verschlüsselt (unter Verwendung des Schlüssels 258) an die weitere IDS Instanz 34 übertragen. Auch Dummy-Nachrichten werden immer durch stets veränderte Größen 254 bzw. neue Zufallszahlen verschlüsselt, sodass auch bei Nicht- Auftreten von neuen selektierten Ereignissen 226 immer zyklisch andere bzw. verschlüsselte Nachrichten (Signal 406) übertragen werden. Durch das zyklische Übertragen kann das Funktionieren einer ordnungsgemäßen Kommunikationsverbindung zwischen dem Kommunikationsadapter 32 und der weiteren IDS Instanz 34 überprüft werden. Wie bereits beschrieben erfolgt das versenden des Ereignisbericht 242 über den in der nicht vertrauensvollen Zone Z1 angeordneten Teil des Kommunikationsadapter 32.
Nach dem Erhalt der von dem Kommunikationsadapter 32 versendeten Nachricht (Signal 406) durch die weitere IDS Instanz 34 sendet die weitere IDS Instanz 34 ein Bestätigungssignal (408) an den Kommunikationsadapter 32, insbesondere an den in der nicht vertrauenswürdigen Zone Z1 angeordneten Teil des Kommunikationsadapter 32. Das weitere Vorgehen wurde bereits in Verbindung mit Figur 4 näher ausgeführt. Nach Erhalt des Bestätigungssignals 408 generiert der in der vertrauenswürdigen Zone Z2 angeordnete Teil des Kommunikationsadapters 32 eine Anforderung an den Ereignismanager 30, die zwischengespeicherten gegebenenfalls reduzierten selektierten Ereignisse 226 bzw. zugehörigen Ereignisberichte 242 zu löschen bzw. wieder zu überschreiben (Signal 410). In einem alternativen Ausführungsbeispiel überprüft die übergeordnete Instanz 34 und/oder das Backend 36 die Authentizität des empfangenen verschlüsselten Ereignisberichts 242. Hierzu entschlüsselt die übergeordnete Instanz 34 und/oder das Backend 36 die empfangene Nachricht, nämlich den verschlüsselten Ereignisbericht 242, unter Verwendung des bekannten Schlüssels 258. Dann steht der Ereignisbericht 242 im Klartext zur Verfügung. Unter Verwendung des entsprechenden Algorithmus (der auch durch Ereignismanager 30 oder Kommunikationsadapter 32 zur Erstellung der Authentifizierungs-Information 256 verwendet wurde) zur Bildung der Authentifizierung-Information 256 wird der Ereignisbericht 242 authentifiziert. Hierzu werden wieder sämtliche Daten des empfangenen und entschlüsselten Ereignisberichts 242 (mit Ausnahme der Authentifizierungs-Information 256) herangezogen und daraus eine entsprechende Authentifizierungs-Information 256‘ gebildet. Anschließend erfolgt der Vergleich der gebildeten Authentifizierungs-Information 256‘ mit der im Rahmen des Ereignisberichts 242 empfangenen Authentifizierungslnformation 256. Bei einer Übereinstimmung gilt der empfangene Ereignisbericht 246 als authentisch. Erst nach erfolgter Authentifizierung kann in dieser Variante die weitere Datenkommunikation mit der Instanz der höheren Ebene oder niedrigeren Ebene erfolgen. Erst bei einer erfolgreichen Authentifizierung wird in dieser Ausführung das Signal 408 (Bestätigungssignal) an den Kommunikationsadapter 32 verschickt, der daraufhin das Signal 410 zur Freigabe zum Überschreiben der selektierten Ereignisse 226.1,226.2 an den Ereignismanager 30 versendet.
Vorzugsweise soll auch die Antwort bzw. das Bestätigungssignal 408, 416 eine feste Länge 257‘ aufweisen. Vorzugsweise soll das Bestätigungssignal 408 authentifiziert und verschlüsselt sein. Jede Antwort bzw. Bestätigungssignal 408 durch die übergeordnete Instanz 34 und/oder das Backend 36 soll sich unterscheiden, selbst wenn sich der Inhalt nicht verändert hat.
Ein Beispiel für ein solches Bestätigungssignal 408, 416 ist Figur 5 zu entnehmen. Das Bestätigungssignal 408, 416 ist ähnlich aufgebaut wie der Ereignisbericht 242. Das Bestätigungssignal 408,416 umfasst eine veränderliche Größe 254‘. Die veränderliche Größe 254‘ verändert sich für jedes neu versendete Bestätigungssignal 408, 416. Die veränderliche Größe 254‘ könnte wieder beispielsweise durch eine Zufallszahl, einen Zähler, eine Zeit realisiert werden.
Besonders bevorzugt könnte die veränderliche Größe 254‘ des Bestätigungssignals 408,416 gebildet werden, indem die veränderliche Größe 254 des Ereignisbericht 242 wie eben übermittelt und, gegebenenfalls durch das Sicherheitsmodul 73 erzeugt, verwendet wird. Hierzu ist die übergeordnete Instanz 34,36, dazu eingerichtet, die veränderliche Größe 254 aus dem empfangenen Ereignisbericht 242 zu extrahieren und in das Bestätigungssignal 408,416 einzufügen. Damit könnte in einem nachfolgenden Schritt auch eine Authentifizierung des Bestätigungssignals 408,416 erfolgen, indem die empfangene veränderliche Größe 254‘ des Bestätigungssignals 408,416 verglichen wird mit der veränderlichen Größe 254 des eben zuvor gesendeten Ereignisberichts 242. Bei einer Übereinstimmung wird auf ein authentisches Bestätigungssignal 406,408 geschlossen. Außerdem muss die veränderliche Größe 254‘ in der übergeordneten Instanz 34,36 nicht selbst generiert werden. Daran kann die Freigabe des Speichers 206 folgen.
Weiterhin umfasst das Bestätigungssignal 408,416 bestimmte Daten 255‘, beispielsweise in Form beliebiger Pattern. Weiterhin umfasst das Bestätigungssignal 408, 416 eine Authentifizierungs-Information 256‘. Die Authentifizierungs-Information 256‘ könnte ähnlich wie beim Ereignisbericht 242 wieder über einen bestimmten Algorithmus gebildet werden, der auf die restlichen Daten des Bestätigungssignals 408, 416, nämlich die veränderliche Größe 254‘ sowie die Daten 255‘ zurückgreift. Die so gebildete Authentifizierung Information 256‘ komplettiert das Bestätigungssignal 408, 416. Es weist eine feste Länge 257‘ auf. Dann erfolgt eine Verschlüsselung unter Verwendung eines Schlüssels 258‘. Optional könnte auch auf diese Verschlüsselung 258‘ verzichtet werden.
Die empfangenden Instanzen (beispielsweise die übergeordnete Instanz 34 das Backend 36) und/oder der Kommunikationsadapter 32 bzw. der Ereignismanager 30 sind wiederum in der Lage, das Bestätigungssignal 408,412 zu entschlüsseln (unter Verwendung des Schlüssels 258‘) und zu authentifizieren. Hierzu wird wiederum aus den empfangenen Daten (veränderliche Größe 254‘, Daten 255‘) unter Verwendung eines entsprechend bekannten Algorithmus die sich daraus ergebende Authentifizierungs-Informationen 256“ ermittelt und mit der erhaltenen Authentifizierungs-Informationen 256‘ verglichen. Bei Übereinstimmung wird von Authentizität ausgegangen. Sofern die erhaltene Authentifizierungsinformationen 256‘ in Ordnung ist, könnte das Signal 410 zur Freigabe des Speichers 206 erzeugt werden. Sollte die Authentifizierungsinformationen 256‘ nicht in Ordnung sein, könnte dieses Signal 410 nicht generiert werden, sodass die in dem Speicher 206 enthaltenen selektierten Ereignisse 226 (noch) nicht gelöscht werden.
Auch die weitere IDS Instanz 34 empfängt zyklisch ein Timer Interrupt- Signal 412, welches ähnlich wie das Signal 400 wie bereits beschrieben gebildet wird. Auf dieses Interrupt-Signal 412 sendet die weitere IDS Instanz 34 wiederum eine verschlüsselte Nachricht, Signal 414. Diese Nachricht enthält gegebenenfalls den Ereignisbericht 242 oder einen fahrzeugbezogenen Ereignisbericht (unter Einbeziehung weiterer Ereignisberichte) wie über Signal 406 vor dem Kommunikationsadapter 32 übermittelt. Ebenso wie beim Kommunikationsadapter 32 wird die Nachricht durch die weitere IDS Instanz 34 verschlüsselt, insbesondere durch eine sich ständig ändernde Größe 254‘ wie beispielsweise eine Zufallszahl 273. Sollte der Kommunikationsadapter 32 keinen Ereignisbericht 242 übermittelt haben, da beispielsweise kein neues selektiertes Ereignis 226 auftrat, wird wiederum eine Dummy-Nachricht mit dem selben Datenformat wie ein Ereignisbericht 242 verwendet und verschlüsselt an das Backend 36 übertragen (Signal 414). Das Backend 36 sendet ein Bestätigungssignal 416 und/oder eine weitere Mitteilung bzw. Aufforderung zum Überschreiben der im Pufferspeicher 206 zwischengespeicherten Ereignisse 236 oder Ähnliches an die weitere IDS Instanz 34. Das Bestätigungssignal 416 kann wie oben beschrieben gebildet sein.
Nach Erhalt des Signals 410 bezüglich der Ereignisfreigabe selektiert der Ereignismanager 30 weitere selektierte Ereignisse 226.3 sowie 226.4. Der weitere Ablauf lässt sich Figur 6 entnehmen. Zwischenzeitlich selektierte der Ereignismanager 30 noch ein weiteres Ereignis 226.5. Erneut gelangt ein Timer Interrupt (Signal 420) an den Kommunikationsadapter 32. Dieser fordert nun für das Gateway 20 einen Ereignisbericht 242 an (Signal 422). Der Ereignismanager 30 übersendet an den Kommunikationsadapter 32 einen Ereignisbericht 242, der auf den selektierten Ereignissen 226.3, 226.4, 226.5 basiert, Signal 424. Nach Erhalt des Ereignisberichts 242 übersendet der Kommunikationsadapter 32 den durch eine neue veränderliche Größe 254 wie eine Zufallszahl verschlüsselten und authentifizierten Ereignisbericht 242 an die weitere IDS Instanz 34, Signal 426. Den Erhalt bestätigt die weitere IDS Instanz 34 durch ein Bestätigungssignal 428. Das Betätigungssignal 428 kann gebildet sein wie in Verbindung mit Betätigungssignal 408 (Figur 5) beschrieben. Nach Erhalt des Bestätigungssignals 428 sendet der Kommunikationsadapter 32 wiederum eine Anforderung an den Ereignismanager 30, die dem Ereignisbericht 242 zugrunde liegenden selektierten Ereignisse 226.3, 226.4, 226.5, zu überschreiben bzw. zu löschen, Signal 430. Zwischen dem Aussenden des Signals 424 und dem Empfang des Signals 430 wird zwischenzeitlich ein weiteres selektiertes Ereignis 226.6 selektiert. Dieses selektierte Ereignis 226.6 jedoch darf noch nicht überschrieben werden, da dieses selektierte Ereignis 226.6 noch nicht Basis für einen schon an den Kommunikationsadapter 32 übermittelten Ereignisbericht 242 war. Insofern bezieht sich das Signal 430 nicht darauf, das selektierte Ereignis 226.6 zu überschreiben, sondern lediglich diejenigen selektierten Ereignisse 226.3, 226.4, 226.5 zu überschreiben, die bereits im Rahmen des letzten Ereignisberichts 242 übermittelt wurden.
Wiederum tritt auch bei der weiteren IDS Instanz 34 ein Timer Interrupt auf (Signal 432) wie bereits beschrieben. Dadurch wird die weitere IDS Instanz 34 veranlasst, den in Signal 426 neu empfangenen Ereignisbericht 242 verschlüsselt an das Backend 36 zu übertragen, Signal 434. Den Erhalt der entsprechenden Nachricht 434 quittiert das Backend 36 durch ein entsprechendes Bestätigungssignal 436, welches an die weitere IDS Instanz 34 gesendet wird. Das Bestätigungssignal 436 könnte gebildet sein wie das Bestätigungssignal 408 bzw. 416.
Der weitere Ablauf wird in Figur 7 gezeigt. Erneut tritt ein weiterer Timer Interrupt für den Kommunikationsadapter 32 auf, Signal 440. Daraufhin sendet der Kommunikationsadapter 32 aus der vertrauenswürdigen Zone Z2 eine Anforderung an den Ereignismanager 30 zur Übersendung eines Ereignisberichts 242, Signal 442. Der Ereignismanager 30 übersendet einen Ereignisbericht 242, der das zwischenzeitlich selektierte Ereignis 226.6 beinhaltet, Signal 444. Der Kommunikationsadapter 32 verschlüsselt den Ereignisbericht 242 unter Verwendung einer sich neuen veränderlichen Größe 256, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, und übersendet den verschlüsselten Ereignisbericht 242 über den in der nicht vertrauenswürdigen Zone Z1 befindlichen Teil des Kommunikationsadapter 32 an die weitere IDS Instanz 34, Signal 446. Bei Erhalt sendet die weitere IDS Instanz 34 eine Bestätigung, Signal 448, bei dessen Erhalt der Kommunikationsadapter 32 eine Anforderung an den Ereignismanager 30 sendet, die bereits übermittelten Ereignisse 226.6 zu überschreiben bzw. freizugeben, 450.
Wiederum empfängt die weitere IDS Instanz 34 einen Timer Interrupt, Signal 452. Daraufhin wird der verschlüsselte Ereignisbericht 242 gegebenenfalls zusammen mit weiteren Ereignisberichten weiterer IDS-Systeme fahrzeugbezogen an das Backend 36 übermittelt. Das Backend 36 sendet an die weiteren IDS Instanz(en) 34 ein Bestätigungssignal und/oder eine Anforderung, entsprechende Ereignisse freizugeben bzw. zu überschreiben etc., Signal 456.
Bei dem beispielhaften Ablauf gemäß Figur 8 ist zwischen dem Versenden des letzten Ereignisberichts 242 und dem neuen Auftreten eines Timer Interrupts (Signal 460) kein neues selektiertes Ereignis 226 aufgetreten. Nach Erhalt des Timer Interrupts 460 sendet der Kommunikationsadapter 32 aus der vertrauenswürdigen Zone Z2 ein entsprechendes Anforderungssignal 462 für einen neuen Ereignisbericht 242 an den Ereignismanager 30. Der Ereignismanager 30 generiert - obwohl neues selektiertes Ereignis 226 aufgetreten ist - einen Ereignisbericht 242 mit einem Dummy-Inhalt, der dann an den Kommunikationsadapter 32 versendet wird, Signal 464. Dieser Dummy- Inhalt kann von den weiteren IDS Instanzen 34 und/oder vom Backend 36 als solcher erkannt werden. Der Kommunikationsadapter 32 verschlüsselt in der vertrauensvollen Zone Z2, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, den empfangenen Ereignisbericht 242, der einen Dummy- Inhalt aufweist, mit einer neuen veränderten Größe 254, versendet und verschickt den verschlüsselten und authentifizierten Ereignisbericht 242 an die weitere IDS Instanz 34, Signal 466. das Versenden erfolgt wieder aus der nicht vertrauenswürdige Zone Z1. Der Erhalt wird durch die weitere IDS Instanz 34 bestätigt, Signal 468. Bei dessen Erhalt sendet der Kommunikationsadapter 32 erneut ein Anforderungssignal an den Ereignismanager 30, die letzten selektierten Ereignisse 226 zu überschreiben, Signal 470. Dies erfolgt selbst dann, wenn keine neuen selektierten Ereignisse 226 wie in dieser Konstellation vorliegen.
Erneut erhält die weitere IDS Instanz 34 einen Timer Interrupt, Signal 472. Daraufhin verschlüsselt die weitere IDS Instanz 34 den zuletzt erhaltenen verschlüsselten Ereignisbericht 242 wie von dem Kommunikationsadapter 32 übermittelt und versendet ihn gegebenenfalls mit weiteren Ereignisberichten von weiteren IDS-Systemen fahrzeugbezogen an das Backend 36. Das Backend 36 sendet ein Bestätigungssignal 476 und/oder eine Anforderung zur Freigabe der zu Grunde liegenden Ereignisse etc. an die weitere IDS Instanz 34.
Bei der Kommunikationssequenz der Figur 9 erhält der Kommunikationsadapter 32 erneut einen Timer Interrupt, Signal 480. Bei diesem Timer Interrupt 480 kann es sich um ein spezielles Signal handeln, so dass der Kommunikationsadapter 32 eine Ereigniszusammenfassung vom Ereignismanager 30 anfordert (und nicht einen der üblichen Ereignisberichte 242), Signal 482. Der Ereignismanager 30 übersendet die Ereigniszusammenfassung an den Kommunikationsadapter 32, Signal 484. dies erfolgt wieder in der vertrauenswürdigen Zone Z2. Bei der Ereigniszusammenfassung können übergeordnete Informationen enthalten sein wie beispielsweise die verschiedenen Zählerstände 231 für die verschiedenen Ereignisarten 218, oder das Auftreten einer neuen Ereignisart etc. Wiederum wird auch die Ereigniszusammenfassung vom Kommunikationsadapter 32 durch eine neue veränderliche Größe 254 wie eine Zufallszahl, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, in der sicherheitsrelevanten Zone Z2 verschlüsselt und an weitere IDS Instanzen 34 übertragen, Signal 486. die Übertragung erfolgt wieder aus der nicht sicherheitsrelevanten Zone Z1. Sobald die IDS Instanz 34 die verschlüsselte Ereigniszusammenfassung von dem Kommunikationsadapter 32 erhalten hat, sendet die weitere IDS Instanz 34 die Ereigniszusammenfassung besonders bevorzugt verschlüsselt an das Backend 36 weiter. Im Ausführungsbeispiel ist für den Sendevorgang zwischen der weiteren IDS Instanz 34 und dem Backend 36 kein Timer Interrupt zur Initiierung des Kommunikationsvorgangs vorgesehen. Alternativ könnte dieser jedoch wiederum zyklisch wie auch die Übersendung eines üblichen Ereignisberichts initiiert werden. Bei der Kommunikationssequenz der Figur 10 sendet das Backend 36 eine Anforderung für einen Ereignisbericht an die weitere IDS Instanz 34 aus, Signal 490. Die weitere IDS Instanz 34 sendet eine verschlüsselte Anforderung für einen Ereignisbericht, beispielsweise über eine Diagnoseschnittstelle, an den Kommunikationsadapter 32, Signal 492. Die Verschlüsselung kann wieder über die veränderliche Größe 254‘ wie beispielsweise eine Zufallszahl erfolgen, die sich insbesondere für jede Verschlüsselung ändert. Nach Erhalt der Anforderung 492 sendet der Kommunikationsadapter 32 in der sicherheitsrelevanten Zone Z2 eine Anfrage für einen Ereignisbericht 242 an den Ereignismanager 30, Signal 494. Nach Erhalt der entsprechenden Anfrage 494 übersendet der Ereignismanager 30 den Ereignisbericht 242 an den Kommunikationsadapter 32, Signal 496. Der Kommunikationsadapter 32 verschlüsselt den Ereignisbericht 242 beispielsweise über eine neue veränderliche Größe 254 wie eine Zufallszahl, gegebenenfalls unter Verwendung des Sicherheitsmoduls 73, und übersendet diesen aus der nicht sicherheitsrelevanten Zone Z1 an die weitere IDS Instanz 34, Signal 498. Nach Erhalt des verschlüsselten Ereignisbericht 242 sendet die weitere IDS Instanz 34 den Ereignisbericht 242 an das Backend 36. Den Erhalt quittiert das 36 Backend an die weitere IDS Instanz 34, Signal 492. Den Erhalt des Quittierungssignals 492 bestätigt die weitere IDS Instanz 34 dem Kommunikationsadapter 32, Signal 494. Nach Erhalt des entsprechenden Signals 494 sendet der Kommunikationsadapter 32 eine entsprechende Anforderung an den Ereignismanager 30, zumindest die im Rahmen des letzten Ereignisberichts 242 übermittelten Ereignisse 220 freizugeben bzw. zu überschreiben.
Die beschriebenen Verfahren können in einer Recheneinheit, Computer bzw. Controller implementiert sein, insbesondere in einem Steuergerät eines Fahrzeugs 18. Gleichermaßen kann das Verfahren im Rahmen eines Computerprogramms erstellt sein, das eingerichtet ist, das Verfahren auszuführen, wenn es auf einem Computer ausgeführt wird. Weiterhin kann das Computerprogramm auf einem maschinenlesbares Speichermedium abgespeichert sein. Gleichwohl kann das Programm beispielsweise als Software- „over-the-air“ drahtlos oder über Diagnoseschnittstellen kabelgebunden aufgespielt werden.

Claims

Ansprüche
1. Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug, wobei mindestens ein Sensor (24,26, 28) zur Anomalieerkennung Daten (211) erhält erhält, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht und bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und an einen Ereignismanager (30) weiterleitet, dadurch gekennzeichnet, dass zumindest eine vertrauenswürdige Zone (Z2) und eine nicht vertrauenswürdige Zone (Z1) vorgesehen werden, wobei zumindest ein Sensor (24,26, 28; 40, 60) und/oder der Ereignismanager (30) der vertrauenswürdigen Zone (Z2) zugeordnet sind.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zumindest ein Kommunikationsadapter (32) in derselben Zone (Z2) angeordnet ist wie der Ereignismanager (30), wobei der Kommunikationsadapter (32) der Kommunikation eines von dem Ereignismanager (30) zumindest teilweise erstellten Ereignisberichts (242) dient.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Kommunikationsadapter (32) auch einer nicht vertrauenswürdigen Zone (Z1) zugeordnet wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Sensor (24,26, 28) in der vertrauenswürdigen Zone (Z2) zumindest Daten (211), insbesondere defragmentierte Daten, von einem Sensor (38, 62) enthält, der in der nicht vertrauenswürdigen Zone (Z1) angeordnet ist, wobei der Sensor (24, 26, 28) in der vertrauenswürdigen Zone (Z2) die erhaltenen Daten (211) auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis (220) erzeugt und/oder wobei der Sensor (38,62) in der nicht vertrauenswürdigen Zone (Z1) die erhaltenen Daten (211) auf Anomalien prüft und bei Vorliegen einer Anomalie ein Ereignis (220) erzeugt.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Versenden des Ereignisberichts (242) erfolgt, indem der Kommunikationsadapter (32) in der vertrauenswürdigen Zone (Z2) den Ereignisbericht (242) in einen Speicher der nicht vertrauenswürdigen Zone (Z1) bringt, auf den der Kommunikationsadapter (32) in der nicht vertrauenswürdigen Zone (Z1) zugreifen und verschicken kann.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ereignisbericht (242) zumindest eine sich für jeden Ereignisbericht (242) verändernde Größe (254) und/oder zumindest eine Authentifizierungs-Information (256) umfasst und/oder durch eine Verschlüsselung (258) verschlüsselt wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein der vertrauenswürdigen Zone (Z2) zugeordnetes Sicherheitsmodul (73) eine sich für jeden Ereignisbericht (242) veränderliche Größe (254) und/oder eine Authentifizierungs-Information (256) und/oder eine Verschlüsselung (258) bereitstellt.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach Versenden des Ereignisberichts (242) ein Bestätigungssignal (408,416) empfangen wird, welches von dem Kommunikationsadapter (32) der nicht vertrauenswürdigen Zone (Z1) empfangen und an den Kommunikationsadapter (32) der vertrauenswürdigen Zone (Z2) weitergeleitet wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Bestätigungssignal (408,416) zumindest eine für jedes Bestätigungssignal (408,416) veränderliche Größe (254‘) und/oder zumindest bestimmte Daten bzw. Pattern (255‘) und/oder zumindest eine Authentifizierungs-Information (256‘) und/oder zumindest eine konstante Länge (257‘) umfasst und/oder mit einer Verschlüsselung (258‘) verschlüsselt wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Kommunikationsadapter (32) der vertrauenswürdigen Zone (Z2) das empfangene Bestätigungssignal (408,416) unter Verwendung eines in der sicherheitsrelevanten Zone (Z2) angeordneten Sicherheitsmoduls (73) entschlüsselt und/oder authentifiziert.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das empfangene Bestätigungssignal (408,416) entschlüsselt und/oder authentifiziert wird, indem überprüft wird, ob die veränderliche Größe (256) des verschickten Ereignisberichts (242) in dem Bestätigungssignal (408,416) enthalten ist.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einer Übertragung von Daten von einer Zone (Z1) in die andere Zone (Z2) der Sensor (24, 26, 28) die Daten vor einer Benutzung überprüft, insbesondere ob ein Ereignis (220) aufgetreten ist und/oder dass für den Fall, dass kein Ereigniss (220) detektiert wurde, die Daten für die Benutzung in der anderen Zone (Z2) freigegeben werden.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem Auftreten eines Ereignisses (220) die Daten nicht in die andere Zone (Z2) transferiert werden und/oder der Sensor (24,26, 28) das Ereignis (220) an den Ereignismanager (30) weiterleitet.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ereignismanager (30) und/oder der Kommunikationsadapter (32) der vertrauenswürdigen Zone (Z2) und/oder der Sensor (24,26,28) der vertrauenswürdigen Zone (Z2) und/oder das Sicherheitsmodul (73) auf einem Rechnerkern (K2) implementiert sind.
15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest einer Recheneinrichtung (100a; 100b) bestimmte ausführbaren Anwendungsprogramme (AP) zu einer von den wenigstens zwei Zonen (Z1, Z2) zugeordnet werden, wobei die Zonen (Z1, Z2) Ressourcen der Recheneinrichtung (100b; 100b) charakterisieren, die für eine Ausführung eines betreffenden Anwendungsprogramms (AP) nutzbar sind, optional Ausführen wenigstens eines der Anwendungsprogramme (AP) in Abhängigkeit der ihm zugeordneten Zone (Z1, Z2).
16. Verfahren nach wenigstens einem der vorstehenden Ansprüche , weiter aufweisend :
Austauschen von ersten Daten zwischen verschiedenen Zonen (Z1, Z2) über einen Pufferspeicher, insbesondere Arbeitsspeicher, wobei insbesondere das Austauschen der ersten Daten zwischen der ersten Zone (Z1) und der zweiten Zone (Z2) folgende Schritte aufweist: d1) Kopieren der ersten Daten in einen der ersten Zone (Z1) zugeordneten ersten Pufferspeicherbereich, d2) Überprüfen der kopierten ersten Daten, und, insbesondere in Abhängigkeit der Überprüfung, d3) Kopieren der ersten Daten aus dem der ersten Zone (Z1) zugeordneten ersten Pufferspeicherbereich in einen der zweiten Zone (Z2) zugeordneten zweiten Pufferspeicherbereich.
17. Vorrichtung zur Ausführung des Verfahrens nach wenigstens einem der vorstehenden Ansprüche.
PCT/EP2021/056539 2020-03-28 2021-03-15 Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug WO2021197822A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022558498A JP7467670B2 (ja) 2020-03-28 2021-03-15 特に自動車におけるデータの異常を処理するための方法
CN202180024770.8A CN115398427A (zh) 2020-03-28 2021-03-15 用于处理数据异常的方法，特别是在机动车辆中

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020204059.1 2020-03-28
DE102020204059.1A DE102020204059A1 (de) 2020-03-28 2020-03-28 Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug

Publications (1)

Publication Number Publication Date
WO2021197822A1 true WO2021197822A1 (de) 2021-10-07

Family

ID=75111563

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/056539 WO2021197822A1 (de) 2020-03-28 2021-03-15 Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug

Country Status (4)

Country Link
JP (1) JP7467670B2 (de)
CN (1) CN115398427A (de)
DE (1) DE102020204059A1 (de)
WO (1) WO2021197822A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102023100444A1 (de) 2023-01-10 2024-07-11 Giesecke+Devrient Mobile Security Germany Gmbh Verfahren und System zum Betreiben einer Internet der Dinge (IoT) -Vorrichtung

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110138456A1 (en) * 2003-10-03 2011-06-09 Verizon Services Corp. Security management system for monitoring firewall operation
US20170169231A1 (en) * 2014-12-23 2017-06-15 Intel Corporation Technologies for enhanced user authentication using advanced sensor monitoring
US20190158461A1 (en) * 2015-12-22 2019-05-23 Mcafee, Llc Attestation device custody transfer protocol
EP3528163A1 (de) * 2018-02-19 2019-08-21 Argus Cyber Security Ltd Kryptische fahrzeugabschirmung
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3012643B1 (fr) * 2013-10-28 2017-03-17 Oberthur Technologies Systeme de detection d'intrusion dans un dispositif comprenant un premier systeme d'exploitation et un deuxieme systeme d'exploitation
CN105450406B (zh) * 2014-07-25 2018-10-02 华为技术有限公司 数据处理的方法和装置
JP6981078B2 (ja) * 2017-07-28 2021-12-15 大日本印刷株式会社 セキュアエレメント、コンピュータプログラム、デバイス、サーバ及びデバイス監視方法
JP7026298B2 (ja) * 2017-09-29 2022-02-28 積水ハウス株式会社 セキュアモードとノンセキュアモードとを選択的に切り替え可能なシステム
DE102017221889B4 (de) * 2017-12-05 2022-03-17 Audi Ag Datenverarbeitungseinrichtung, Gesamtvorrichtung und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung oder Gesamtvorrichtung

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110138456A1 (en) * 2003-10-03 2011-06-09 Verizon Services Corp. Security management system for monitoring firewall operation
US20170169231A1 (en) * 2014-12-23 2017-06-15 Intel Corporation Technologies for enhanced user authentication using advanced sensor monitoring
US20190158461A1 (en) * 2015-12-22 2019-05-23 Mcafee, Llc Attestation device custody transfer protocol
EP3528163A1 (de) * 2018-02-19 2019-08-21 Argus Cyber Security Ltd Kryptische fahrzeugabschirmung
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Also Published As

Publication number Publication date
CN115398427A (zh) 2022-11-25
JP7467670B2 (ja) 2024-04-15
JP2023519910A (ja) 2023-05-15
DE102020204059A1 (de) 2021-09-30

Similar Documents

Publication Publication Date Title
DE102014224694B4 (de) Netzwerkgerät und Netzwerksystem
DE60115615T2 (de) System, einrichtung und verfahren zur schnellen paketfilterung und -verarbeitung
DE19741246C2 (de) Vorrichtung und Verfahren zur Erhöhung der Sicherheit in Netzwerken
EP3625950B1 (de) Datenverarbeitungseinrichtung, gesamtvorrichtung und verfahren zum betrieb einer datenverarbeitungseinrichtung oder gesamtvorrichtung
EP3192226B1 (de) Vorrichtung und verfahren zur steuerung eines kommunikationsnetzwerks
EP3506144A1 (de) Verfahren und system zum überprüfen einer integrität einer kommunikation
DE102018202996A1 (de) Verfahren zum Durchführen einer Diagnose
WO2021197822A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
DE102017212474A1 (de) Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus
DE102014101835A1 (de) Verfahren zur Kommunikation zwischen abgesicherten Computersystemen sowie Computernetz-Infrastruktur
WO2021197820A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197823A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
EP3603012A1 (de) Verfahren und vorrichtung zum schutz einer kommunikation zwischen mindestens einer ersten kommunikationseinrichtung und wenigstens einer zweiten kommunikationseinrichtung insbesondere innerhalb eines kommunikationsnetzwerkes einer industriellen fertigung und/oder automatisierung
DE102018216959B4 (de) Verfahren zur Absicherung eines Datenpakets durch eine Vermittlungsstelle in einem Netzwerk, Vermittlungsstelle und Kraftfahrzeug
WO2021197828A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197821A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2018177614A1 (de) Schutzeinrichtung, verfahren und gerät enthalten eine schutzeinrichtung zum schutz eines mit dem gerät verbundenen kommunikationsnetzwerks
WO2021197826A1 (de) Vorrichtung zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197824A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197827A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
EP4014424B1 (de) Verfahren zum verarbeiten von telegrammen in einem automatisierungsnetzwerk, automatisierungsnetzwerk, masterteilnehmer und slaveteilnehmer
DE102016203534A1 (de) Verfahren und Analysemodul zur Überprüfung von verschlüsselten Datenübertragungen
EP1496665B1 (de) Verfahren zur Festlegung von Sicherheitseinstellungen in einem Automatisierungsnetz
DE102022209766A1 (de) COMPUTERIMPLEMENTIERTES VERFAHREN ZUR EINLEITUNG VON MITIGATIONSMAßNAHMEN IN EINEM SYSTEM
EP3713187A1 (de) Verfahren zur übertragung von datenpaketen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21713336

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022558498

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21713336

Country of ref document: EP

Kind code of ref document: A1