WO2021197828A1 - 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
WO2021197828A1
WO2021197828A1 PCT/EP2021/056573 EP2021056573W WO2021197828A1 WO 2021197828 A1 WO2021197828 A1 WO 2021197828A1 EP 2021056573 W EP2021056573 W EP 2021056573W WO 2021197828 A1 WO2021197828 A1 WO 2021197828A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
events
data
memory
random number
Prior art date
Application number
PCT/EP2021/056573
Other languages
German (de)
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 JP2022558499A priority Critical patent/JP7441326B2/ja
Priority to CN202180024776.5A priority patent/CN115398428A/zh
Publication of WO2021197828A1 publication Critical patent/WO2021197828A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G06F11/3082—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved by aggregating or compressing the monitored data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect

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.
  • a random decision is made and / or a decision is made as a function of a number of occurrences of an event for a certain type of event as to whether the event is to be further processed. This means that events are selected for the attacker in a non-deterministic way. This reduces the number of events. This simplifies the further processing of the selected events.
  • the associated number of events that have occurred in each case is determined for different types of events. This generates helpful additional information that is useful for a later evaluation.
  • the individual types of events can also be related to one another.
  • certain types of events are each assigned to different priority groups, with events in a higher priority group being more likely to be processed further, in particular randomly, than events with a lower priority group. By combining them into different priority groups, individual events can be selected in a simplified manner with regard to their significance. However, due to the random selection of a selected event within the priority group, the behavior remains incomprehensible for the attacker or cannot be determined deterministically.
  • the different priority groups are assigned certain offsets or areas, from which at least one event to be further processed of the respective priority group is selected, the offset or the area of a priority group with a higher priority being smaller than the offset or the area of a priority group with lower priority. This means that it is always possible to randomly select within an offset how many events are selected on average depending on the priority. As a result, more events are selected randomly for events with a higher priority group, and fewer events are selected randomly for events with a lower priority group.
  • a random decision is made using a random number and / or a range of a random number, in particular a vehicle-specific and / or control unit-specific random number. This ensures the non-deterministic behavior of the anomaly reduction. Even in the case of the disclosure of the random number in a vehicle, the knowledge acquired cannot be applied to one another vehicle can be transferred. 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.
  • An expedient development provides that the event to be further processed is at least partially stored in a memory, in particular in a volatile memory or buffer memory and / or in a non-volatile memory (208) and / or communicated as part of an event report and / or with others Information, in particular generic metadata such as the number of events that have occurred, time signal, number of events not processed further, length is provided. In this way, helpful additional information can be generated, which is helpful for the subsequent evaluation. By archiving the length of each event, conclusions can be drawn about the fill level of the buffer without having to read out the fill level separately.
  • sensors are provided for anomaly detection, each of which receives data from different data sources, in particular a communication system and / or a host or microcontroller, each of the sensors examining the received data for anomalies when an anomaly is detected Generates an event depending on the associated data and forwards the event to an event manager.
  • the event manager ensured a higher-level perspective in a suitable selection of the events to be selected.
  • 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).
  • the detection of anomalies in data 211 is implemented by means of what is known as an intrusion detection system, IDS or IDPS.
  • IDS intrusion detection system
  • 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 via a communication network.
  • the gateway 20 processes, for example, instructions for the data connection.
  • the communication produces data 211 in the form of data packets.
  • Data 211 for example system data, also arise during the operation of the host 29.
  • setpoint values are maintained, for example with regard to recipient and destination address, compliance with the correct program sequence (for example for host 29), time stamp, frequency of occurrence or frequency of data 211 of specific data packets.
  • the data 211 of the data packets are exchanged between further control devices or components in the vehicle 18 (not shown in detail) in order to fulfill the specific tasks.
  • the gateway 20 is used to couple several communication systems or interfaces such as a CAN bus 25, an Ethernet connection 27 and a data connection to the host system 29, which is part of the control device 20 or the gateway.
  • other communication systems for example further wired bus systems such as LIN, CAN-FD etc. or wireless networks (for example WLAN or Bluetooth
  • an intrusion detection IDS or anomaly detection is used in one Control device for this purpose, all data 211 (data 211 received by the communication system as well as generated within the control device 20 by the host 29 Data 211) for corresponding anomalies.
  • the IDS functional mechanism is described for the gateway 20 as an example.
  • the described functionalities of anomaly detection or intrusion detection IDS can be implemented in any control device or any electronic components.
  • the use is not restricted to a vehicle 18.
  • any communication components for example communication modules in the Internet (IOT Internet of Things) or in networked production systems, can be equipped with the functions described.
  • a communication component such as the control device or the gateway 20 includes at least one anomaly detection 22.
  • the data 211 arriving via the interfaces of the respective communication systems 25, 27, 29 are each conducted via so-called sensors 24, 26, 28 for anomaly detection or intruder detection, IDS sensors for short .
  • Corresponding sensors 24, 26, 28 are arranged in gateway 20. Such sensors 24, 26, 28 serve to detect whether the data 211 received represents an anomaly.
  • Corresponding filter algorithms or 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 that are able to detect anomalies in the respective sources or anomaly sources and, if necessary, to classify them.
  • the IDS CAN sensors 24 detect incidents 220 of associated event types 218, such as invalid CAN ID's, invalid messages frequencies, invalid message length or the like.
  • the IDS Ethernet sensors 26 detect relevant events 220 of associated event types 218 for the Ethernet 27, such as invalid addresses or MAC addresses, invalid message frequencies, invalid message lengths or the like.
  • the IDS host sensors 28 detect events 220 of associated event types 218 that are relevant for the host system 29, such as, for example, invalid code executions, corruption of programs, batch counters or the like.
  • 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 Vehicle 18) and / or a backend 36 (preferably outside of 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 the added generic metadata 217 as selected events 226 in a random manner in addition to the event-dependent metadata 216.
  • the communication adapter 32 could undertake a random, non-deterministic and disguised uploading or sending of an event report 242 to other IDS instances 34 for an attacker.
  • the randomly controlled upload could, for example, be based on a random number 273 that is individual for a specific control device (or gateway 20).
  • specific events 220 could be transmitted cyclically and in encrypted form within the scope of the event report 242. But even if there are no new events 220, so-called dummy events could be transmitted cyclically and encrypted in the format of an event report 242. This serves to protect against eavesdropping or to conceal the data exchange based on chance between the communication adapter 32 and further IDS entities 34 or the backend 36.
  • FIG. 2 it is shown by way of example how data 211 from the sensor 24, 26, 28 are further processed in the event of a detected anomaly and sent to the event manager 30 until the latter sends an event report 242 via the communication adapter 32.
  • a data packet of data 211 is shown in FIG. 2a as it could occur, for example, in a network frame (for example CAN, Ethernet).
  • the data 211 has a header 214 which includes, for example, the source address and the destination address (for example MACa, MACb).
  • the data 211 include useful data 213.
  • the senor 24, 26, 28 could optionally select a useful data area 219 at random, which is forwarded to the event manager 30.
  • the sensor 24, 26, 28 has determined that it is an anomaly according to a certain type of event 218 (event ID or event ID,
  • the sensor 24, 26, 28 therefore generates event-dependent metadata 216 as shown in FIG. 2b.
  • event-dependent metadata 216 Depending on the event type 218 (or ID), different information about the anomaly can be stored in the event-dependent metadata 216.
  • the source and destination address (MACa, MACb), the event type 218 and the selected useful data area 219, among other things, are used as event-dependent metadata 216.
  • event-dependent useful data 213 could also be forwarded to the event manager 30 in full as part of the event 220.
  • the event 220 could also not include any event-dependent user data 213, for example if the host 29 is used as the source.
  • event-dependent metadata 216 can be part of the event 220 for different event types 218.
  • the event-dependent metadata 216 could, for example, include the context, for example in the size of 32 bits.
  • the event-dependent metadata 216 could, for example, be the accessed address (for example 32 bits), the program counter (e.g. 32 bits) that comprise the task ID (e.g. 8 bits).
  • the event-dependent metadata 216 could include, for example, the reason for the reset (for example 8 bits), for example POR (point of return), software reset, exceptions, etc.
  • Subsequent Ethernet-related events 220 could be logged as event-dependent metadata 216, such as static / state-dependent filter violations (specific rule ID or ID for specific event type 218 (e.g. 16 bits), an ID of the filter rule that caused event 220 if available, physical port address, physical port ID via which the frame was received, source address (e.g. MAC address, e.g. 48 bit), destination address (e.g. MAC address, e.g. 48 bit), possibly IP address of the source or destination, Determination of the UDP / TCP port (e.g. 16 bit) if available in the frame, optional).
  • specific rule ID or ID for specific event type 218 e.g. 16 bits
  • ID of the filter rule that caused event 220 if available
  • physical port address e.g. 48 bit
  • destination address e.g. MAC address, e.g. 48 bit
  • IP address of the source or destination e.g. 16 bit
  • Determination of the UDP / TCP port
  • static / state-dependent filter violations could also be logged, such as rule ID, physical port, frame (number of bytes), certain number of bytes of the received frame are stored, selected user data area 219 (certain number of bytes) selected user data area 219 of the bytes of the original Frames, user data area 219 - index (for example 16 bits), start byte of the selected user data area 219 in the original frame.
  • Ethernet-related events could also be contained in the events 220 transmitted to the event manager 30, such as for the event type 218 "Transmission rate limited (active / inactive)" the rule ID with the associated ID of the filter rule that caused the event 220, for 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 are identified as event 220 and reduced event 221, respectively (due to the random selection or reduction of the useful data area 219 to be transmitted in the sensor 24, 26, 28) to the event manager 30.
  • generic metadata 217 are added to the event-dependent metadata 216 so that the metadata 215 shown in FIG. 2c arise.
  • These generic metadata 217 are usually generated in the event manager 30. These are, for example, output signals from event counters 204, that is to say current counter readings 231, how many global event 220 or how many event of a specific event type 218 the current event 220 is.
  • the generic metadata 217 can include, for example, a time signal 224 indicating when this event 220 occurred.
  • the metadata 217 could include the length 232 (size of the data) the event-dependent metadata 216 or the complete metadata 215 have. This is advantageous for the later memory management of the buffer memory 206.
  • the following generic metadata 217 is proposed as an example. This could, for example, be an event type 218 in the context of an event ID (for example 8 bits). This event ID of event type 218 is unique and can, for example, comprise a TLV-based coding (TLV: Type-Length-Value type-length-value).
  • the generic metadata 217 include the length 232, for example between 8 and 16 bits in size. The size of the data (metadata 215) follows the length field in bytes, up to a maximum of 255 bytes. Again, TLV-based coding could be provided. Also included is the time signal 224, a time stamp (for example 64 bits).
  • the time 224 is given, for example, in the form of an absolute time value that has elapsed since a reference point in time such as January 1, 1970 (in milliseconds) for the purpose of specifying a unique time stamp.
  • the generic metadata 217 counter readings 231 or output values 231 of the event type counter 204 (for example 32 bits) and / or the counter reading 231 of the global (event) counter 204 (for example 32 bits), a sum of all counter readings 231 of the event counters 204 for each event type 218.
  • the event-dependent metadata 216 are adopted as they were formed by the respective sensor 24, 26, 28.
  • This event 220 with the corresponding metadata 215 formed both by the sensor 24, 26, 28 and by the event manager 30 is stored in the buffer memory 206 of the event manager 30.
  • further events 226 selected or reduced by the event manager 30 designated as 215_1, 215_8, 215_190 in the exemplary embodiment according to FIG.
  • an event report 242 is now generated. This includes the selected events 226 stored in the buffer memory 206 (in the example 215_ 1, 215_8,
  • the event report 242 also includes authentication information 256.
  • the authentication between communication adapter 32 or event manager 30 and the unit receiving the event report 242 can also take place.
  • the event report 242 has a fixed length 258. To achieve this fixed length 258, the data 254, 215_ 1, 215_8,
  • the 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 very quickly with a large number of events 220 to be forwarded with large amounts of data or event-dependent metadata 216 no longer includes all events 220. 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 randomly controlled selection or reduction could be based, for example, on a random number 273 that is individual for a specific control device. 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 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).
  • 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
  • could be determined on a random basis e.g. transfer a data area whose start value was determined randomly, e.g.
  • 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 could also be varied, preferably randomly ab from a random number 273.
  • This random number 273 is particularly preferably dependent on the control device or the gateway 20. Particularly preferably, the random number 273 is unambiguous, that is to say it is only assigned once for this specific control device.
  • 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 sent to the higher-level instance 34, 36 completely between two attack sequences forwarded. 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 so large that the selection of a certain reduced user data area 219 can also cover this large data area of the user 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 another control device, sub-data area 558-567 (another selected user data area 219) and the respective selected user data areas 219 are reassembled, for example in a higher-level control unit or in the backend 36, to form a complete (user) data area 213 .
  • This is the case in particular in the case of a so-called broadcast attack on the entire vehicle fleet or a so-called multicast attack on parts of the vehicle fleet.
  • the random determination of the beginning and / or the end of the forwarded or selected useful data area 219 is preferably carried out 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 area of the random number 273 could be used to generate the start and / or end of the data area to be forwarded or selected useful data area 219.
  • 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 user data 213. The address area 214 could be reduced by selecting the destination 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 random number 273 or areas of the random number 273 for determining the start or end area of 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, i.e.
  • 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. This is particularly the case when, for example, in the context of a so-called event burst, a large number of events 220, 221 are received with an increased fill level 228 of the buffer memory 206.
  • an additional event 220 is to be generated, for example with an event type 218 "Event reduction active" as described above.
  • 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 block 210 for the communication of events, in particular of event reports 242, exchanges signals 244 with a cryptography module 212.
  • 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 saved.
  • block 202 serves to use the events 220, 221 supplied to event manager 30 to further process the events as selected events 226 to select.
  • 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 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 depending on the respective event type 218 and one of their own Instance for the random event reduction can 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 the basis of chance (N1: (number of selected events for priority group 1 (Priol), Nx: number of selected events for priority group x ( Prio_x).
  • 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. According to FIG.
  • 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.
  • data can in principle be stored in the non-volatile memory 208 if this state 264 is reached.
  • 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.
  • 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 memory 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 filling level 228 of the memory 206 is within a certain range 227 is located, the event manager 30 always selects an event 226 to be selected from the same associated offset 271 until the fill level 228 reaches the next area 227 with a changed, usually increased offset 271.
  • the next offset 271 for the new area can be increased or decreased, for example by a certain factor or divisor.
  • the offset 271 could be selected for the different filling levels 228 or memory areas 267, for example, as indicated below.
  • 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 is dependent on the respective offset 271 of the range of the random number 273 to be considered is selected. 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 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) to represent the size of the offset 271 of the associated Storage 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, it was previously specified that after the stored event 226.8 (8th event) the next event 226.13 (13th event) should be stored. 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 calls itself however (for each event 220) block 280, which gives feedback to block 284, whether the event 220 should be selected or not. 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 Procedures for random selection and / or prioritization can nonetheless run 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 the selected events 226 stored in the buffer memory 206. These selected events 226 are preceded by a variable 254 (for example random number, time or counter, etc.) that is different from each event report 242.
  • 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. In order to achieve this 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 in FIG of Figure 2d indicated.
  • 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 thus be transmitted cyclically 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 scope of the event report 242. 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 can 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 an event report 242 is sent cyclically from the communication adapter 32 to further IDSs Instances 34 in the vehicle 18 is initiated.
  • 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 whether his attack was detected, 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. Then a dummy message with the data format of an event report 242 is used and encrypted by a random number or the constantly changing size 254 (using the key 258) is transmitted to the further IDS entity 34. Dummy messages are also always encrypted by constantly changing sizes 254 or new random numbers, so that even if new selected events 226 do not occur, other or encrypted messages (signal 406) are always transmitted cyclically. As a result of the cyclical transmission, the functioning of a proper communication connection between the communication adapter 32 and the further IDS entity 34 can be checked.
  • 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 decrypts and / or the backend 36 the received message, namely the encrypted event report 242, using the known key 258.
  • the event report 242 is then available in plain text.
  • the event report 242 is authenticated using the corresponding algorithm (which was also used by the event manager 30 or communication adapter 32 to create the authentication information 256) to form the authentication information 256.
  • all the data of the received and decrypted event report 242 (with the exception of the authentication information 256) are used again and a corresponding authentication information 256 'is formed therefrom.
  • the authentication information 256 'formed is then compared with the authentication information 256 received in the context of the event report 242. If there is a match, the received event report 246 is considered authentic. 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.
  • the 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 variable 254 ′ does not have to be generated in the higher-level instance 34, 36 itself. This can be followed by the release of the memory 206.
  • the confirmation signal 408, 416 also includes certain data 255, for example in the form of any pattern.
  • the confirmation signal 408, 416 also includes authentication information 256 ‘.
  • the authentication information 256 ‘could be formed similarly to the event report 242 again via a specific algorithm that accesses the remaining data of the confirmation signal 408, 416, namely the variable variable 254‘ and the data 255 ‘.
  • the authentication information 256 formed in this way completes the confirmation signal 408, 416. It has a fixed length 257 ‘. Encryption then takes place using a key 258 ‘. This encryption 258 ‘could optionally also be dispensed with.
  • the receiving entities for example the higher-level entity 34, the backend 36
  • 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 a correspondingly known algorithm and compared with the received authentication information 256 '. If they match, authenticity is assumed. If the received authentication information 256 ′ is correct, the signal 410 could be used to release the memory 206 be generated. If the authentication information 256 'is not in order, this signal 410 could not be generated, so that the selected events 226 contained in the memory 206 are not (yet) deleted.
  • the further IDS instance 34 also receives a timer interrupt signal 412 cyclically, which is formed similarly to the signal 400 as already described. In response to this interrupt signal 412, the further IDS instance 34 in turn sends an encrypted message, signal 414.
  • This message may contain the event report 242 or a vehicle-related event report (including further event reports) as transmitted via signal 406 in front of the communication adapter 32.
  • the message is encrypted by the further IDS instance 34, in particular by a constantly changing variable 254 'such as a random number 273.
  • the communication adapter 32 has not transmitted an event report 242, because, for example, no new selected event 226 occurred, In turn, a dummy message with the same data format as an event report 242 is used and transmitted in encrypted form to the backend 36 (signal 414).
  • the backend 36 sends a confirmation signal 416 and / or a further message or request to overwrite the events 236 or the like temporarily stored in the buffer memory 206 to the further IDS entity 34.
  • the confirmation signal 416 can be formed as described above.
  • the event manager 30 After receiving the signal 410 relating to the event release, the event manager 30 selects further selected events 226.3 and 226.4. The further process can be seen in FIG. 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 overwriting the selected event 226.6, but rather merely overwriting those selected events 226.3, 226.4, 226.5 that were already transmitted in the context of the last event report 242.
  • a timer interrupt also occurs in the further IDS instance 34 (signal 432), as already described.
  • This causes the further IDS entity 34 to transmit the event report 242 newly received in signal 426 in encrypted form to the backend 36, signal 434.
  • the receipt of the corresponding message 434 is acknowledged by the backend 36 with a corresponding confirmation signal 436, which is sent to the further IDS entity 34 is sent.
  • the confirmation signal 436 could be formed like the confirmation signal 408 or 416.
  • the further sequence is shown in FIG. Another timer interrupt occurs for the communication adapter 32, signal 440.
  • the communication adapter 32 then sends a request 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 sends to overwrite or release the already transmitted events 226.6, 450.
  • the further IDS instance 34 again receives a timer interrupt, signal 452.
  • the encrypted event report 242 is then transmitted to the backend 36 in a vehicle-related manner together with further event reports from further IDS systems.
  • the backend 36 sends a confirmation signal and / or a request to release or overwrite etc., signal 456, to the further IDS instance (s) 34.
  • no new selected event 226 has occurred between the sending of the last event report 242 and the new occurrence of a timer interrupt (signal 460).
  • the communication adapter 32 After receiving the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 for a new event report 242 to the event manager 30.
  • 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.
  • the receipt is confirmed by the further IDS instance 34 confirmed, signal 468.
  • the communication adapter 32 again sends a request signal to the event manager 30 to overwrite the last selected events 226, signal 470. This 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.
  • the event summary from the communication adapter 32 is also encrypted by a new variable variable 254 such as a random number and transmitted to further IDS instances 34, signal 486.
  • the further IDS instance 34 sends the event summary, particularly preferably encrypted, to the backend 36.
  • the event summary particularly preferably encrypted
  • 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 via a new variable 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 as part of the last one Event report 242 transmitted events 220 to release or overwrite.
  • the described methods can be implemented in a processing unit, computer or controller, in particular in a control unit of a vehicle 18.
  • the method can likewise be created in the context of a computer program that is set up to carry out the method when it is carried out on a computer.
  • the computer program can be stored on a machine-readable storage medium.
  • the program can be uploaded as software "over-the-air" wirelessly or via diagnostic interfaces using cables.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
PCT/EP2021/056573 2020-03-28 2021-03-15 Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug WO2021197828A1 (de)

Priority Applications (2)

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

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=75111568

Family Applications (1)

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

Country Status (4)

Country Link
JP (1) JP7441326B2 (ja)
CN (1) CN115398428A (ja)
DE (1) DE102020204052A1 (ja)
WO (1) WO2021197828A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7219239B1 (en) * 2002-12-02 2007-05-15 Arcsight, Inc. Method for batching events for transmission by software agent
US20110196964A1 (en) * 2008-10-14 2011-08-11 Srikanth Natarajan Managing event traffic in a network system
US9027120B1 (en) * 2003-10-10 2015-05-05 Hewlett-Packard Development Company, L.P. Hierarchical architecture in a network security system
US20180077183A1 (en) * 2016-09-14 2018-03-15 Microsoft Technology Licensing, Llc. Modular event pipeline
US20190073253A1 (en) * 2016-06-14 2019-03-07 Amazon Technologies, Inc. Throttling system and method
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5240013B2 (ja) 2009-04-01 2013-07-17 日本電気株式会社 ネットワーク装置、ネットワーク装置の制御方法、及びプログラム
CN110610092B (zh) 2014-04-17 2023-06-06 松下电器（美国）知识产权公司 车载网络系统、网关装置以及不正常检测方法
CN115361212A (zh) 2017-12-01 2022-11-18 松下电器（美国）知识产权公司 不正当检测服务器及其所执行的方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7219239B1 (en) * 2002-12-02 2007-05-15 Arcsight, Inc. Method for batching events for transmission by software agent
US9027120B1 (en) * 2003-10-10 2015-05-05 Hewlett-Packard Development Company, L.P. Hierarchical architecture in a network security system
US20110196964A1 (en) * 2008-10-14 2011-08-11 Srikanth Natarajan Managing event traffic in a network system
US20190073253A1 (en) * 2016-06-14 2019-03-07 Amazon Technologies, Inc. Throttling system and method
US20180077183A1 (en) * 2016-09-14 2018-03-15 Microsoft Technology Licensing, Llc. Modular event pipeline
DE102018209407A1 (de) 2018-06-13 2019-12-19 Robert Bosch Gmbh Verfahren und Vorrichtung zur Behandlung einer Anomalie in einem Kommunikationsnetzwerk

Also Published As

Publication number Publication date
JP2023519911A (ja) 2023-05-15
CN115398428A (zh) 2022-11-25
JP7441326B2 (ja) 2024-02-29
DE102020204052A1 (de) 2021-09-30

Similar Documents

Publication Publication Date Title
EP3278529B1 (de) Angriffserkennungsverfahren, angriffserkennungsvorrichtung und bussystem für ein kraftfahrzeug
EP2324595B1 (de) Verfahren zur datenübertragung zwischen netzwerkknoten
DE102018122152A1 (de) Systeme und verfahren zur eindringungserkennung in das netzwerk im fahrzeug
EP3136285B1 (de) Verfahren und speichermodul für sicherheitsgeschützte schreibvorgänge und/oder lesevorgänge auf dem speichermodul
EP3625950B1 (de) Datenverarbeitungseinrichtung, gesamtvorrichtung und verfahren zum betrieb einer datenverarbeitungseinrichtung oder gesamtvorrichtung
DE102020101358A1 (de) Selektive Echtzeit-Kryptographie in einem Fahrzeugkommunikationsnetz
DE102014224694A1 (de) Netzwerkgerät und Netzwerksystem
DE102015211451A1 (de) Verfahren zu einem Manipulationsschutz von über ein Bussystem zwischen Systemkomponenten zu übertragenden Nutzdatenpaketen
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
WO2019129417A1 (de) Verfahren und system zum überprüfen einer integrität einer kommunikation
DE112004002544B4 (de) Verfahren, System und Programm zur Identifizierung von Datenüberlauf
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
WO2021197828A1 (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
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
WO2021197822A1 (de) Verfahren zur behandlung einer anomalie von daten, insbesondere bei einem kraftfahrzeug
EP3682317B1 (de) Verfahren zum betrieb einer berührungssensitiven, flächigen eingabevorrichtung einer gesamtvorrichtung und gesamtvorrichtung
EP3713187A1 (de) Verfahren zur übertragung von datenpaketen
WO2020083960A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zur übertragung von daten mit manipulationsschutz in einem seriellen bussystem

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: 21713340

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022558499

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21713340

Country of ref document: EP

Kind code of ref document: A1