WO2021197820A1 - 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
WO2021197820A1
WO2021197820A1 PCT/EP2021/056534 EP2021056534W WO2021197820A1 WO 2021197820 A1 WO2021197820 A1 WO 2021197820A1 EP 2021056534 W EP2021056534 W EP 2021056534W WO 2021197820 A1 WO2021197820 A1 WO 2021197820A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
data
events
memory
random number
Prior art date
Application number
PCT/EP2021/056534
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 CN202180024768.0A priority Critical patent/CN115398429A/zh
Publication of WO2021197820A1 publication Critical patent/WO2021197820A1/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
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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

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 should reliably send the event reports, for example via an interface to an external node. After a successful transmission to the external node, the event entries can be deleted locally, particularly preferably after one 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.
  • the time of saving is selected randomly within a certain time interval.
  • non-deterministic behavior for the attacker is ensured.
  • the mean value of the storage cycles can be configured so that it can be adapted to the system conditions, operating time, etc.
  • the time of storage which is selected at random, depends on a random number. This in turn realizes the non-deterministic behavior.
  • the random number is selected individually for each control device and / or for each vehicle. This ensures the non-deterministic behavior of the anomaly reduction. Even if the random number is disclosed in one vehicle, the knowledge acquired cannot be transferred to another vehicle. The use of different random numbers across the vehicle fleet ensures that different events are selected for each vehicle. In the event of a fleet attack, this increases the variety of data and enables a broader evaluation or complete reconstruction of the attack.
  • the time of saving is determined by linking a random number or a range of a random number with a time interval, in particular by multiplication. This reliably results in a mean value of the time interval. However, the actual time of saving is not chosen deterministically for the attacker.
  • the random number is regenerated cyclically and / or as a function of certain system events such as the transition from system states such as, for example, reset, start-up, transition to a sleep mode, etc. This ensures that the current status of the event report is permanently saved when the system status changes.
  • the storage takes place in a non-volatile memory, in particular a flash memory.
  • the procedure can ensure that the use of inexpensive storage technologies with greatly reduced write cycles will tend to be possible.
  • the storage in the non-volatile memory takes place in that events stored in a further memory, in particular a buffer memory or non-volatile memory, are also stored in the non-volatile memory. If there is no connectivity to a higher-level unit or if there is a change to a different system state, the events can be saved locally. This could also be done through permanent storage. This is particularly preferably done by initiating storage when a state change, for example into a sleep mode or restart, takes place in a control device.
  • data are stored redundantly in the non-volatile memory, with a check being made when data is restored as to whether the stored data are authentic or with integrity. This increases security by only using data of integrity.
  • the event manager assigns further information to the respective event received, in particular generic metadata such as, for example, the counter reading in an event counter and / or a time signal and / or a length of the selected event and / or a number of events that are not processed further, whereby a point in time for storing the further information is selected at random. This enables an improved, in-depth analysis. In particular, the time of entry can be reconstructed and set in relation to other events.
  • the relationship between the individual events can be determined using a counter reading.
  • the counter readings allow simple statements to be made as to whether certain events with associated metadata have been lost or not saved.
  • the fill level of the buffer can be reconstructed over the length without this having to be read out dynamically and explicitly.
  • Figure 1 schematically components of an anomaly 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. 3 shows a more detailed structure of an event manager
  • FIG. 4 shows a flow chart for selecting a further processing
  • FIG. 5 shows a flow chart for the counter incrementation
  • FIG. 6 shows a flow chart for storing a non-volatile
  • FIG. 7 shows a schematic overview for the random selection of an event to be saved
  • FIG. 8 the assignment of certain quantities used in FIG. 7,
  • 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 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 over 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 in networked production systems can be equipped with the functions described.
  • a communication component such as the control device or the gateway 20 comprises at least one anomaly detection 22.
  • the data 211 arriving via the interfaces of the respective communication systems 25, 27, 29 are each transmitted 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 filter algorithms are used in sensors 24, 26, 28 for this purpose.
  • Rule sets are stored which are used for the detection and classification of 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) are not forwarded to the destination address. Alternatively, the sensors 24, 26, 28 can also be used to reduce events 220 (reduced event or pre-reduced event 221). This reduction could reduce the load on the event manager 30, for example by only forwarding a small portion of useful data from data 211 or data packets containing anomalies. This is particularly advantageous with large amounts of data, such as those that occur with Ethernet connections.
  • 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 who 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.
  • the respective event types 218 are often provided with an event-specific event ID or event ID. There is a plurality of predefined event types 218 for a variety of data sources with associated unique Event ID 's.
  • 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.
  • Other anomalies that affect the host system 29 can also be taken into account as events 220 with associated event types 218 such as CPU load too high, memory access violation, error in code execution, ECU reset detected, corrupted log entries in the non-volatile memory, 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 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 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 randomly, in addition to the event-dependent metadata 216, the added generic metadata 217 as selected events 226.
  • 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.
  • 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 sensor 24, 26, 28 could optionally select a useful data area 219 at random, which is forwarded to the event manager 30.
  • the sensor 24, 26, 28 has determined that it is an anomaly according to a specific event type 218 (event ID or event ID, ID).
  • the sensor 24, 26, 28 therefore generates event-dependent metadata 216 as shown in FIG. 2b.
  • event-dependent metadata 216 among other things source and destination address (MACa, MACb), the event type 218 and the selected user data area 219 are used.
  • 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 in Frame available, 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 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) that 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 as to when this event 220 occured.
  • 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, which includes those in the buffer memory 206 stored selected events 226 (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 data shown in the event report 242 are provided with an encryption 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.
  • IDS sensors 24, 26, 28 forward events 220 or reduced events 221 to event manager 30.
  • a memory 206 in particular a volatile memory or buffer memory 206, can no longer record all events 220 very quickly with a large number of events 220 to be forwarded with large amounts of data or event-dependent metadata 216. This is due to the high data transfer rate or the large amount of data that can be transferred. It can therefore make sense that one or more IDS sensors 24, 26, 28 already make a preselection of the events 220 to be forwarded and / or a data reduction (reduced events 221) according to certain criteria. These criteria are said to be characterized by low predictability.
  • the selection of certain events 220 to be forwarded and / or the reduction of the events to reduced events 221 is preferably carried out randomly to increase security.
  • a random or arbitrary selection or reduction of specific events 220 or data blocks of an Ethernet frame is not deterministic and disguised for an attacker.
  • the random selection or reduction could for example, based on a random number 273 that is individual for a specific control unit. In the simplest case, the same random number 273 could also be used for the other random-based scenarios as a reference in the event manager 30 for the reduction or prioritization of all events 220, the random storage of events 220 or the like. Alternatively, corresponding random numbers could also be regenerated in the control unit.
  • Incoming messages or data 211 usually have corresponding header information 214 (for example specific address data) and subsequent useful data 213.
  • header information 214 for example specific address data
  • header information 214 for example specific address data
  • header information 214 for example specific address data
  • subsequent useful data 213 usually a lot of header information is contained that is not absolutely necessary for the anomaly evaluation.
  • only certain address components that are absolutely necessary are forwarded as part of a reduced event 221 within the scope of the event-dependent metadata 216, such as the address of the source (for example MAC address, for example 48 bits), the address of the destination (for example MAC address, for example 48 bits) and the ID number that led to an anomaly (event type 218).
  • Other information such as the physical port or port ID where the frame was received, IP address of the source or destination, details of the UDP / TCP port of the source or destination, if such information is contained in the frame, must be required not or not completely transmitted in event 220.
  • the useful data area 219 to be forwarded or selected is selected on a random basis from the useful data 213 of the incoming data 211, as has already been explained in connection with FIGS. 2a and 2b.
  • the number of the start date beginning of the memory area of the user data to be transferred, e.g. byte no. Xyz
  • the offset of the selected user data area 219 could be fixed.
  • the user data bytes with the numbers 538-547 would be in addition to the minimum address information (source address, destination address) as selected user data area 219 in the frame of the event 221 reduced in this way is forwarded to the event manager 30.
  • the offset of the selected useful data area 219 can be varied, preferably randomly.
  • the selected user data area 219, in particular the starting or end area selected user data area 219 preferably depends on a random number 273.
  • This random number 273 is particularly preferably dependent on the control unit or gateway 20. Particularly preferably, the random number 273 is unique, i.e. only for this special control unit assigned once.
  • the random number 273 can also be renewed. This results in the following advantages. By renewing the random number, different events 220 are logged or selected for the same attack sequence (sequence of events 220). This is also the case if the attack only takes place on a single control unit / vehicle 18 and not on the entire fleet.
  • Not all events 220 can be logged or selected as part of an attack sequence (event burst).
  • An event reduction for the event report 242 follows
  • An event report 242 with reduced events 221 is forwarded to the higher-level entity 34, 36 completely between two attack sequences. As a result, after the same attack sequence has been repeated several times, the complete attack sequence can be reconstructed via the event reports 242.
  • the sensor 26 could preferably adapt the selection of the random number 273 or the different ranges of the random number 273 to the size of the incoming data 211, in particular to the size of the incoming useful data 213 can be selected such that the selection of a specific reduced useful data area 219 also only falls within this small data area of the useful data 213.
  • the random number 273 or the considered area of the random number 273 must therefore be correspondingly small.
  • the random number 273 or the considered area of the random number 273 must be selected to be so large that the selection of a specific reduced useful data area 219 can also cover this large data area of the useful data 213.
  • the random number 273 is therefore correspondingly larger.
  • the complete message (which was also sent to the further control units and was also appropriately detected and forwarded there with appropriately equipped sensors 26) with the complete data area could be included an analysis in the backend 36 by merging a large number of reduced events 221 from several control units. This is because other control units with the same sensor function as described now also randomly select other user data areas 219 (with other randomly selected start or end addresses) which, after merging several reduced events 221, contain a large part of the (useful) data area 213 or the entire data area of the useful data 213 on the basis of the sub-areas or selected user data areas 219 of the various control units.
  • an event 220 could be reconstructed by various control devices from the reduced events 221 or selected user data area 219 by, for example, sub-data area 538-547 (of one selected user data area 219) from one control unit, sub-data area 548-557 (another selected user data area 219) is made available by a further control device, partial data area 558-567 (of a further selected user data area 219) is made available by another control device and the respective selected user data areas 219, for example, in a higher-level control device or in the backend 36 again to the complete (useful) Data area 213 can be combined.
  • This is the case in particular in the case of a so-called broadcast attack on the entire vehicle fleet or a so-called multicast attack on parts of the vehicle fleet.
  • the random determination of the beginning and / or the end of the forwarded or selected useful data area 219 is preferably carried out anew after certain events (cyclical, start-up of the control device, reset of a control device, etc.).
  • the random number 273 could be generated anew.
  • another range of the random number 273 could be used for the Generation of the beginning and / or end of the data area to be forwarded or selected useful data area 219 can be used.
  • 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 an Ethernet frame with high transmission rates, however, such events 220 would quickly lead to an overflow of the buffer memory 206. In the case of IDS CAN sensors 24, corresponding data 211 occurs anyway at a lower data rate and a lower data volume, so that complete events 220 can tend to be passed on and stored here. In principle, however, the data could also be reduced there as described accordingly.
  • Data 211 are received by the sensor 24, 26, 28 and / or data 211 are evaluated as to whether an anomaly is present. If there is an anomaly, the data 211 is reduced. The reduction takes place by reducing the address area or header 214 and / or the data area or useful data 213. The address area 214 could be reduced by selecting the target address and / or the source address.
  • the user data 213 is reduced in a random manner.
  • the user data 213 is reduced in a random manner by randomly selecting a start value and / or an end value of a sub-area of the user data 213.
  • the offset of the data area (number of transmitted data) is fixed at a specific value.
  • the reduced events 221 are transmitted to the event manager 30.
  • the reduced events 221 contain reduced address data and / or reduced or selected user data 219.
  • the random number 273 is updated as a function of certain system states (cyclical, start-up, reset, etc.). Alternatively, the random number 273 could be updated randomly and / or in a time-controlled manner.
  • the selected useful data area 219 can depend on the size of the useful area 213 of the received data 211.
  • the event manager 30 has several functional blocks that interact with one another.
  • Each of the events 220 or reduced events 221 detected by the sensors 24, 26, 28 reach a block 202.
  • Block 202 is used to select the incoming events 220 or reduced events 221 that are to be processed further.
  • block 202 is used to prioritize and reduce events 220, 221.
  • Each event 220 or each reduced event 221 likewise arrives at a block 204, which serves as a counter 204 for events 220, 221.
  • a corresponding counter is incremented, in particular a global event counter 205.
  • the counter 204 has different counters Z1, Z2, ... Zn for different types of events 218 (ID1, ID2, ... IDn) as detailed above in connection with the corresponding sensors 24, 26, 28.
  • the global event counter 205 in turn represents the sum of all counter readings of the counters Z1, Z2, ... Zn for different types of events 218 (ID1, ID2, ... IDn).
  • the output signal 231 of block 204 or counter contains the counter readings of all events 220, 221, that is to say counter readings of the respective event-dependent counters Z1, Z2,.
  • Block 204 is set up to receive a reset signal 222, which represents a reset request to the counter (s) or event counter (s) 204, 205.
  • Block 204 receives a signal from block 202 for a reduction status 225, for example “event reduction active”. Event reduction is then active in block 202, for example, if only a reduced number of specific events 220, 221 are further processed as selected events 226.
  • the events processed by block 202 reach a block 206 as selected events 226, which serves as a memory or buffer memory for the selected events 226 supplied by block 202 and includes the corresponding logic for this.
  • the memory 206 reports the filling level or the memory occupancy 228 back to the block 202.
  • the memory 206 is preferably a volatile memory, in particular a buffer memory of a RAM.
  • the time signal 224 in particular a global time signal 224, reaches the memory 206 or the block for buffering the selected events 226.
  • the memory 206 is part of the event manager 30.
  • Certain events 236 stored or buffered in the memory 206 arrive at a block 210 which is used to communicate event reports 242 as a function of the selected events 226 or stored events 236.
  • the block 210 for communication of events also receives output signals 231 of the event counter 204, for example counter readings of the counters Z1, Z2 ... Zn for the respective event types 218 and / or the counter reading of the global event counter 205.
  • the cryptography module carries out cryptography operations such as encryption operations, authentication and authentication operations and random number generation, etc. With the aid of the cryptography module 212, encrypted communication between the block 210 and the outside world can take place.
  • the cryptography module 212 in particular encrypts the event report 242 using the encryption 257 indicated in FIG. 2d.
  • the cryptography module 212 can likewise carry out an authentication of the event report 242 using the authentication information 256, cf. likewise FIG. 2d.
  • Block 210 can be located in the communication adapter 32 and / or in the event manager 30.
  • the block 210 outputs corresponding event reports 242.
  • Block 210 receives a request command 240 to read out corresponding events 236 stored in memory 206, 208.
  • the request command 240 can take place cyclically and / or upon explicit request.
  • the block 210 sends a signal 239 (event release) to the memory 206. As a rule, this is communicated to the memory 206 or 208 after successful transmission of the associated event reports 242, which also contain the stored events 236 or selected events 226 that the stored and further communicated events 236, 2 26 may be overwritten or deleted.
  • a further memory 208 is provided in the event manager 30, in particular a non-volatile memory.
  • certain events 234 that were temporarily stored in the buffer memory 206 and / or counter readings of the event counter 204 are permanently stored. To this end, the memory 208 exchanges data with the event counter 204 and / or with the buffer memory 206.
  • block 202 for prioritizing and reducing events 220 is described in more detail below with reference to FIG.
  • the mechanism described below is used to select whether additional helpful (and memory-intensive)
  • Metadata 215 are to be stored.
  • block 202 serves to select the events to be further processed as selected events 226 from the events 220, 221 supplied to the event manager 30.
  • block 304 follows, in which the respective event 220 is transmitted as a selected event 226 to the buffer 206 and is stored there. Otherwise, block 302 follows.
  • step 302 it is decided according to a specific criterion whether the event 220, 221 that has already occurred with regard to the event type 218 should nevertheless be stored. This takes place, for example, after a random selection of the event 220, 221, in particular based on a random number 273. This random selection could particularly preferably be based on a control unit-specific or vehicle-specific random number 273 To limit overflow of the buffer memory 206 in worst-case attack scenarios (long-lasting attack with so-called event bursts). On the other hand, a reasonable number of stored events 236 or selected events 226 or log entries should be obtained in normal scenarios in order to cover the largest possible spectrum over the entire attack. For this purpose, in step 303 the event 220 selected in step 302 is transmitted to the memory 206 as a selected event 226 for storage.
  • this event 220, 221 is also sent to memory 206 as a selected event 226, step 304 Memory 206 or without additional storage of further metadata 215 for event 220.
  • the monitoring of the first occurrence of event type 218 is reset when memory 206 has been read out and communicated via block 210. If an event 220, 221 was not selected or rejected, the “event rejected” state is triggered for each rejected event 220, 221.
  • a further counter 204 is particularly preferred, which records the number of unselected events 220.
  • the events 220, 221 could optionally be grouped as a function of the respective event type 218 and a separate instance for the random event reduction could be provided for each event type 218.
  • prioritization can be achieved by forming groups. This means that the event types 218 are assigned to different priority groups. Certain event types 218 (e.g. event types 218 with the ID numbers ID1, ID6, ID14, ID23 etc.) are assigned to the priority group with the highest priority (priority 1), a priority group with the next lower priority (priority 2) are assigned additional event types 218 (e.g.
  • Event types 218 with the ID numbers ID2, ID5, ID12, ID27 etc.), a priority group with the next lower priority (Prio 3) are associated further event types 218 (e.g. event types 218 with the ID numbers ID3, ID9, ID13, ID19 etc.) .) etc. assigned.
  • different numbers of events 220 are selected on average as selected events 226 on a random basis (N1: (number of selected events for priority group 1 (Prio), Nx: number selected events for priority group x (Prio_x).
  • N1 number of selected events for priority group 1 (Prio)
  • Nx number selected events for priority group x (Prio_x).
  • N1> N2 In the case of priority groups with high priority, on average more events 220 are selected on a random basis than in the case of priority groups with low priority (N1> N2).
  • Selected events 226 are stored in volatile memory 206. However, selected events 226 should not be stored immediately in the non-volatile memory 208, since too frequent storage could damage the non-volatile memory 208. The selected events 226 could be stored in the non-volatile memory 208 on a random basis, as explained in more detail in connection with FIG. 6, for example.
  • the memory (s) 206, 208 can handle selected events 226 of different sizes.
  • the memory 206 is shown here by way of example. It comprises a free memory area 250 and a filled memory area 252. Several selected events 226 and 226 are stored in the filled memory area 252. The entries 226 can each have different sizes. Due to the non-rigid division of memory areas, the memory space is optimally used. If the memory 206 is full, new selected events 226 would be discarded. In principle, however, as explained below, a complete filling of the memory 206 is prevented by a self-regulating mechanism.
  • the buffer 206 is released for overwriting or deleting the corresponding events 226 (signal 239 free event).
  • the writing of events 236, in particular in a non-volatile memory 208 such as a flash memory, could advantageously be mapped using a non-AUTOSAR storage mechanism in order to ensure storage efficiency and performance requirements.
  • the event counter 204 is described in more detail in connection with FIG. A separate counter Z1, Z2... Zn is implemented as part of the event counter 204 for each event type 218.
  • the event counter 204 always starts with the value zero. First, it is determined whether the counter reading is still less than a maximum value, query 260. If this is the case, when an event 220, 221 of a certain event type 218 occurs, the counter Z1, Z2... Zn for the respective event type 218 is incremented , Step 262. Otherwise, the count is kept at the maximum value, so there is no overflow. It is possible to reset the event counter 204 to zero upon request.
  • the counter 204 could be implemented as a 32-bit counter.
  • the non-volatile storage of the event counter 204 and / or certain selected events 226 in the non-volatile memory 208 is described.
  • the data are to be stored in the non-volatile memory 208 at regular time intervals. Such time intervals are, for example, in the seconds, minutes to hours range, for example the data is saved every 30 minutes.
  • the time for saving should be chosen randomly in order to make the writing behavior unpredictable for an attacker.
  • the storage cycles could be randomly controlled, for example in a certain interval (for example within 30 minutes, etc., but the exact time of saving within the, for example, 30 minute interval is randomly controlled).
  • the random variable for determining the storage time
  • time-controlled storage moments could be chosen randomly by multiplying a random number by a basic time interval.
  • the random number 273 itself could be updated cyclically and / or randomly.
  • the random number 273 could be assigned individually for a specific control unit or for a specific vehicle, for example in production and manufacturing.
  • a specific range of the random number 273 could be selected, on the basis of which the factor is formed as a function of the range of the random number 273.
  • the selected events 226 are stored in a non-volatile manner.
  • storage of the selected events 226 (in memory 206) and / or further information such as certain counter readings 232 of event counter 204 in non-volatile memory 208 is initiated if the control device changes its state (which could also have been caused by an attacker) a loss of the current RAM content (and thus the loss of the buffer memory 206) is due, for example, due to a requested reset or sleep mode.
  • the data should be stored in a redundant manner so that it can be recovered even if part of the data was corrupted.
  • the authenticity and integrity of the stored data should be checked or ensured after reading out from the non-volatile memory 208.
  • the non-volatile memory 208 is preferably arranged in a trustworthy zone. It is assumed that the IC internal memory is classified as trustworthy. A standard AUTOSAR NVM (Non Volatile Memory) handler could be used for this.
  • a state graph for storing selected events 226 in the non-volatile memory 208 is shown as an example.
  • a state 264 It is possible in principle to store data in the non-volatile memory 208 when this state 264 is reached.
  • a state 266 storage in the non-volatile memory 208 is not possible.
  • a change from state 264 to state 266 takes place after saving has been carried out.
  • a change back to state 264, in which saving is possible, takes place in a time-controlled manner. The time is preferably random as already described.
  • the system remains in state 266 (no saving) if the control unit is not preparing an idle state or reset.
  • FIG. 7 shows a more detailed representation of the components of the event manager 30.
  • Several events 226 are stored in the buffer memory or memory 206 and form the filled memory area 252.
  • an event no. 2 226.2
  • an event no. 4 (226.4)
  • Event No. 8 (226.8)
  • Event No. 13 (226.13)
  • Event No. 25 (226.25)
  • Event No. 38 (226.38
  • Event No. 77 (226.77
  • Event No. 97 are stored as selected events 226 in the buffer memory 206.
  • these selected events 226 were selected from a series of occurring events 220 (No. 0 to, for example, 200) using a specific procedure and stored in the buffer memory 206 as selected events 226.
  • the unfilled area or the remaining area of the buffer memory 206 forms the free memory area 250.
  • the corresponding fill level 228 of the memory occupancy shown is formed in the exemplary embodiment by the last selected event 226.97 that was stored.
  • the memory area of the buffer memory 206 is now divided into several areas 267 or fill level areas 267 between 0 and 100%. In the exemplary embodiment, these are, for example, ten (fill level) areas 267.1-267.10. In the exemplary embodiment, the areas 267 are always selected to be the same size, in the exemplary embodiment these are 10% intervals. In the exemplary embodiment, the memory 206 currently has the current area 267.4, that is to say the fourth area 267.4, which is between 30 and 40% of the complete memory occupancy.
  • the current memory area 267.4, in which the current filling level 228 of the memory 206 is located, is determined in the functional block 268.
  • the current fill level area 267, in the exemplary embodiment 267.4 for the fourth area, arrives at a block 270.
  • the offset 271 for the next event is determined.
  • the offset 271 indicates from how many events 220 the next event 226 to be stored in the memory 206 is to be selected. This number (offset 271) of events 220, from which the next event 226 to be stored is to be selected, in particular randomly, depends on the respective fill level 228 or associated memory area 267 206 is relatively low) events 20 are stored faster, so offset 271 is relatively low. With an increasing fill level 228 or storage area 267, the offset 271 increases, so fewer events 220 are stored or only one event 220 is selected from a larger number (offset 271). In this way, an overflow of the memory 206 can be delayed or prevented in a targeted manner.
  • the random-based selection of the next event 226 to be stored takes place within an offset 271. Only one event 220 (within the offset 271) is ever randomly selected or stored for each offset 271. By varying the offset size as a function of the filling level 228 of the memory 206, on average more or fewer events 220 are selected or stored on a random basis. As long as the level 228 of the memory 206 is within a certain area 227, the event manager 30 always selects an event 226 to be selected from the same associated offset 271 until the level 228 reaches the next area 227 with a changed, usually one increased offset 271.
  • the next offset 271 for the new area can be increased or decreased, for example by a certain factor or divisor.
  • FIG. 8 a corresponding scenario is shown in the table according to FIG. 8, which leads to an occupancy of the memory 206 as shown in FIG.
  • the offset 271 could be for the different filling levels 228 resp.
  • Memory areas 267 can be selected as given below by way of example.
  • the offset 271 could be to two (from zero to two, the selection is therefore made from three events 220), in the memory area between 10% and 20% (267.2) to 8 ( from zero to eight, the selection is made from nine events 220), for the memory area between 20% and 30% (267.3) 32 (from zero to 32, the selection is made from 33 events 220) and for the memory area between 30% and 40% to 128 (from zero to 128, so the selection is made from 129 events 220) etc.
  • a corresponding increase in the offset 271 for the next memory area 267 could be carried out, for example, by a corresponding factor (4) or the like. Both the memory areas 267 and the offset values 271 can be freely configured and thus adapted to the respective desired situation, such as memory size, etc.
  • next event 220 to be stored is now to be selected randomly (depending on the random number 273 as shown by way of example in FIG. 7) depending on the fill level 228 or the memory area 267. It must be ensured that the offset 271, i.e. the number of events 220 or the range of the next events to be considered 220, from which the respective event 220 to be stored is to be selected at random, from the random number 273 or a corresponding range of the random number 273 can be covered. The size of the area of the random number 273 to be considered is selected as a function of the respective offset 271. If the random number 273 is, for example, bit-coded as shown in FIG.
  • a preliminary range of the random number 273_temp with the size of two bits is selected first.
  • an offset 271 of 8 (0-8) an area x of the random number 273.
  • x_v with a size of 4 bits is selected.
  • a preliminary range of the random number 273_v with a size of 6 bits is selected.
  • an offset 271 of 128 (0-128) a preliminary range of the random number 273_v with a size of 8 bits is selected.
  • the preliminary range of the random number 273_v can be found in column 4, given there by way of example for the specific random number 273 in FIG is less than or equal to the offset 271 for the next memory area 276.
  • the provisional area 273_v is actually used as a section of the random number 273.x as a random number area.
  • the corresponding query in column 5 can be answered with "TRUE”.
  • the temporary section of the random number 273. x_v coincides with the selected section of the random number 273.x.
  • the preliminary section of the random number 273. x_v is reduced. This can be done by omitting a bit, preferably the most significant bit (MSB). For the value of the random number then resulting in this area 273.x, it can now be ensured that this value lies within the offset 271 for the next memory area 267.
  • MSB most significant bit
  • the size of the random number range 273.x (e.g. the number of bits required for the range of the random number 273), it must be taken into account whether the size (e.g. the number of bits required) is used to represent the size of the Offsets 271 of the associated memory area 267 of the next event 220 is sufficient.
  • event no.2 (220.2, global event counter 285 is 2) (after discarding the events 220.0, 220.1 No. O and No. 1) selected as selected event 226.2.
  • event no. 1 related to this offset area 271 is randomly selected for the next offset area 271 (still at 0-2).
  • Event no. 0 in this offset area 271 was discarded (would correspond to the global counter reading 285 of 3), but event number 1 in this offset area 271 was selected (corresponds to the global counter reading 285 of 4, results in the selected event 226.4).
  • the next offset range 271 is still 2 (0-2), since the fill level 267 of the buffer 206 is still in the range 267.1 between 0 and 10%.
  • the random number for 273.3 is 2, so that after events number 0 and 1 have been discarded in this offset area 271, event no. 2 is selected (global counter reading 285 at 8, selected event 226.8). Since the fill level 267 is then in the next fill level range 267.2, the new offset 271 now changes to 8 (0-8). As described above, the next 4 bits of the preliminary random number range 273.4_v are now considered.
  • Block 272 it was determined on a random basis which event 220 will be selected next as the selected event 226.
  • the corresponding block 280 now monitors the occurrence of new events 220 (block 284). For example, after the stored event 226.8 (8th event), the next event 226.13 (13th event) was stored beforehand shall be. Block 280 thus waits for event no. 13, that is to say discards the next events no. 9-12 and first saves event no. 13 as selected event 226.13 in memory 206.
  • the new filling level 228 of the memory 206 is determined as a function of the new selected event 226 with a data size of the metadata 215 (event-dependent metadata 216 and generic metadata 217). This could for example be done particularly easily using the length 232 as already contained in the metadata 215.
  • the random number 273 is to be selected differently for different control devices or vehicles 18.
  • the random number 273 could be assigned once in production for a specific vehicle or control unit.
  • the random number 273 could be regenerated internally according to certain rules. The regeneration could take place, for example, in the event of transitions from system states (when booting, resetting, transferring to a sleep mode, etc.) and / or cyclically after certain times.
  • the block 272 determines the next event hit 278 (next event hit: the next event hit 278 in the next offset 271).
  • the next event hit 278 arrives at a block 280 (throw the dice), in which, based on a random basis, the supplied event 220 is either discarded (event 220 is not stored in the buffer memory 206) or is selected as a selected event 226 for storage in the buffer memory 206.
  • Block 284 follows. Block 284 is called on each event 220. Block 284 itself, however, calls (for each event 220) block 280, which gives feedback to block 284 as to whether or not the event 220 should be selected. If event 220 was selected by block 280, then block 284 triggers the storage of event 220 in memory 206 as selected event 226.
  • Block 284 (on event) the selected event 220 is read in for subsequent storage in the free area 250 of the buffer memory 206 as a selected event 226.
  • Block 284 is always called for each new incoming event 220, 221.
  • Block 284 is used for the random selection including possible reduction and prioritization of incoming events 220, 221.
  • a random reduction of the event 220 can also take place, as already described with the ETH sensors 26, for example. In this way, a certain data area (beginning of a preferably fixed data area or end of a data area) can be selected randomly. Likewise, only certain reduced address data could be saved.
  • events 220 could select or reduce, quasi a pre-filtering analogous to the event manager 30 in order to the event manager 30 (which also includes events from other sources). If the sensor 24, 26, 28 does not forward individual events 220 to the event manager 30, this should also be communicated to the event manager 30 as a separate event type 218 (analogous to the reduction status 225 in the event manager 30). In general, however, the event-dependent selection of events 220 could take place in the sensor 24, 26, 28 itself and be stored in a buffer memory of the sensor 24, 26, 28.
  • Corresponding counters can also be provided in the sensor 24, 26, 28 for the respective event types 218, which could be transmitted to the event manager 30 if required.
  • the events 226 'selected by the sensor 24, 26, 28 could also be communicated to the event manager 30 upon request by the event manager 30 for possible forwarding to the higher-level entity 34 and / or the backend 36.
  • the procedures described in connection with the event manager 30 are random Selection and / or prioritization can nevertheless take place in the sensor 24, 26, 28. Nevertheless, they can only be limited to the special data 211 for the respective source, so the sensor 24, 26, 28 can only select sensor-specific events 220.
  • the communication adapter 32 could provide for a random, non-deterministic and disguised sending of an event report 242 to other IDS instances 34 for an attacker.
  • an event report 242 is generated from selected events 226 stored in the buffer memory 206. This includes those stored in the buffer memory 206 selected events 226. These selected events 226 are preceded by a variable 254 that is different from each event report 242 (for example random number, time or counter, etc.).
  • the event report 242 includes authentication information 256.
  • the authentication between communication adapter 32 and the unit receiving the event report 242 (IDS instance 34, backend 36 or the like) can also take place.
  • the authentication information 256 could for example be formed from at least part of the data of the event report 242, preferably from all of the data of the event report 242 (with the exception of course the authentication information 256 to be formed).
  • a corresponding algorithm is stored in the event manager 30 for this purpose.
  • a superordinate unit 34 and / or the backend 36 can be formed in the same way from the corresponding data of the received event report 242 after decryption, the associated authentication information 256 'and with the authentication information 256 actually received as in the event report 242 transmitted to be compared. If they match, authenticity is assumed.
  • the event report 242 has a fixed length 258.
  • the data 254, 215_ 1, 215_8, 215_190, 256 are still filled with so-called filler data 255.
  • This filler data 255 does not contain any event-relevant information.
  • the data shown in the event report 242 are provided with an encryption 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. Even if the size 254, which changes for each event report 242, differs by only 1 bit, for example, the subsequent encryption 258 has the effect that the encrypted event report 242 differs greatly (and not just in one bit) from the previous event report 242.
  • Certain events 220 could be cyclical and encrypted (both with a constantly changing size 254 as part of the event report 242 in plain text and with the encryption 258 of the event report 242) within the framework of the Event report 242 will be transmitted. But even if there are no new events 220, so-called dummy events (consisting, for example, of filler data 255) could be transmitted cyclically and in encrypted form. This serves to protect against eavesdropping or to conceal the data exchange between the communication adapter 32 and further IDS entities 34 or the backend 34 in a random-based manner.
  • 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 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 communication adapter 32 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).
  • 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 to say 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 if his attack is what was detected and how the anomaly detection system works.
  • the communication adapter 32 After the communication adapter 32 has received the signal 400 (timer interrupt), the communication adapter 32 requests an event report 242 from the event manager 30, signal 402.
  • the event manager 30 creates the corresponding event report 242, which includes the previously selected events 226.1 and / or 226.2 ( with respective generic metadata 217 and event-dependent metadata 216) as well as a changed size 254.
  • 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 communication adapter 32 as a signal 404. Encryption (using the changed information 254 and / or the Key 258) and authentication (formation of the authentication information 256) could take place in the event manager 30 and / or in the communication adapter 32 if the corresponding security requirements are met.
  • the communication adapter 32 could encrypt the event report 242, for example as a function of a random number 273.
  • a new random number 273 is particularly preferably always formed for the encryption, for example by hashing. This further complicates 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.
  • 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.
  • the further IDS entity 34 After receiving the message (signal 406) sent by the communication adapter 32 by the further IDS entity 34, the further IDS entity 34 sends a confirmation signal (408) to the communication adapter 32. After receiving the confirmation signal 408, the communication adapter 32 generates a request to the event manager 30, to delete or to overwrite again 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 comparison is made Authentication information 256 '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 to be authentic. Only after authentication has taken place can further data communication with the instance of the higher or lower level take place in this variant.
  • the signal 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 be implemented, for example, by a random number, a counter, a time.
  • variable variable 254 ′ of the confirmation signal 408, 416 could particularly preferably be formed by using the variable variable 254 of the event report 242 as just transmitted.
  • 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 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 event report 242 that was just sent before. If they match, an authentic confirmation signal 406, 408 is concluded.
  • the variable size 254 'in the higher-level instance 34,36 are not generated by themselves. 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
  • 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 for authentication.
  • the resulting authentication information 256 ′′ is determined from the received data (variable size 254, data 255) using an appropriately known algorithm and compared with the received authentication information 256. If they match, authenticity is assumed. If the received authentication information 256 ‘is in order, 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 sends an encrypted message, signal 414 Communication adapter 32 transmitted. As with the communication adapter 32, the message is encrypted by the further IDS instance 34, in particular by a constantly changing variable 254 'such as a random number 273. If the communication adapter 32 has not transmitted an event report 242, because, for example, no new selected event 226 occurred, In turn, a dummy message with the same data format as an event report 242 is used and transmitted in encrypted form to the backend 36 (signal 414). The backend 36 sends a confirmation signal 416 and / or a further message or request to overwrite the events 236 or the like temporarily stored in the buffer memory 206 to the further IDS entity 34.
  • the confirmation signal 416 can be formed as described above.
  • 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. 10. 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 based on the selected events 226.3, 226.4, 226.5, signal 424. After receiving the event report 242, the communication adapter 32 sends the event report encrypted and authenticated by a new variable 254 like a random number 242 to the further IDS entity 34, signal 426.
  • 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 based on the selected events 226.3, 226.4, 226.5, signal 4
  • 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 (FIG. 9).
  • 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 the selected To overwrite event 226.6, but only to overwrite 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 to the event manager 30 to send an event report 242, signal 442.
  • the event manager 30 sends an event report 242, which contains the event 226.6 selected in the meantime , Signal 444.
  • the communication adapter 32 encrypts the event report 242 using a new variable variable 256 and sends the encrypted event report 242 to the further IDS entity 34, signal 446.
  • the further IDS entity 34 Upon receipt, the further IDS entity 34 sends an acknowledgment, signal 448, at the receipt of which the communication adapter 32 sends a request to the event manager 30 to overwrite or release 450 the events 226.6 already transmitted.
  • 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.
  • 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.
  • 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 is sent, 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 the received event report 242, which has dummy content, sends it with a new, changed size 254 and sends the encrypted and authenticated event report 242 to the further IDS instance 34, signal 466 confirmed, signal 468. Upon receipt of this, the communication adapter 32 again sends a request signal to the event manager 30 to overwrite the last selected events 226, signal 470. This occurs even if 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.
  • 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. also the event summary from Communication adapter 32 encrypted by a new variable 254 like a random number and transmitted to further IDS instances 34, signal 486.
  • the further IDS instance 34 sends the event summary particularly preferably in encrypted form the backend 36 continues.
  • 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 Upon receipt of the request 492, the communication adapter 32 sends a request for an event report 242 to the event manager 30, signal 494.
  • the event manager 30 Upon receipt of the corresponding request 494, the event manager 30 sends the event report 242 to the communication adapter 32, signal 496.
  • the communication adapter 32 encrypts the event report 242, for example, a new variable 254 such as a random number and sends this to the further IDS instance 34, signal 498.
  • the further IDS instance 34 sends the event report 242 to the backend 36.
  • the receipt 36 acknowledges the backend to the further IDS instance 34, signal 492.
  • the receipt of the acknowledgment signal 492 is confirmed by the further IDS instance 34 to the communication adapter 32, signal 494.
  • the communication adapter 32 After receiving the corresponding signal 494, the communication adapter 32 sends a corresponding request to the event manager 30, at least the one in the frame the last one n event report 242 to enable or overwrite events 220 transmitted.
  • the described methods can be implemented in a processing unit, computer or controller, in particular in a control unit Vehicle 18.
  • the method can be created in the context of a computer program which is set up to carry out the method when it is carried out on a computer.
  • the computer program can be stored on a machine-readable storage medium. Nevertheless, the program can be used, for example, as a software

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (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, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht, bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und das Ereignis (220, 221) an einen Ereignismanager (30) weiterleitet, wobei der Ereignismanager (30) entscheidet, ob das Ereignis (220, 221) oder zumindest eine von dem Ereignis (220, 221) abhängige Größe in einem Speicher (208) zumindest teilweise abgespeichert wird, dadurch gekennzeichnet, dass ein Zeitpunkt des Abspeicherns des Ereignisses (220, 221) bzw. eine von dem Ereignis (220, 221) abhängige Größe zufällig ausgewählt wird.

Description

Beschreibung
Titel
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 gemäß den Merkmalen des unabhängigen Anspruchs erreicht.
Dadurch, dass ein Zeitpunkt des Abspeicherns des Ereignisses bzw. eine von dem Ereignis abhängige Größe zufällig ausgewählt wird, wird das Verhalten des Systems zur Anomalieerkennung weiter verschleiert. Die Zeitpunkte des Abspeicherns sind für den Angreifer somit nicht deterministisch. Der Angreifer kann ein lokales Persistieren nicht unterbinden, indem der Angreifer beispielsweise eine Spannungsunterbrechung durchführt. Dadurch erhöht sich die Sicherheit des Gesamtsystems. Dadurch sind die lokalen Einträge auch bei einem Spannungswechsel vorhanden, der gegebenenfalls Teil eines Angriffs ist.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Zeitpunkt des Abspeicherns innerhalb eines bestimmten Zeitintervalls zufällig ausgewählt wird. Einerseits wird ein nicht deterministisch Verhalten für den Angreifer sichergestellt. Andererseits wird jedoch zuverlässig erreicht, dass bestimmte Daten im Mittel zuverlässig abgespeichert werden. Der Mittelwert der Speicherzyklen sind konfigurierbar, sodass dieser an die Systembedingungen, Betriebsdauer etc. angepasst werden kann.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Zeitpunkt des Abspeicherns, der zufällig ausgewählt wird, von einer Zufallszahl abhängt. Dadurch wird wiederum das nicht deterministisch Verhalten realisiert.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass die Zufallszahl steuergeräteindividuell und/oder fahrzeugindividuell gewählt wird. Dadurch wird das nicht-deterministische Verhalten der Anomaliereduktion sichergestellt. Selbst im Falle der Offenlegung der Zufallszahl in einem Fahrzeug kann das erworbene Wissen nicht auf ein weiteres Fahrzeug übertragen werden. Durch die Verwendung von unterschiedlichen Zufallszahlen über die Fahrzeugflotte hinweg wird sichergestellt, dass unterschiedliche Ereignisse pro Fahrzeug selektiert werden. Dies erhöht bei einem Flottenangriff die Datenvielfalt und ermöglicht eine breitere Auswertung bzw. vollständige Rekonstruktion des Angriffs. In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Zeitpunkt des Abspeicherns bestimmt wird, indem eine Zufallszahl oder ein Bereich einer Zufallszahl mit einem Zeitintervall verknüpft wird, insbesondere durch Multiplikation. Dadurch entsteht verlässlich ein Mittelwert des Zeitintervalls. Der tatsächliche Zeitpunkt des Abspeichern ist jedoch für den Angreifer nicht deterministisch gewählt.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass die Zufallszahl zyklisch und/oder in Abhängigkeit von bestimmten Systemereignissen wie Übergang von Systemzuständen wie beispielsweise Reset, Hochfahren, Überführen in einen Ruhemodus etc. neu generiert wird. Dadurch wird bei Übergang von Systemzuständen sichergestellt, dass der aktuelle Stand des Ereignisberichts dauerhaft abgespeichert wird.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass das Abspeichern in einem nichtflüchtigen Speicher, insbesondere ein Flash-Speicher, erfolgt. Durch das Vorgehen kann sichergestellt werden, dass tendenziell der Einsatz günstiger Speichertechnologien mit stark reduzierten Schreibzyklen möglich wird.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass das Abspeichern in dem nichtflüchtigen Speicher erfolgt, indem in einem weiteren Speicher, insbesondere ein Pufferspeicher bzw. nichtflüchtiger Speicher, abgelegte Ereignisse auch in dem nichtflüchtigen Speicher abgelegt werden. Bei fehlender Konnektivität zu einer übergeordneten Einheit oder Wechsel in einen anderen Systemzustand können die Ereignisse lokal gesichert werden. Dies könnte auch durch einen dauerhaften Speicher erfolgen. Dies erfolgt besonders bevorzugt, indem ein Abspeichern eingeleitet wird, wenn ein Zustandswechsel, beispielsweise in einen Ruhemodus oder Neustart, eines Steuergeräts erfolgt.
In einer zweckmäßigen Weiterbildung ist vorgesehen, dass Daten in dem nichtflüchtigen Speicher redundant abgelegt werden, wobei bei einem Wiederherstellen von Daten überprüft wird, ob die abgespeicherten Daten authentisch bzw. integer sind. Damit wird die Sicherheit erhöht, indem lediglich integre Daten weiterverwendet werden. In einer zweckmäßigen Weiterbildung ist vorgesehen, dass der Ereignismanager dem jeweiligen erhaltenen Ereignis noch weitere Informationen zuzuordnet, insbesondere generische Metadaten wie beispielsweise Zählerstand ines Ereigniszählers und/oder ein Zeitsignal und/oder eine Länge des selektierten Ereignisses und/oder eine Anzahl nicht weiterverarbeitet Ereignisse, wobei ein Zeitpunkt des Abspeichern der weiteren Informationen zufällig ausgewählt wird. Dadurch wird eine verbesserte, tiefgehende Analyse ermöglicht. Insbesondere kann der Eintrittszeitpunkt rekonstruiert werden und in Relation zu anderen Ereignissen gesetzt werden. Insbesondere über einen Zählerstand kann die Relation der einzelnen Ereignisse zueinander festgestellt werden. Über die Zählerstände lassen sich einfache Aussagen darüber treffen, ob bestimmte Ereignisse mit zugehörigen Metadaten verloren wurden bzw. nicht abgespeichert wurden. Über die Länge kann der Füllstand des Puffers rekonstruiert werden, ohne dass dieser dynamisch explizit ausgelesen werden muss.
Weitere vorteilhafte Ausgestaltungen ergeben sich aus weiteren abhängigen Ansprüchen sowie der folgenden Beschreibung und der Zeichnung. In der Zeichnung zeigt
Figur 1 schematisch Komponenten einer Anomalieerkennung,
Figur 2 einen beispielhaften Aufbau bzw. Wechselwirkung von empfangenen Daten, daraus abgeleitetem Ereignis, Aufbau des zugehörigen selektierten Ereignisses sowie einen Ereignisbericht,
Figur 3 einen genaueren Aufbau eines Ereignismanagers,
Figur 4 ein Flussdiagramm zur Auswahl eines weiterzuverarbeitenden
Ereignisses,
Figur 5 ein Flussdiagramm für die Zählerinkrementierung,
Figur 6 ein Flussdiagramm für das Abspeichern eines nichtflüchtigen
Speichers, Figur 7 eine schematische Übersicht für die zufällige Auswahl eines abzuspeichernden Ereignisses,
Figur 8 die Zuordnung bestimmter in Figur 7 verwendeter Größen,
Figuren 9-14 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 ü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. Oftmals werden die jeweiligen Ereignisarten 218 mit ereignisspezifischen Event-ID bzw. Ereignis-ID versehen. Es besteht eine Vielzahl von vordefinierten Ereignisarten 218 für unterschiedlichste Datenquellen mit zugehörigen eindeutigen Ereignis-ID's.
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 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.
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.
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ähler204 (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.
IDS Sensoren 24, 26, 28 leiten die Ereignisse 220 bzw. reduzierte Ereignisse 221 an den Ereignismanager 30 weiter. Gerade bei Ethernet-Netzwerken kann bei einem Angriffsversuch ein Speicher 206, insbesondere ein flüchtiger Speicher bzw. Pufferspeicher 206, sehr schnell bei einer Vielzahl von weiterzuleitenden Ereignissen 220 mit großen Datenmengen bzw. ereignisabhängigen Metadaten 216 nicht mehr sämtliche Ereignisse 220 aufnehmen. Dies kommt von der hohen Datenübertragungsrate bzw. hohen Datenmengen, die übertragen werden können. Daher kann es Sinn machen, dass ein oder mehrere IDS-Sensoren 24, 26, 28 bereits eine Vorauswahl der weiterzuleitenden Ereignisse 220 und/oder eine Datenreduktion (reduzierte Ereignisse 221) nach bestimmten Kriterien treffen. Diese Kriterien sollen sich durch geringe Vorhersagbarkeit auszeichnen.
Bei den IDS Sensoren 24,26, 28, insbesondere bei den IDS Ethernet Sensoren 26, erfolgt bevorzugt zur Erhöhung der Sicherheit die Auswahl bestimmter weiterzuleitender Ereignisse 220 und/oder die Reduzierung der Ereignisse zu reduzierten Ereignissen 221 zufallsgesteuert. Eine zufällige bzw. willkürliche Auswahl bzw. Reduzierung von bestimmten Ereignissen 220 bzw. Datenblöcken eines Ethernet-Frames erfolgt für einen Angreifer nicht deterministisch und verschleiert. Die zufallsgesteuerte Auswahl bzw. Reduzierung könnte beispielsweise auf einer für ein bestimmtes Steuergerät individuellen Zufallszahl 273 basieren. Die gleiche Zufallszahl 273 könnte im einfachsten Fall auch für die anderen zufallsbasierten Szenarien als Referenz im Ereignismanager 30 für die Reduktion bzw. Priorisierung aller Ereignisse 220, dem zufallsabhängigen Abspeichern von Ereignissen 220 oder Ähnliches verwendet werden. Alternativ könnten auch entsprechende Zufallszahlen wieder im Steuergerät neu generiert werden.
Eingehende Nachrichten bzw. Daten 211 weisen üblicher weise entsprechende Header-Informationen 214 (beispielsweise bestimmte Adressdaten) und nachfolgende Nutzdaten 213 auf. Üblicherweise sind viele Header-Informationen enthalten, die nicht unbedingt für die Anomalieauswertung notwendig sind. Erfindungsgemäß werden lediglich bestimmte Adressanteile, die unbedingt nötig sind, als Bestandteil eines reduzierten Ereignisses 221 im Rahmen der ereignisabhängigen Metadaten 216 weitergeleitet wie beispielsweise die Adresse der Quelle (beispielsweise MAC Adresse, z.B. 48 Bit), die Adresse des Ziels (beispielsweise MAC Adresse, z.B. 48 Bit) sowie die ID-Nummer, die zu einer Anomalie geführt hat (Ereignisart 218). Andere Informationen wie beispielsweise eventuell der physikalische Port bzw. Port-ID, wo das Frame empfangen wurde, IP-Adresse von Quelle oder Ziel, Angaben zum UDP/TCP-Port der Quelle oder des Ziels, falls solche Informationen im Frame enthalten sind, müssen nicht oder nicht vollständig im Ereignis 220 übertragen werden.
Der weiterzuleitende bzw. ausgewählte Nutzdatenbereich 219 jedoch wird zufallsbasiert ausgewählt aus den Nutzdaten 213 der eingehenden Daten 211 wie auch schon in Verbindung mit den Figuren 2a und 2b erläutert. So könnte beispielsweise die Nummer des Anfangs-Datums (Anfang des zu übertragenden Speicherbereichs der Nutzdaten, beispielsweise Byte Nr. xyz) zufallsbasiert festgelegt werden (übertrage beispielsweise einen Datenbereich, dessen Anfangswert zufällig ermittelt wurde, beispielsweise für dieses Ereignis 220 Nutzdaten-Byte Nr. 538. Der Offset des ausgewählten Nutzdatenbereiches 219 (Anzahl der übermittelten Daten, beispielsweise 10 Bytes) könnte fest gewählt sein. Somit würden die Nutzdaten- Bytes mit den Nummern 538-547 neben den Minimal-Adressinformationen (Quelladresse, Zieladresse) als ausgewählter Nutzdatenbereich 219 im Rahmen des so reduziertes Ereignis 221 an den Ereignismanager 30 weitergeleitet. Alternativ könnte auch der Offset des ausgewählten Nutzdatenbereichs 219 (Anzahl der übermittelten Nutzdaten) variiert werden, vorzugsweise zufallsabhängig. Bevorzugt hängt der ausgewählte Nutzdatenbereich 219, insbesondere der Anfangs- oder Endbereich ausgewählten Nutzdatenbereichs 219 ab von einer Zufallszahl 273. Besonders bevorzugt ist diese Zufallszahl 273 abhängig von dem Steuergerät bzw. dem Gateway 20. Besonders bevorzugt ist die Zufallszahl 273 eindeutig, also nur für dieses spezielle Steuergerät einmalig vergeben.
Optional kann die Zufallszahl 273 aber auch erneuert werden. Dadurch ergeben sich nachfolgende Vorteile. Durch die Erneuerung der Zufallszahl werden bei der gleichen Angriffs-Sequenz (Sequenz von Ereignissen 220) unterschiedliche Ereignisse 220 geloggt bzw. selektiert. Dies ist auch der Fall, wenn der Angriff nur auf ein einzelnes Steuergerät/Fahrzeug 18 und nicht auf die gesamte Flotte erfolgt. Folgende Annahme/ Beispiel:
1. Mehrfache Wiederholung derselben Angriffs-Sequenz (Sequenz von Ereignissen 220)
2. Zwischen Angriffs-Sequenzen werden Zufallszahlen 273 erneuert
3. Im Rahmen einer Angriffs-Sequenz können nicht alle Ereignisse 220 geloggt bzw. selektiert werden werden (Ereignis Burst). Es folgt eine Ereignis- Reduktion für den Ereignisbericht 242
4. Ein Ereignisbericht 242 mit reduzierten Ereignissen 221 wird an die übergeordnete Instanz 34, 36 vollständig zwischen zwei Angriffs-Sequenzen weitergeleitet. Hierdurch kann nach mehrmaliger Wiederholung der gleichen Angriffs-Sequenz die komplette Angriffs-Sequenz über die Ereignisberichte 242 rekonstruiert werden.
Der Sensor 26 könnte vorzugsweise die Wahl der Zufallszahl 273 bzw. die verschiedenen Bereiche der Zufallszahl 273 anpassen an die Größe der eingehenden Daten 211 , insbesondere an die Größe der eingehenden Nutzdaten 213. Weisen die Nutzdaten 213 einen kleineren Datenbereich auf, so muss die Zufallszahl 273 so gewählt werden, dass die Auswahl eines bestimmten reduzierten Nutzdatenbereiches 219 auch nur in diesen kleinen Datenbereich der Nutzdaten 213 fällt. Die Zufallszahl 273 bzw. der betrachtete Bereich der Zufallszahl 273 muss also entsprechend klein sein. Weisen die eingehenden Nutzdaten 213 jedoch einen sehr großen Datenbereich auf, so muss die Zufallszahl 273 bzw. der betrachtete Bereich der Zufallszahl 273 so groß gewählt werden, dass die Auswahl eines bestimmten reduzierten Nutzdatenbereichs 219 auch diesen großen Datenbereich der Nutzdaten 213 abdecken kann. Die Zufallszahl 273 fällt also entsprechend größer aus.
Indem die Zufallszahl 273 eindeutig für ein jeweiliges Steuergerät 20 vergeben wurde, könnte bei Vorliegen weiterer Steuergeräte eventuell die komplette Nachricht (die auch an die weiteren Steuergeräte ging und mit dort entsprechend ausgestatteten Sensoren 26 ebenfalls entsprechend detektiert und reduziert weitergeleitet wurde) mit dem kompletten Datenbereich bei einer Analyse im Backend 36 durch das Zusammenführen vieler reduzierter Ereignisse 221 mehrerer Steuergeräte zusammengesetzt werden. Denn andere Steuergeräte mit derselben Sensorfunktion wie beschrieben wählen nun zufällig auch andere Nutzdatenbereiche 219 (mit anderen zufällig ausgewählten Start-oder Endadressen) aus, die nach dem Zusammenführen mehrerer reduzierter Ereignisse 221 einen großen Teil des (Nutz)Datenbereichs 213 oder den kompletten Datenbereich der Nutzdaten 213 anhand der Teilbereiche bzw. ausgewählter Nutzdatenbereiche 219 der verschiedenen Steuergeräte abdecken können. So könnten von verschiedenen Steuergeräten aus den reduzierten Ereignissen 221 bzw. ausgewählten Nutzdatenbereichs 219 ein Ereignis 220 rekonstruiert werden, indem beispielsweise Teil-Datenbereich 538-547 (des einen ausgewählten Nutzdatenbereichs 219) von dem einen Steuergerät, Teil- Datenbereich 548-557 (eines weiteren ausgewählten Nutzdatenbereichs 219) von einem weiteren Steuergerät, Teil-Datenbereich 558-567 (eines weiteren ausgewählten Nutzdatenbereichs 219) von einem weiteren Steuergerät zur Verfügung gestellt und die jeweiligen ausgewählten Nutzdatenbereiche 219 beispielsweise in einem übergeordneten Steuergerät oder im Backend 36 wieder zum kompletten (Nutz)Datenbereich 213 zusammengesetzt werden. Dies ist insbesondere bei einem sogenannten Broadcast-Angriff auf die gesamte Fahrzeugflotte oder einem sogenannten Multicast-Angriff auf Teile der Fahrzeugflotte der Fall.
Die zufällige Ermittlung des Beginns und/oder das Endes des weitergeleiteten bzw. ausgewählten Nutzdatenbereichs 219 wird vorzugsweise nach bestimmten Ereignissen (zyklisch, Hochfahren des Steuergeräts, Reset eines Steuergeräts etc.) neu durchgeführt. Hierzu könnte beispielsweise die Zufallszahl 273 neu erzeugt werden. Alternativ könnte ein anderer Bereich der Zufallszahl 273 für die Generierung des Beginns und/oder Endes des weiterzuleitenden Datenbereichs bzw. ausgewählten Nutzdatenbereichs 219 herangezogen werden.
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. Prinzipiell könnten jedoch auch dort die Daten wie entsprechend beschrieben reduziert werden.
Prinzipiell laufen somit folgende Schritte zur Reduzierung der Ereignisse 220 im Sensor 24, 26, 28 ab. Daten 211 werden von dem Sensor 24, 26, 28 empfangen und/oder Daten 211 werden ausgewertet, ob eine Anomalie vorliegt. Bei Vorliegen einer Anomalie werden die Daten 211 reduziert. Die Reduktion erfolgt durch Reduzierung des Adressbereichs bzw. Header 214 und/oder des Datenbereichs bzw Nutzdaten 213. Die Reduzierung des Adressbereichs 214 könnte erfolgen durch Auswahl der Zieladresse und/oder der Quellenadresse.
Die Reduzierung der Nutzdaten 213 erfolgt zufallsabhängig. Die Reduzierung der Nutzdaten 213 erfolgt zufallsabhängig durch zufällige Auswahl eines Startwerts und/oder eines Endwerts eines Teil-Bereichs der Nutzdaten 213. Der Offset des Datenbereichs (Anzahl der übermittelten Daten) ist auf einen bestimmten Wert festgelegt. Die reduzierten Ereignisse 221 werden an den Ereignismanager 30 übermittelt. Die reduzierten Ereignisse 221 beinhalten reduzierte Adressdaten und/oder reduzierte bzw. ausgewählte Nutzdaten 219. Eine Aktualisierung der Zufallszahl 273 erfolgt in Abhängigkeit von bestimmten Systemzuständen (zyklisch, Hochfahren, Reset etc.). Alternativ könnte eine Aktualisierung der Zufallszahl 273 zufällig und/oder zeitgesteuert erfolgen. Die Zufallszahl 273 bzw. Bereiche der Zufallszahl 273 zur Bestimmung des Start-oder Endbereichs des ausgewählten Nutzdatenbereich 219 kann abhängen von der Größe des Nutzbereichs 213 der empfangenen Daten 211.
Gemäß Figur 3 ist der Aufbau des Ereignismanagers 30 genauer gezeigt. Der Ereignismanager 30 weist mehrere funktionale Blöcke auf, die in Wechselwirkung zueinander stehen. Jedes der von den Sensoren 24, 26, 28 detektierten Ereignisse 220 bzw. reduzierten Ereignisse 221 gelangen an einen Block 202. Block 202 dient der Auswahl der eingehenden Ereignisse 220, bzw. reduzierten Ereignisse 221, die weiterverarbeitet werden sollen. Insbesondere dient Block 202 der Priorisierung und Reduzierung von Ereignissen 220, 221.
Jedes Ereignis 220 bzw. jedes reduzierte Ereignis 221 gelangt ebenfalls an einen Block 204, der als Zähler 204 für Ereignisse 220, 221 dient. Bei einem auftretenden Ereignis 220, 221 wird ein entsprechender Zähler inkrementiert, insbesondere ein globaler Ereigniszähler 205. Besonders bevorzugt weist der Zähler 204 unterschiedliche Zähler Z1, Z2,...Zn auf für unterschiedliche Ereignisarten 218 (ID1, ID2, ... IDn) wie oben in Verbindung mit den entsprechenden Sensoren 24, 26, 28 näher ausgeführt. Der globale Ereigniszähler 205 wiederum stellt die Summe sämtlicher Zählerstände der Zähler Z1, Z2,...Zn für unterschiedliche Ereignisarten 218 (ID1, ID2, ... IDn) dar. Das Ausgangssignal 231 des Blocks 204 bzw. Zählers beinhaltet die Zählerstände sämtlicher Ereignisse 220,221, also Zählerstände der jeweiligen ereignisabhängigen Zähler Z1, Z2,... Zn sowie des globalen Ereigniszählers 205. Das entsprechende Ausgangssignal 231 von Block 204 wird einem Block 210 zur Kommunikation der Ereignisse 220 zugeführt. Block 204 ist eingerichtet zum Empfang eines Rücksetzsignals 222, welches eine Rücksetzungsanforderung an den bzw. die Zähler bzw. Ereigniszähler 204, 205 darstellt. Block 204 erhält von Block 202 ein Signal für einen Reduktionsstatus 225, beispielsweise „Ereignisreduktion aktiv“. In Block 202 ist beispielsweise dann eine Ereignisreduktion aktiv, wenn nur eine reduzierte Anzahl bestimmter Ereignisse 220, 221 als selektierte Ereignisse 226 weiterverarbeitet werden. Dies ist insbesondere dann der Fall, wenn beispielsweise im Rahmen eines sogenannten Ereignis-Bursts eine hohe Anzahl von Ereignissen 220, 221 eingehen mit einem erhöhten Füllstand 228 des Pufferspeichers 206. In diesem Fall soll ein zusätzliches Ereignis 220 generiert werden, beispielsweise mit einer Ereignisart 218 „Ereignisreduktion aktiv“ wie oben beschrieben. Für dieses Ereignis 220‘ mit zugehöriger Ereignisart 218 gibt es dann ebenfalls einen entsprechenden Zähler bzw. Zählerstand.
Die von Block 202 bearbeiteten Ereignisse gelangen als selektierte Ereignisse 226 an einen Block 206, der als Speicher bzw. Pufferspeicher für die von Block 202 zugeführten selektierte Ereignisse 226 dient und die entsprechende Logik hierzu umfasst. Im Gegenzug meldet der Speicher 206 den Füllstand bzw. die Speicherbelegung 228 zurück an den Block 202. Bei dem Speicher 206 handelt es sich vorzugsweise um einen flüchtigen Speicher, insbesondere um einen Pufferspeicher eines RAM. Außerdem gelangt das Zeitsignal 224, insbesondere ein globales Zeitsignal 224, an den Speicher 206 bzw. an den Block zum Puffern der selektierten Ereignisse 226. Der Speicher 206 ist ein Bestandteil des Ereignismanagers 30.
Bestimmte in dem Speicher 206 abgespeicherte bzw. gepufferte Ereignisse 236 gelangen an einen Block 210, der der Kommunikation von Ereignisberichten 242 in Abhängigkeit von den selektierten Ereignissen 226 bzw. abgespeicherten Ereignissen 236 dient. Der Block 210 zur Kommunikation von Ereignissen erhält darüber hinaus Ausgangssignale 231 des Ereigniszählers 204, beispielsweise Zählerstände der Zähler Z1, Z2 ... Zn für die jeweiligen Ereignisarten 218 und/oder den Zählerstand des globalen Ereigniszählers 205. Der Block 210 zur Kommunikation von Ereignissen, insbesondere von Ereignisberichten 242, tauscht Signale 244 mit einem Kryptographiemodul 212 aus. Das Kryptografiemodul führt Kryptographieoperationen wie beispielsweise Verschlüsselungsoperationen, Authentisierungs- und Authentifizierungs- Operationen sowie Zufallszahlen-Generierung etc. durch. Mithilfe des Kryptographiemoduls 212 kann eine verschlüsselte Kommunikation des Blocks 210 nach außen erfolgen. Das Kryptografiemodul 212 führt insbesondere eine Verschlüsselung des Ereignisberichts 242 unter Verwendung der in Figur 2d angedeuteten Verschlüsselung 257 durch. Ebenfalls kann das Kryptografiemodul 212 eine Authentifizierung des Ereignisberichts 242 unter Verwendung der Authentifizierungsinformation 256 durchführen, vergleiche ebenfalls Figur 2d. Block 210 kann in dem Kommunikationsadapter 32 und/oder im Ereignismanager 30 angesiedelt sein. Der Block 210 gibt entsprechende Ereignisberichte 242 aus. Block 210 empfängt einen Anforderungsbefehl 240, entsprechende im Speicher 206, 208 abgespeicherte Ereignisse 236 auszulesen. Der Anforderungsbefehl 240 kann zyklisch erfolgen und/oder auf explizite Anforderung hin. Außerdem sendet der Block 210 ein Signal 239 (Ereignisfreigabe) an den Speicher 206. Damit wird in der Regel nach einer erfolgreichen Übertragung der zugehörigen Ereignisberichte 242, die auch die gespeicherten Ereignisse 236 bzw. selektierten Ereignisse 226 beinhalten, dem Speicher 206 bzw. 208 mitgeteilt, dass die abgespeicherten und weiterkommunizierten Ereignisse 236, 2 26 überschrieben bzw. gelöscht werden dürfen.
Außerdem ist in dem Ereignismanager 30 ein weiterer Speicher 208 vorgesehen, insbesondere ein nichtflüchtiger Speicher. In dem weiteren insbesondere nichtflüchtigen Speicher 208 werden bestimmte Ereignisse 234, die in dem Pufferspeicher 206 zwischengespeichert wurden, und/oder Zählerstände des Ereigniszählers 204 dauerhaft abspeichert. Hierzu tauscht der Speicher 208 Daten aus mit dem Ereigniszähler 204 und/oder mit dem Pufferspeicher 206.
Anhand Figur 4 nachfolgend wird die Arbeitsweise des Blocks 202 zur Priorisierung und Reduzierung von Ereignissen 220 genauer beschrieben. Der nachfolgend beschriebene Mechanismus wird verwendet, um zu selektieren, ob für ein Ereignis 220, 221 ergänzende hilfreiche (und speicherintensive)
Metadaten 215 abgespeichert werden sollen. Weiter verallgemeinernd dient Block 202 dazu, aus den dem Ereignismanager 30 zugeführten Ereignissen 220,221 die weiterzuverarbeitenden Ereignisse als selektierte Ereignisse 226 auszuwählen. Für jede Ereignisart 218 des erhaltenen Ereignisses 220, 221 wird nachverfolgt, ob es sich um das erstmalige Auftreten dieser bestimmten Ereignisart 218 handelt oder ob ein Ereignis 220 mit dieser Ereignisart 218 bereits an den Speicher bzw. Puffer 206 gesendet wurde; Abfrage 301. Beim erstmaligen Auftreten einer Ereignisart 218 schließt sich Block 304 an, in dem das jeweilige Ereignis 220 als selektiertes Ereignis 226 an den Puffer 206 übertragen und dort abgespeichert wird. Andernfalls schließt sich Block 302 an.
In diesem Schritt 302 wird nach einem bestimmten Kriterium entschieden, ob das hinsichtlich der Ereignisart 218 bereits aufgetretene Ereignis 220, 221 trotzdem abgespeichert werden soll. Dies erfolgt beispielsweise nach einer zufälligen Auswahl des Ereignisses 220, 221, insbesondere basierend auf einer Zufallszahl 273. Diese zufällige Auswahl könnte besonders bevorzugt basieren auf einer steuergerätespezifischen oder fahrzeugspezifischen Zufallszahl 273. Für die zufällige Auswahl soll ein intelligenter Algorithmus verwendet werden, um das Überlaufen des Pufferspeichers 206 bei Worst-Case-Angriffsszenarien (lang anhaltender Angriff mit sog. Ereignis-Bursts) zu begrenzen. Andererseits soll eine vernünftige Anzahl von gespeicherten Ereignissen 236 bzw. selektierten Ereignissen 226 bzw. Log-Einträgen in normalen Szenarios erhalten werden, um ein möglichst großes Spektrum über den kompletten Angriff zu erfassen. Hierzu wird in Schritt 303 das in Schritt 302 ausgewählte Ereignis 220 an den Speicher 206 als selektiertes Ereignis 226 zum Abspeichern übermittelt.
Sofern nun also nach zufälligen Kriterien gemäß Schritt 302 das Ereignis ausgewählt wurde, Abfrage 303, so wird auch dieses Ereignis 220, 221 als selektiertes Ereignis 226 an den Speicher 206 geschickt, Schritt 304. Andernfalls endet der Programmablauf ohne Abspeichern dieses Ereignisses 220, 221 im Speicher 206 bzw. ohne ergänzendes Abspeichern weiterer Metadaten 215 zum Ereignis 220. Das Überwachen des erstmaligen Auftretens der Ereignisart 218 wird zurückgesetzt, wenn der Speicher 206 ausgelesen und über Block 210 kommuniziert wurde. Falls ein Ereignis 220, 221 nicht ausgewählt bzw. verworfen wurde, so wird der Zustand “Ereignis zurückgewiesen“ getriggert für jedes verworfene Ereignis 220, 221. besonders bevorzugt ist hierzu ein weiterer Zähler 204 vorzusehen, der die Anzahl der nicht selektierten Ereignisse 220 erfasst.
Für eine zusätzliche Priorisierung könnten die Ereignisse 220, 221 optional in Abhängigkeit von der jeweiligen Ereignisart 218 gruppiert und eine eigene Instanz für die zufällige Ereignisreduktion für jede Ereignisart 218 vorgesehen werden. Eine Priorisierung kann ergänzend erreicht werden durch Gruppenbildung. Dies bedeutet, dass die Ereignisarten 218 unterschiedlichen Prioritätsgruppen zugeordnet werden. Der Prioritätsgruppe mit höchster Priorität (Prio 1) werden bestimmte Ereignisarten 218 (beispielsweise Ereignisarten 218 mit den ID-Nummern ID1, ID6, ID14, ID23 etc.), einer Prioritätsgruppe mit nächst niedrigerer Priorität (Prio 2) werden zugehörige weitere Ereignisarten 218 (beispielsweise Ereignisarten 218 mit den ID-Nummern ID2, ID5, ID12, ID27 etc.), einer Prioritätsgruppen mit nächst niedrigerer Priorität (Prio 3) werden zugehörige weitere Ereignisarten 218 (beispielsweise Ereignisarten 218 mit den ID-Nummern ID3, ID9, ID13, ID19 etc.) usw. zugeordnet. Für unterschiedliche Prioritätsgruppen (Priol, Prio2, Prio3, ...) werden zufallsbasiert unterschiedlich viele Ereignisse 220 im Mittel als selektierte Ereignisse 226 ausgewählt (N1: (Anzahl selektierter Ereignisse für Prioritätsgruppe 1 (Priol), Nx: Anzahl selektierter Ereignisse für Prioritätsgruppe x (Prio_x). Bei Prioritätsgruppen mit hoher Priorität werden zufallsbasiert im Mittel mehr Ereignisse 220 selektiert als bei Prioritätsgruppen mit niedriger Priorität (N1>N2...). Dies könnte beispielsweise dadurch erreicht werden, dass die Bereiche B1, B2.. Bx (mit den zugehörigen Prioritätsgruppen Priol, Prio2... Prio_x) bzw. Anzahl, aus denen ein Ereignis 220 selektiert wird, je kleiner gewählt werden, desto höher die Priorität ist (B1<B2...).
Selektierte Ereignisse 226 werden im flüchtigen Speicher 206 abgespeichert. Selektierte Ereignisse 226 sollen jedoch nicht unmittelbar in dem nichtflüchtigen Speicher 208 abgespeichert werden, da ein zu häufiges Speichern den nichtflüchtigen Speicher 208 beschädigen könnte. Ein Abspeichern der selektierten Ereignisse 226 im nichtflüchtigen Speicher 208 könnte zufallsbasiert erfolgen wie beispielsweise in Verbindung mit Figur 6 näher erläutert.
Der bzw. die Speicher 206, 208 können selektierte Ereignisse 226 mit unterschiedlicher Größe behandeln. In der Figur 7 ist hier beispielhaft der Speicher 206 gezeigt. Er umfasst einen freien Speicherbereich 250 sowie einen gefüllten Speicherbereich 252. In dem gefüllten Speicherbereich 252 sind mehrere selektierte Ereignisse 226 bzw. 226 hinterlegt. Die Einträge 226 können jeweils unterschiedliche Größen aufweisen. Durch die nicht starre Einteilung von Speicherbereichen wird der Speicherplatz optimal ausgenutzt. Falls der Speicher 206 voll ist, würden neue selektierte Ereignisse 226 verworfen. Prinzipiell wird jedoch wie nachfolgend ausgeführt ein vollständiges Füllen des Speichers 206 durch einen selbstregelnden Mechanismus unterbunden. So werden bei einem sehr hohen Füllstand 228 des Speichers 206 zufallsbasiert im Mittel viel weniger Ereignisse 220 selektiert als bei einem niedrigen Füllstand 228 des Speichers 206. Sofern dennoch selektierte Ereignisse 226 verworfen werden aufgrund eines vollen Puffers 206, dann wird ein Ereigniszähler für eine neue Ereignisart 218 „Logging Buffer Overflow (Overflow des Speichers 206)“ implementiert, um die Anzahl der verworfenen Ereignisse bzw. Einträge zu ermitteln. Dies kann wie in Figur 3 gezeigt beispielsweise dadurch erfolgen, dass der Status 230 des Speichers 206 dem Zähler 204 mitgeteilt wird bzw. dieses Signal 230 immer dann einen Impuls an den Zähler 204 sendet, wenn wieder ein weiteres selektiertes Ereignis 226 aufgrund vollen Speichers 206 nicht abgespeichert werden kann. Sobald alle gespeicherten Ereignisse 236 bzw. selektierten Ereignisse 226 erfolgreich über Block 210 im Rahmen eines Ereignisberichts 242 beispielsweise zu einem externen Datenlogger in dem Steuergerät berichtet wurden, wird der Puffer 206 zum Überschreiben oder Löschen der entsprechenden Ereignisse 226 freigegeben (Signal 239 free event). Das Schreiben von Ereignissen 236 insbesondere in einen nichtflüchtigen Speicher 208 wie einen Flash Speicher könnte vorteilhaft über einen Nicht-AUTOSAR Speichermechanismus abgebildet werden, um Speichereffizienz und Performanceanforderungen sicherzustellen.
Es besteht aber auch die Möglichkeit, einen Standard-AUTOSAR Speichermechanismus zu nutzen.
In Verbindung mit Figur 5 wird der Ereigniszähler 204 näher beschrieben. Für jede Ereignisart 218 wird ein eigener Zähler Z1, Z2...Zn im Rahmen des Ereigniszählers 204 implementiert. Der Ereigniszähler 204 startet jeweils mit dem Wert Null. Zunächst wird ermittelt, ob der Zählerstand noch kleiner als ein Maximalwert ist, Abfrage 260. Sofern dies der Fall ist, wird bei Auftreten eines Ereignisses 220, 221 einer bestimmten Ereignisart 218 der Zähler Z1, Z2...Zn für die jeweilige Ereignisart 218 inkrementiert, Schritt 262. Andernfalls wird der Zählerstand auf dem Maximalwert gehalten, es kommt also zu keinem Overflow. Es ist möglich, den Ereigniszähler 204 auf Anfrage zurückzusetzen auf Null. Der Zähler 204 könnte beispielsweise als 32-Bit-Zähler implementiert werden.
Gemäß Figur 6 wird das nichtflüchtige Abspeichern des Ereigniszählers 204 und/oder bestimmter selektierter Ereignisse 226 in dem nichtflüchtigen Speicher 208 beschrieben. Die Daten sollen in den nichtflüchtigen Speicher 208 in regelmäßigen Zeitabständen abgespeichert werden. Solche Zeitabstände liegen beispielsweise im Sekunden-, Minuten- bis Stundenbereich, beispielsweise erfolgt ein Speichern der Daten jede 30 Minuten. Der Zeitpunkt für das Abspeichern soll zufallsabhängig gewählt werden, um das Schreibverhalten für einen Angreifer unvorhersehbar zu machen. Die Speicherzyklen könnten zufallsgesteuert beispielsweise in einem bestimmten Intervall (beispielsweise innerhalb von 30 Minuten etc., der genaue Zeitpunkt des Abspeicherns innerhalb des bspw. 30 Minuten-Intervalls ist jedoch zufallsgesteuert) erfolgen. Wiederum könnte die Zufallsgröße (für die Bestimmung des Speicherzeitpunkts) in Abhängigkeit von einer steuergeräteindividuellen oder fahrzeugindividuellen Zufallszahl 273 erzeugt bzw. gewählt werden.
Alternativ könnten zeitgesteuerte Speichermomente zufallsabhängig gewählt werden, indem eine Zufallszahl multipliziert wird mit einem Grund-Zeitintervall.
So handelt es sich beispielsweise um ein bestimmtes Grund-Zeitintervall von 15 Sekunden, welches multipliziert wird mit einer beispielsweise 3 Bit-Zufallszahl bzw. Zufallszahlsbereich einer Zufallszahl 273. Die Zufallszahl 273 selbst könnte zyklisch und/oder zufällig aktualisiert werden. Alternativ könnte die Zufallszahl 273 steuergerätespezifisch bzw. fahrzeugspezifisch individuell vergeben werden beispielsweise in der Produktion und Fertigung. Alternativ könnte ein bestimmter Bereich der Zufallszahl 273 ausgewählt werden, auf dessen Basis der Faktor in Abhängigkeit von dem Bereich der Zufallszahl 273 gebildet wird.
Sobald ein neues selektiertes Ereignis 226 auftritt und ein Abspeichern im nichtflüchtigen Speicher 208 möglich ist, werden die selektierten Ereignisse 226 nichtflüchtig abgespeichert. Darüber hinaus wird ein Abspeichern der selektierten Ereignisse 226 (im Speicher 206) und/oder weitere Informationen wie bestimmte Zählerstände 232 des Ereigniszählers 204 in dem nichtflüchtigen Speicher 208 eingeleitet, wenn ein Zustandswechsel (der auch durch einen Angreifer hervorgerufen worden sein könnte) des Steuergeräts zu einem Verlust des gegenwärtigen RAM-Inhalts (und damit dem Verlust des Pufferspeichers 206) beispielsweise durch einen angeforderten Reset oder Ruhemodus ansteht.
Die Daten sollen in redundanter Art und Weise gespeichert werden, um ein Wiederherstellen möglich zu machen, selbst dann, wenn ein Teil der Daten korrumpiert war. Die Authentizität und Integrität der gespeicherten Daten soll überprüft bzw. sichergestellt werden nach dem Auslesen aus dem nichtflüchtigen Speicher 208. Bevorzugt ist der nichtflüchtige Speicher 208 in einer vertrauenswürdigen Zone angeordnet. Es wird dabei davon ausgegangen, dass der IC-interne Speicher als vertrauenswürdig (Trusted) eingestuft wird. Ein Standard-AUTOSAR NVM (Non Volatile Memory)-Handler könnte hierfür eingesetzt werden.
In Figur 5 ist beispielhaft ein Zustandsgraph zum Abspeichern von selektierten Ereignissen 226 im nichtflüchtigen Speicher 208 gezeigt. In einem Zustand 264 ist das Abspeichern von Daten im nichtflüchtigen Speicher 208 grundsätzlich möglich, wenn dieser Zustand 264 erreicht wird. In einem Zustand 266 ist ein Abspeichern im nichtflüchtigen Speicher 208 nicht möglich. Ein Wechsel vom Zustand 264 in den Zustand 266 erfolgt nach durchgeführtem Abspeichern. Ein Wechsel zurück in den Zustand 264, in dem ein Speichern möglich ist, erfolgt Zeit-gesteuert. Vorzugsweise ist die Zeit zufallsabhängig wie bereits beschrieben. Das System verbleibt im Zustand 266 (kein Abspeichern), wenn das Steuergerät nicht einen Ruhezustand oder Reset vorbereitet.
Figur 7 zeigt eine genauere Darstellung der Komponenten des Ereignismanagers 30. In dem Pufferspeicher bzw. Speicher 206 sind mehrere Ereignisse 226 abgespeichert und bilden den gefüllten Speicherbereich 252. Beispielhaft wurden ein Ereignis Nr. 2 (226.2), ein Ereignis Nr. 4 (226.4), ein Ereignis Nr. 8 (226.8), ein Ereignis Nr. 13 (226.13), ein Ereignis Nr. 25 (226.25), ein Ereignis Nr. 38 (226.38), ein Ereignis Nr, 77 (226.77) sowie ein Ereignis Nr. 97 (226.97) als selektierte Ereignisse 226 in dem Pufferspeicher 206 abgespeichert. Diese selektierten Ereignisse 226 wurden wie nachfolgend beschrieben nach einer bestimmten Vorgehensweise aus einer Reihe von auftretenden Ereignissen 220 (Nr. 0- bis bspw. 200) ausgewählt und im Pufferspeicher 206 als selektierte Ereignisse 226 abgespeichert.
Der nicht gefüllte Bereich bzw. der verbleibende Bereich des Pufferspeichers 206 bildet den freien Speicherbereich 250.
Der entsprechende Füllstand 228 der gezeigten Speicherbelegung wird im Ausführungsbeispiel gebildet durch das zuletzt abgespeicherte selektierte Ereignis 226.97. Der Speicherbereich des Pufferspeichers 206 ist nun in mehrere Bereiche 267 bzw. Füllstandsbereiche 267 aufgeteilt zwischen 0 und 100 %. Im Ausführungsbeispiel sind dies beispielsweise zehn (Füllstands)bereiche 267.1- 267.10. Im Ausführungsbeispiel sind die Bereiche 267 immer gleich groß gewählt, im Ausführungsbeispiel sind dies 10 %- Intervalle. Im Ausführungsbeispiel weist der Speicher 206 gerade den aktuellen Bereich 267.4, also den vierten Bereich 267.4 auf, der zwischen 30 und 40 % der kompletten Speicherbelegung liegt. Der aktuelle Speicherbereich 267.4, in dem sich der aktuelle Füllstand 228 des Speichers 206 befindet, wird in dem funktionalen Block 268 ermittelt. Der aktuelle Füllstandsbereich 267, im Ausführungsbeispiel 267.4 für den vierten Bereich, gelangt an einen Block 270.
In Block 270 wird der Offset 271 für das nächste Ereignis ermittelt. Der Offset 271 gibt an, aus wievielen Ereignissen 220 das nächste im Speicher 206 abzuspeichernde Ereignis 226 ausgewählt werden soll. Diese Anzahl (Offset 271) der Ereignisse 220, aus denen das nächste abzuspeichernde Ereignis 226 insbesondere zufällig ausgewählt werden soll, hängt ab von dem jeweiligen Füllstand 228 bzw. zugehörigen Speicherbereich 267. Bei niedrigem Füllstand 228 bzw. Speicherbereich 267 (der Füllstand 228 des Speichers 206 ist relativ niedrig) werden schneller Ereignisse 20 abgespeichert, also ist der Offset 271 relativ gering. Mit zunehmenden Füllstand 228 bzw. Speicherbereich 267 nimmt der Offset 271 zu, es werden also weniger Ereignisse 220 abgespeichert bzw. es wird nur ein Ereignis 220 aus einer größeren Anzahl (Offset 271) ausgewählt. Dadurch kann gezielt ein Overflow des Speichers 206 hinausgezögert bzw. verhindert werden. Innerhalb eines Offsets 271 erfolgt die zufallsbasierte Auswahl des nächsten abzuspeichernden Ereignisses 226. Pro Offset 271 wird immer nur ein Ereignis 220 (innerhalb des Offsets 271) zufallsbasiert selektiert bzw. abgespeichert. Durch Variation der Offset-Größe in Abhängigkeit des Füllstands 228 des Speichers 206 werden somit im Mittel mehr oder weniger Ereignisse 220 zufallsbasiert selektiert bzw. abgespeichert. Solange sich also der Füllstand 228 des Speichers 206 innerhalb eines bestimmten Bereichs 227 befindet, wählt der Ereignismanager 30 immer aus dem selben zugehörigen Offset 271 ein zu selektiertes Ereignis 226 aus, bis der Füllstand 228 den nächsten Bereich 227 erreicht mit einem veränderten, in der Regel erhöhten Offset 271.
Wird der Speicherbereich 267, definiert durch unteren bzw. oberen Grenzwert, verlassen, so kann der nächste Offset 271 für den neuen Bereich erhöht oder erniedrigt werden, beispielsweise um einen bestimmten Faktor bzw. Divisor.
Beispielhaft ist ein entsprechendes Szenario in der Tabelle gemäß Figur 8 gezeigt, das zu einer Belegung des Speichers 206 wie in Figur 7 gezeigt führt. Der Offset 271 könnte für die unterschiedlichen Füllstände 228 bzw. Speicherbereiche 267 beispielhaft wie nachfolgend angegeben gewählt werden. So könnte beispielsweise bei dem Speicherbereich zwischen 0 und 10 % (267.1) der Offset 271 zu zwei (von Null bis zwei, die Auswahl erfolgt also aus drei Ereignissen 220), bei dem Speicherbereich zwischen 10 % und 20 % (267.2) zu 8 (von Null bis acht, die Auswahl erfolgt also aus neun Ereignissen 220), für den Speicherbereich zwischen 20 % und 30 % (267.3) 32 (von Null bis 32, die Auswahl erfolgt also aus 33 Ereignissen 220) sowie für den Speicherbereich zwischen 30 % und 40 % zu 128 (von Null bis 128, die Auswahl erfolgt also aus 129 Ereignissen 220) usw. zugeordnet werden. Eine entsprechende Vergrößerung des Offsets 271 für den nächsten Speicherbereich 267 könnte beispielsweise durch einen entsprechenden Faktor (4) oder Ähnliches vorgenommen werden. Sowohl die Speicherbereiche 267 wie auch die Offsetwerte 271 können frei konfiguriert und damit an die jeweilige gewünschte Situation wie beispielsweise Speichergröße etc. angepasst werden.
In dem nachfolgenden Block 272 der Figur 7 soll nun das nächste abzuspeichernde Ereignis 220 zufällig (in Abhängigkeit von der Zufallszahl 273 wie in Figur 7 beispielhaft dargestellt) in Abhängigkeit von dem Füllstand 228 bzw. dem Speicherbereich 267 ausgewählt werden. Dabei muss sichergestellt werden, dass der Offset 271 , also die Anzahl der Ereignisse 220 bzw. der Bereich der nächsten zu betrachtenden Ereignisse 220, aus denen das jeweilige abzuspeichernde Ereignis 220 zufällig ausgewählt werden soll, von der Zufallszahl 273 bzw. einem entsprechenden Bereich der Zufallszahl 273 abgedeckt werden kann. Abhängig von dem jeweiligen Offset 271 wird die Größe des Bereichs der zu betrachtenden Zufallszahl 273 gewählt. Ist die Zufallszahl 273 beispielsweise Bit-codiert wie in Figur 7 beispielhaft gezeigt, werden beispielsweise für einen Offset 271 von zwei (0-2) zunächst ein vorläufger Bereich der Zufallszahl 273_temp vorläufiger in der Größe von zwei Bits ausgewählt. Bei einem Offset 271 von 8 (0-8) wird ein Bereich x der Zufallszahl 273. x_v in der Größe von 4 Bits ausgewählt. Bei einem Offset 271 von 32 (0-32) wird ein vorläufiger Bereich der Zufallszahl 273_v in der Größe von 6 Bits ausgewählt. Bei einem Offset 271 von 128 (0-128) wird ein vorläufiger Bereich der Zufallszahl 273_v in der Größe von 8 Bits ausgewählt. Der vorläufige Bereich der Zufallszahl 273_v lässt sich Spalte 4 entnehmen, dort beispielhaft angegeben für die konkrete Zufallszahl 273 der Figur 7. Anschließend wird überprüft, ob der in dem vorläufigen Bereich 273_temp enthaltene Abschnitt der Zufallszahl 273 kleiner oder gleich ist als der Offset 271 für den nächsten Speicherbereich 276.
Ist dies der Fall, so wird der vorläufige Bereich 273_v auch tatsächlich als Abschnitt der Zufallszahl 273.x als Zufallszahlbereich verwendet. Die entsprechende Abfrage in Spalte 5 kann mit „TRUE“ beantwortet werden. Für diese Fälle stimmen der temporäre Abschnitt der Zufallszahl 273. x_v mit dem ausgewählten Abschnitt der Zufallszahl 273.x überein. Ist dies nicht der Fall (Abfrage in Spalte 5 wird mit „FALSE“ beantwortet), so wird der vorläufige Abschnitt der Zufallszahl 273. x_v verkleinert. Dies kann durch Weglassen eines Bits erfolgen, bevorzugt des höherwertigsten Bits (MSB). Für den sich dann ergebenden Wert der Zufallszahl in diesem Bereich 273.x kann nun sichergestellt werden, dass dieser Wert innerhalb des Offsets 271 für den nächsten Speicherbereich 267 liegt.
So werden beispielsweise für einen Offset 271 von 8 (0-8) zunächst 4 Bits der Zufallszahl 273 betrachtet, um auch die Zahl 8 selbst (Größe des aktuellen Offsets 271) abzudecken, vgl. hierzu Spalten mit Puffereinträgen Nr. 3, 4, 5 in Fig. 8. Ist der 4 Bit große Wert des zugehörigen vorläufigen Zufallszahl-Bereichs 273.5_v <= der Offset 271 - bspw. Ereignis Nr. 25, 273.5 = 0b0111 = 7, dann wird diese 4 Bit Zahl direkt verwendet. Die zugehörige Abfrage zeigt Spalte 5 der Figur 8. Da die Bedingung erfüllt ist, ist das Ergebnis „TRUE“.
Ist der 4 Bit große Wert des zugehörigen vorläufigen Zufallszahl-Bereichs 273.4_v > der Offset 271 - bspw. Ereignis Nr. 13, 273.4 = 0b1100 = 12, dann wird diese 4 Bit-Zahl nicht direkt verwendet, sondern das MSB (höchstwertiges Bit für den betrachteten Bereich der Zufallszahl 273.4) abgeschnitten und die daraus resultierende 3 Bit-Zahl 0b100 = 4 verwendet. Das abgeschnittene MSB muss nicht weggeworfen werden, sondern geht als LSB (niederwertigstes Bit) des nächsten zu betrachtenden Bereichs der Zufallszahl 273.5_v ein. Die zugehörige Bedingung (ist der entsprechende Zufallszahlbereich 273.3 <= Offset 271) ist in diesem Fall nicht erfüllt (zugehöriges Ergebnis „FALSE“ in Spalte 5). Durch diese Vorgehensweise kann sichergestellt werden, dass die Zufallszahl 273 komplett verwendet und nicht unnötig schnell verbraucht wird.
Für die Ermittlung der Größe des Zufallszahlbereichs 273.x (bspw. der Anzahl der benötigten Bits für den Bereich der Zufallszahl 273) ist zu berücksichtigen, ob die Größe (bswp. die Anzahl der benötigten Bits) zur Darstellung der Größe des Offsets 271 des zugehörigen Speicherbereichs 267 des nächsten Ereignisses 220 ausreicht.
Beim Ausführungsbeispiel gemäß Figur 8 wird also gemäß Zeile 1 bei dem Offset 271 von 2 (von 0-2) bei der ausgewählten Zufallszahl 273.1 von 2 also Ereignis Nr. 2 (220.2, globaler Ereigniszähler 285 beträgt 2) (nach Verwerfen der Ereignisse 220.0, 220.1 Nr.O und Nr.1) als selektiertes Ereignis 226.2 ausgewählt. Gemäß Zeile 2 wird beim nächsten Offsetbereich 271 (immer noch bei 0-2) zufällig Ereignis Nr. 1 bezogen auf diesen Offsetbereich 271 ausgewählt. Ereignis Nr. 0 in diesem Offsetbereich 271 wurde verworfen (entspräche dem globalen Zählerstand 285 von 3), jedoch Ereignis Nummer 1 in diesem Offsetbereich 271 wurde selektiert (entspricht dem globalen Zählerstand 285 von 4, ergibt selektiertes Ereignis 226.4). Der nächste Offsetbereich 271 liegt gemäß Zeile 3 immer noch bei 2 (0-2), da der Füllstand 267 des Puffers 206 immer noch im Bereich 267.1 zwischen 0 und 10 % liegt. Die Zufallszahl für 273.3 liegt bei 2, sodass nach Verwerfen der Ereignisse Nummer 0 und 1 in diesem Offsetbereich 271 das Ereignis Nr. 2 selektiert wird (globaler Zählerstand 285 bei 8, selektiertes Ereignis 226.8). Da sich anschließend der Füllstand 267 im nächsten Füllstandsbereich 267.2 befindet, verändert sich der neue Offset 271 nun auf 8 (0-8). Wie oben beschrieben werden nun die nächsten 4 Bits des vorläufigen Zufallszahlbereichs 273.4_v betrachtet. Da die zugehörige Zufallszahl des vorläufigen Zufallszahlbereichs 273.4_v mit 12 größer ist als der aktuelle Offset 271 (Abfrage 12<=8 in Spalte 5 ergibt „FALSE“) wird das höchstwertige Bit des vorläufigen Zufallszahlbereichs 273.4_v nicht verwendet, sondern lediglich die niederwertigen 3 Bits im Rahmen des ausgewählten Zufallszahlbereichs 273.4 (binär 100, also 4). Somit werden für diesen neuen Offsetbereich 271 von 8 (0-8) die Ereignisse Nr. 0 (globaler Zählerstand 285 ist 9) bis Nr. 3 verworfen und Ereignis Nummer 4 (globaler Zählerstand 285 ist somit 13) als selektiertes Ereignis 226.13 ausgewählt. Beispielhaft stellt Figur 8 die entsprechenden Werte für weitere Füllstände 267 zusammen.
In Block 272 wurde also nun zufallsabhängig ermittelt, welches Ereignis 220 als nächstes ausgewählt wird als selektiertes Ereignis 226. Der entsprechende Block 280 überwacht nun das Auftreten neuer Ereignisse 220 (Block 284). Vorher festgelegt wurde beispielsweise das nach dem abgespeicherten Ereignis 226.8 (8. Ereignis) als nächstes das Ereignis 226.13 (13. Ereignis) abgespeichert werden soll. Block 280 wartet also auf das Ereignis Nr. 13, verwirft also die nächsten Ereignisse Nr. 9-12 und speichert erst Ereignis Nr. 13 als selektiertes Ereignis 226.13 im Speicher 206 ab. Abhängig von dem neuen selektierten Ereignis 226 mit einer Datengröße der Metadaten 215 (ereignisabhängige Metadaten 216 und generische Metadaten 217) wird der neue Füllstand 228 des Speichers 206 ermittelt. Dies könnte beispielsweise besonders einfach unter Verwendung der Länge 232 wie bereits in den Metadaten 215 enthalten erfolgen.
Die Zufallszahl 273 ist für unterschiedliche Steuergeräte bzw. Fahrzeuge 18 unterschiedlich zu wählen. So könnte die Zufallszahl 273 beispielsweise in der Produktion einmalig fahrzeugindividuell bzw. steuergeräteindividuell vergeben werden. Alternativ könnte die Zufallszahl 273 intern nach bestimmten Regeln selbst neu generiert werden. Die Neugenerierung könnte beispielsweise bei Übergängen von Systemzuständen (beim Booten, Reset, Überführen in einen Schlafmodus etc.) und/oder zyklisch nach bestimmten Zeiten erfolgen.
Aus den entsprechenden Informationen ermittelt der Block 272 den nächsten Ereignis-Treffer 278 (next event hit: der nächste Ereignistreffer 278 im nächsten Offset 271). Der nächste Ereignis-Treffer 278 gelangt an einen Block 280 (throw the dice), in dem zufallsbasiert das zugeführte Ereignis 220 entweder verworfen (Ereignis 220 wird nicht im Pufferspeicher 206 abgespeichert) oder ausgewählt wird als selektiertes Ereignis 226 zum Abspeichern im Pufferspeicher 206.
Sofern die Auswahl erfolgt (Ereignis-Treffer 282, event hit) schließt sich Block 284 an. Block 284 wird bei jedem Ereignis 220 aufgerufen. Block 284 selbst ruft jedoch (bei jedem Ereignis 220) Block 280 auf, welcher Rückmeldung an Block 284 gibt, ob das Ereignis 220 selektiert werden soll oder nicht. Falls das Ereignis 220 durch Block 280 selektiert wurde, dann triggert Block 284 das Speichern des Ereignisses 220 im Speicher 206 als selektiertes Ereignis 226.
In Block 284 (on event) erfolgt das Einlesen des ausgewählten Ereignisses 220 zum anschließenden Abspeichern in dem freien Bereich 250 des Pufferspeichers 206 als selektiertes Ereignis 226. Block 284 wird immer bei jedem neu eingehenden Ereignis 220, 221 aufgerufen. Block 284 dient der zufälligen Auswahl inklusive möglicher Reduktion und Priorisierung eingehender Ereignisse 220, 221. Neben der zufallsbasierten Auswahl in Block 280 kann darüber hinaus eine zufallsabhängige Reduzierung des Ereignisses 220 erfolgen wie beispielsweise bereits mit den ETH Sensoren 26 beschrieben. So kann zufallsabhängig ein bestimmter Datenbereich (Beginn eines vorzugsweise festen Datenbereichs oder Ende eines Datenbereich) ausgewählt werden. Ebenso könnten nur bestimmte reduzierte Adressdaten abgespeichert werden.
Ebenso könnte bei einem hohen Aufkommen von Ereignissen 220 oder generell der Sensor 24, 26, 28 selbst (bei einer bestimmten Quelle, beispielsweise Ethernet) Ereignisse 220 selektieren bzw. reduzieren, quasi eine Vor-Filterung analog zum Ereignismanager 30, um den Ereignismanager 30 (bei dem auch Ereignisse 220 anderer Quellen eingehen) zu entlasten. Falls der Sensor 24, 26, 28 bereits einzelne Ereignisse 220 nicht an den Ereignismanager 30 weiterleitet, sollte dies ebenfalls als eigene Ereignisart 218 an den Ereignismanager 30 kommuniziert werden (analog des Reduktionsstatus 225 im Ereignismanager 30). Generell könnte jedoch die ereignisabhängige Selektierung von Ereignissen 220 im Sensor 24,26, 28 selbst erfolgen und in einem Pufferspeicher des Sensors 24, 26, 28 abgelegt werden. Entsprechende Zähler können ebenfalls auch im im Sensor 24, 26, 28 für die jeweiligen Ereignisarten 218 vorgesehen werden, die bei Bedarf an den Ereignismanager 30 übermittelt werden könnten. Auch könnten die vom Sensor 24, 26 ,28 selektierten Ereignisse 226‘ auf Anforderung durch den Ereignismanager 30 an diesen kommuniziert werden zur eventuellen Weiterleitung an die übergeordnete Instanz 34 und/oder das Backend 36. Die in Verbindung mit dem Ereignismanager 30 beschriebenen Vorgehensweisen zur zufälligen Auswahl und/oder Priorisierung können gleichwohl im Sensor 24,26, 28 ablaufen. Gleichwohl können sie lediglich auf die speziellen Daten 211 für die jeweilige Quelle beschränkt sein, der Sensor 24,26, 28 kann also nur sensorspezifische Ereignisse 220 selektieren.
Der Kommunikationsadapter 32 könnte zur Erhöhung der Sicherheit eine zufallsbasierte, für einen Angreifer nicht determininistisches und verschleiertes Versenden eines Ereignisberichts 242 zu anderen IDS Instanzen 34 vorsehen.
Wie bereits in Verbindung mit Figur 2d beschrieben wird aus in dem Pufferspeicher 206 abgelegten selektierten Ereignissen 226 ein Ereignisbericht 242 generiert. Dieser umfasst die in dem Pufferspeicher 206 abgelegten selektierten Ereignisse 226. 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 und der den Ereignisbericht 242 empfangenden Einheit (IDS Instanz 34, Backend 36 oder Ähnliches) erfolgen. Die Authentifizierungs-Information 256 könnte beispielsweise gebildet werden aus zumindest einem Teil der Daten des Ereignisberichts 242, vorzugsweise aus sämtlichen Daten des Ereignisberichts 242 (mit Ausnahme natürlich der zu bildenden Authentifizierungs-Information 256). Hierzu ist ein entsprechender Algorithmus im Ereignismanager 30 hinterlegt. Zum Zwecke der Authentifizierung kann eine übergeordnete Einheit 34 und/oder das Backend 36 in gleicher Weise aus den entsprechenden Daten des empfangenen Ereignisberichts 242 nach Entschlüsselung die zugehörige Authentifizierungs-Imformation 256‘ gebildet werden und mit der tatsächlich empfangenen Authentifizierung-Information 256 wie in dem Ereignisbericht 242 übermittelt verglichen werden. Bei Übereinstimmung wird von Authentizität ausgegangen.
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. Selbst wenn sich die für jeden Ereignisbericht 242 verändernde Größe 254 sich beispielsweise nur um 1 Bit unterscheidet, so bewirkt die anschließende Verschlüsselung 258, dass sich der verschlüsselte Ereignisbericht 242 stark (und nicht nur in einem Bit) von dem vorhergehenden Ereignisbericht 242 unterscheidet.
So könnten bestimmte Ereignisse 220 zyklisch und verschlüsselt (sowohl mit einer immer veränderten Größe 254 als Teil des Ereignisberichts 242 im Klartext sowie mit der Verschlüsselung 258 des Ereignisberichts 242) im Rahmen des Ereignisbereichts 242 übertragen werden. Doch auch wenn keine neuen Ereignisse 220 vorliegen, könnten sogenannte Dummy-Ereignisse (bestehend bspw. aus Fülldaten 255) 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 34.
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 9-14 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 9 selektiert der 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 Kommunikationsadapter 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 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 Kommunikationsadapter 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 erfolgen, wenn die entsprechenden Sicherheitserfordernisse erfüllt sind.
Alternativ könnte der Kommunikationsadapter 32 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.
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. Nach Erhalt des Bestätigungssignals 408 generiert der Kommunikationsadapter 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 9 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 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 zur Authentifizierung. 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 10 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 9) 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 11 gezeigt. Erneut tritt ein weiterer Timer Interrupt für den Kommunikationsadapter 32 auf, Signal 440. Daraufhin sendet der Kommunikationsadapter 32 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 und übersendet den verschlüsselten Ereignisbericht 242 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 12 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 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 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. 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 13 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. 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 verschlüsselt und an weitere IDS Instanzen 34 übertragen, Signal 486. 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 14 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 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 und übersendet diesen 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, wobei der Sensor (24,26, 28) die erhaltenen Daten (211) auf Anomalien untersucht, bei einer erkannten Anomalie in Abhängigkeit der zugehörigen Daten (211) ein Ereignis (220, 221) erzeugt und das Ereignis (220, 221) an einen Ereignismanager (30) weiterleitet, wobei der Ereignismanager (30) entscheidet, ob das Ereignis (220,221) oder zumindest eine von dem Ereignis (220, 221) abhängige Größe in einem Speicher (208) zumindest teilweise abgespeichert wird, dadurch gekennzeichnet, dass ein Zeitpunkt des Abspeicherns des Ereignisses (220, 221) bzw. einer von dem Ereignis (220, 221) abhängigen Größe zufällig ausgewählt wird.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass der Zeitpunkt des Abspeicherns innerhalb eines bestimmten Zeitintervalls zufällig ausgewählt wird.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Zeitpunkt des Abspeicherns, der zufällig ausgewählt wird, von einer Zufallszahl (273) abhängt.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zufallszahl (273) steuergeräteindividuell und/oder fahrzeugindividuell gewählt wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass derZeitpunkt des Abspeicherns bestimmt wird, indem eine Zufallszahl (273) oder ein Bereich einer Zufallszahl (273) mit einem Zeitintervall verknüpft wird, insbesondere durch Multiplikation.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Zufallszahl (273) zyklisch und/oder in Abhängigkeit von bestimmten Systemereignissen wie Übergang von Systemzuständen wie beispielsweise Reset, Hochfahren, Überführen in einen Ruhemodus etc. neu generiert wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Abspeichern in einem nichtflüchtigen Speicher (208), insbesondere ein Flash-Speicher, erfolgt.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Abspeichern in dem nichtflüchtigen Speicher (208) erfolgt, indem in einem weiteren Speicher (206), insbesondere ein Pufferspeicher bzw. nichtflüchtiger Speicher, abgelegte Ereignisse (226) auch in dem nichtflüchtigen Speicher (206) abgelegt werden.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein Abspeichern eingeleitet wird, wenn ein Zustandswechsel, beispielsweise in einen Ruhemodus oder Neustart, eines Steuergeräts erfolgt.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass Daten in dem nichtflüchtigen Speicher (208) redundant abgelegt werden, wobei bei einem Wiederherstellen von Daten überprüft wird, ob die abgespeicherten Daten authentisch bzw. integer sind.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ereignismanager (30) dem jeweiligen erhaltenen Ereignis (220,221) noch weitere Informationen zuzuordnet, insbesondere generische Metadaten (217) wie beispielsweise Zählerstand (231) eines Ereigniszählers (204,205) und/oder ein Zeitsignal (224) und/oder eine Länge (232) des selektierten Ereignisses (226) und/oder eine Anzahl nicht weiterverarbeitet Ereignisse (22,221), wobei ein Zeitpunkt des Abspeichern der weiteren Informationen zufällig ausgewählt wird.
PCT/EP2021/056534 2020-03-28 2021-03-15 Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug WO2021197820A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202180024768.0A CN115398429A (zh) 2020-03-28 2021-03-15 用于处理数据异常的方法，特别是在机动车辆中

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=74874888

Family Applications (1)

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

Country Status (3)

Country Link
CN (1) CN115398429A (de)
DE (1) DE102020204055A1 (de)
WO (1) WO2021197820A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114326676A (zh) * 2021-12-30 2022-04-12 北京三快在线科技有限公司 一种入侵检测方法、装置、存储介质及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001082033A1 (de) * 2000-04-19 2001-11-01 Syntion Ag Verfahren zur abrechnungsfähigen erfassung der nutzung eines computerprogramms
EP3528163A1 (de) * 2018-02-19 2019-08-21 Argus Cyber Security Ltd Kryptische fahrzeugabschirmung
EP3567509A1 (de) * 2018-05-09 2019-11-13 Palantir Technologies Inc. Systeme und verfahren zur manipulationssicheren aktivitätsprotokollierung
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001082033A1 (de) * 2000-04-19 2001-11-01 Syntion Ag Verfahren zur abrechnungsfähigen erfassung der nutzung eines computerprogramms
EP3528163A1 (de) * 2018-02-19 2019-08-21 Argus Cyber Security Ltd Kryptische fahrzeugabschirmung
EP3567509A1 (de) * 2018-05-09 2019-11-13 Palantir Technologies Inc. Systeme und verfahren zur manipulationssicheren aktivitätsprotokollierung
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114326676A (zh) * 2021-12-30 2022-04-12 北京三快在线科技有限公司 一种入侵检测方法、装置、存储介质及电子设备
CN114326676B (zh) * 2021-12-30 2023-10-24 北京三快在线科技有限公司 一种入侵检测方法、装置、存储介质及电子设备

Also Published As

Publication number Publication date
CN115398429A (zh) 2022-11-25
DE102020204055A1 (de) 2021-09-30

Similar Documents

Publication Publication Date Title
EP3278529B1 (de) Angriffserkennungsverfahren, angriffserkennungsvorrichtung und bussystem für ein kraftfahrzeug
EP3625950B1 (de) Datenverarbeitungseinrichtung, gesamtvorrichtung und verfahren zum betrieb einer datenverarbeitungseinrichtung oder gesamtvorrichtung
DE102020101358A1 (de) Selektive Echtzeit-Kryptographie in einem Fahrzeugkommunikationsnetz
DE102017124399A1 (de) Hardware-sicherheit für eine elektronische steuereinheit
DE102014224694A1 (de) Netzwerkgerät und Netzwerksystem
WO2010028936A1 (de) Verfahren zur datenübertragung zwischen netzwerkknoten
EP3136285A1 (de) Verfahren und speichermodul für sicherheitsgeschützte schreibvorgänge und/oder lesevorgänge auf dem speichermodul
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
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
EP3871393B1 (de) Verfahren zur überwachung eines datenübertragungssystems, datenübertragungssystem und kraftfahrzeug
DE102012210327A1 (de) Verfahren zum Übertragen von Nachrichten in einem Kommunikationssystem, insbesondere eines Fahrzeugs
WO2021197822A1 (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
WO2021197828A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197826A1 (de) Vorrichtung zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197821A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
WO2021197824A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
EP3723007B1 (de) Verfahren und steuersystem zum steuern einer ausführung von transaktionen
EP3682317B1 (de) Verfahren zum betrieb einer berührungssensitiven, flächigen eingabevorrichtung einer gesamtvorrichtung und gesamtvorrichtung
DE102017204156B3 (de) System und Verfahren zur sicheren Fahrzeugkommunikation
EP3363146B1 (de) Verfahren zur erzeugung eines schlüssels in einer schaltungsanordnung
WO2018177614A1 (de) Schutzeinrichtung, verfahren und gerät enthalten eine schutzeinrichtung zum schutz eines mit dem gerät verbundenen kommunikationsnetzwerks
DE102023001975A1 (de) Kommunikationssystem und Fahrzeug
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: 21712153

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21712153

Country of ref document: EP

Kind code of ref document: A1