Controller area network intrusion detection system and operating method thereof

Abstract

To provide: an intrusion detection system (IDS) that detects intrusion of a controller area network (CAN); and an operating method thereof.SOLUTION: An operating method includes the steps of: receiving, by a CAN packet mirroring system, a CAN message from a CAN driver existing in an AUTomotive Open System ARchitecture (AUTOSAR) protocol data unit (PDU) router (PduR) region of an AUTOSAR layer; storing the received CAN message in a plurality of storage regions of a memory; a reading, by an IDS core, data copied by the CAN packet mirroring system and transmitting the copied data to a detection engine base; and separately managing, by the IDS core of the IDS core layer, a first memory region for storing a policy binary file which is policy rules of the IDS and a second memory region for storing a buffering table for buffering and storing the CAN message.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates to intrusion detection systems (IDS), and more particularly to an intrusion detection system for detecting intrusions in a controller area network (CAN) and a method of operating the same. [Background technology]

[0002] As the electronicization of vehicle parts progresses rapidly, the types and number of electronic devices installed in vehicles, such as ECUs (electronic control units), are increasing significantly. Electronic devices are largely classified into power train control systems, body control systems, chassis control systems, vehicle networks, multimedia systems, etc. Here, power train control systems include engine control systems and automatic transmission control systems. Body control systems include body electrical equipment control systems, convenience device control systems, lamp control systems, etc. Chassis control systems include steering control systems, brake control systems, suspension control systems, etc.

[0003] Vehicle networks include CAN (controller area network), FlexRay-based networks, MOST (media oriented system transport)-based networks, etc. Multimedia systems include navigation systems, telematics systems, infotainment systems, etc.

[0004] These systems and the electronic devices installed in each system are connected through a vehicle network, and the vehicle network is required to support the functions of each electronic device. CAN can support a maximum transmission speed of 1Mbps and can support automatic retransmission of collision frames and error detection based on CRC (cycle redundancy check).

[0005] Recently, in-vehicle CAN has been increasingly used in automotive hacking techniques, where attackers manipulate any ECU connected to the CAN, the communication network that connects the components inside the car, to stop the vehicle, open and close the doors and windows, or control the radio.

[0006] As such, there is a demand for a method to effectively detect intrusions by external attackers into CAN-based platforms, especially CAN-based platforms installed in automobiles. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Patent No. 7316609 Summary of the Invention [Problem to be solved by the invention]

[0008] The present disclosure has been made in response to the above-mentioned requirements of the prior art, and an object of the present disclosure is to provide an intrusion detection system and an operating method thereof for detecting an intrusion by an attacker through a controller area network (CAN) in a vehicle-based platform based on the CAN. [Means for solving the problem]

[0009] According to one aspect of the present disclosure for solving the above technical problem, there is provided a method for operating a controller area network (CAN) intrusion detection system (IDS), comprising: an ECU (electronic control unit) layer or an AUTOSAR layer mounted on hardware; a real time environment (RTE) or interface connecting components of the AUTOSAR layer with an application (App); and an IDS core layer and an IDS detect layer mounted on the application, the method comprising: detecting an intrusion detection signal from an AUTOSAR layer by a CAN packet mirroring system in the AUTOSAR layer; The method includes the steps of: receiving a CAN message from a CAN driver present in a PduR router (PduR) area; storing the received CAN message in multiple storage areas of a memory by the CAN packet mirroring system; reading the data copied by the CAN packet mirroring system by an IDS core of the IDS core layer and transmitting it to a detection engine base of the IDS core; and separately managing, by an IDS core of the IDS core layer, a first memory area for storing a policy binary file of an IDS policy rule and a second memory area for storing a buffering table for buffering and storing the CAN message.

[0010] The operating method may further include copying and storing CAN standard message data stored in a first shared memory area of ​​the memory to a first engine memory area by the CAN packet mirroring system, and copying and storing CAN FD (flexible data) message data stored in a second shared memory area of ​​the memory to a second engine memory area.

[0011] The operating method may further include copying and bringing the CAN data from the shared memory to the engine memory by the IDS core before the CAN data is transmitted to the detection engine base, where the CAN message brought to the engine memory may be stored in a buffering table.

[0012] The operating method may further include searching a lookup table of a policy binary file through bus information and a CAN ID (ID: identification) of the previously retrieved CAN message by the IDS core to store the CAN message in a buffering table.

[0013] The operating method may further include storing the CAN message in a specific storage area of ​​the memory according to buffering table type information of the CAN message previously searched by the IDS core, where the buffering table type information may include buffer type information and buffer index information.

[0014] The operating method may further include a step of processing the CAN message by the IDS core in at least one of the following cases: when there is no matching information after searching the lookup table; when buffering is not required for the CAN message; and when processing must be performed for a buffered case.

[0015] The operating method may further include searching for a detection policy in a lookup table through a binary search by the IDS core based on the bus and CAN ID of the CAN message retrieved from the engine memory.

[0016] The operating method may further include the steps of storing the CAN message in an unknown message buffer of a buffering table in memory through unknown message buffering table information by the IDS core when there is no matching policy in the lookup table; incrementing a head value of the stored message by the IDS core by one; and transmitting the address of the buffering table of the currently copied item, an address for the detection policy rule, and information regarding the buffer type and buffer index to the detection engine base via an interface by the IDS core.

[0017] The operating method may further include the steps of storing the corresponding CAN message in a buffer table of a memory based on buffering table type information of the corresponding CAN message when a matching detection policy is found in the lookup table by the IDS core; incrementing a head value of the stored message by one by the IDS core; and transmitting the address of the buffering table of the currently copied item, an address for the detection policy rule, and information regarding the buffer type and buffer index to the detection engine base via an interface by the IDS core.

[0018] The operating method may further include the steps of: when the IDS core searches for a detection policy matching the CAN message in the lookup table, storing the corresponding CAN message in a buffering table in a memory area based on buffering table type information of the corresponding CAN message; determining by the IDS core whether a buffer index of the buffering table type information is 0, null, inactive, or minor; and determining by the IDS core that the corresponding CAN message is a message that does not require buffering.

[0019] The operating method may include a step of transmitting the message address of the currently copied item and address information for the detection policy rule to the detection engine base via an interface without storing the corresponding CAN message in a buffering table by the IDS core.

[0020] A controller area network (CAN) intrusion detection system (IDS) according to an aspect of the present disclosure for solving the technical problem includes an ECU (electronic control unit) layer or an AUTOSAR layer mounted on hardware; a real time environment (RTE) or interface connecting components of the AUTOSAR layer and an application (App); and an IDS core layer and an IDS detect layer mounted on the application. The AUTOSAR layer includes a CAN packet mirroring system. The CAN packet mirroring system receives a CAN message from a CAN driver present in an AUTOSAR PduR (Automatic Programming Unit) area of ​​the AUTOSAR layer, stores the received CAN message in multiple storage areas of a memory, and manages the multiple storage areas separately as a shared memory. Here, the IDS core of the IDS core layer reads the data copied in the CAN packet mirroring system and transmits it to the detection engine base of the IDS core, and manages separately a first memory area that stores a policy binary file of the IDS policy rule and a second memory area that stores a buffering table for buffering and storing the CAN message.

[0021] The CAN packet mirroring system can copy and store CAN standard message data stored in a first shared memory area of ​​the memory in a first engine memory area, and copy and store CAN FD (flexible data) message data stored in a second shared memory area of ​​the memory in a second engine memory area.

[0022] The IDS core may copy the CAN data from the shared memory to the engine memory before the CAN data is transferred to the detection engine base. Here, the CAN message brought to the engine memory may be stored in a buffering table.

[0023] The IDS core can search a lookup table of a policy binary file through the bus information and CAN ID (identification) of the received CAN message to store the CAN message in a buffering table.

[0024] The IDS core can store the CAN message in a specific storage area of ​​the memory based on previously searched buffering table type information of the CAN message, where the buffering table type information can include buffer type information and buffer index information.

[0025] The IDS core can process the CAN message in at least one of the following cases: when there is no matching information after searching the lookup table; when buffering is not required for the CAN message; and when processing must be performed for a buffered case.

[0026] The IDS core searches for a detection policy in a lookup table through a binary search based on the bus and CAN ID of the CAN message retrieved from the engine memory; when there is no matching policy in the lookup table, it stores the CAN message in the unknown message buffer of the buffering table in the memory through unknown message buffering table information; it increments the head value of the stored message by one; and it can transmit the buffering table address of the currently copied item, the address for the detection policy rule, the buffer type and the buffer index information to the detection engine base through an interface.

[0027] The IDS core searches for a detection policy in a lookup table through a binary search based on the bus and CAN ID of the CAN message retrieved from the engine memory; when a matching policy or message is found in the lookup table, it stores the corresponding CAN message in a buffer table in memory through the buffering table type information of the corresponding CAN message; it increments the head value of the stored message by one; and it can transmit the buffering table address of the currently copied item, the address for the detection policy rule, and information on the buffer type and buffer index to the detection engine base through an interface.

[0028] The IDS core searches for a detection policy through a binary search in a lookup table based on the bus and CAN ID of the CAN message retrieved from the engine memory; when a detection policy matching the CAN message is found in the lookup table, it stores the corresponding CAN message in a buffering table in the memory area based on the buffering table type information of the corresponding CAN message; if the buffer index of the buffering table type information is 0, null, inactive, or minor, it determines that the corresponding CAN message is a message that does not require buffering; it does not store the corresponding CAN message in the buffering table, and can transmit the message address of the currently copied item and address information for the detection policy rule to the detection engine base through an interface. Effect of the Invention

[0029] According to the present disclosure, intrusion by an attacker through a controller area network (CAN) in a vehicle based platform can be effectively detected. [Brief description of the drawings]

[0030] [Figure 1] 1 is an exemplary diagram illustrating one embodiment of a controller area network (CAN) to which an intrusion detection system (IDS) of the present disclosure can be applied. [Diagram 2] FIG. 1 is a configuration diagram of a CAN IDS according to a comparative example. [Diagram 3] FIG. 2 is a configuration diagram of a CAN IDS according to an embodiment of the present disclosure. [Figure 4] 4 is a diagram for explaining the operation principle of a CAN packet mirroring system of the CAN IDS of FIG. 3. [Diagram 5]5 is a diagram illustrating the structure and operation principle of an engine memory connected to the CAN packet mirroring system of FIG. 4. [Figure 6] 4 is an exemplary diagram illustrating a CAN message buffering process that can be adopted in the CAN IDS of FIG. 3; [Figure 7] 4 is an exemplary diagram illustrating another buffering process of a CAN message that can be adopted in the CAN IDS of FIG. 3; [Figure 8] 5 is an exemplary diagram illustrating another buffering process of a CAN message that can be adopted in the CAN IDS of FIG. 3. [Figure 9] 4 is an exemplary diagram for explaining a CAN message detection procedure in an IDS detection layer that can be adopted in the CAN IDS of FIG. 3. [Figure 10] 4 is an exemplary diagram for explaining a CAN message deletion procedure in an IDS detection layer that can be adopted in the CAN IDS of FIG. 3. [Figure 11] 10 is an exemplary diagram for explaining yet another CAN message deletion procedure in an IDS detection layer that can be adopted in the CAN IDS of FIG. 3. [Figure 12a] 4 is a flowchart of a process for executing a CAN message detection policy that can be adopted in the CAN IDS of FIG. 3. [Figure 12b] 4 is a flowchart of a process for executing a CAN message detection policy that can be adopted in the CAN IDS of FIG. 3. [Figure 12c] 4 is a flowchart of a process for executing a CAN message detection policy that can be adopted in the CAN IDS of FIG. 3. [Figure 13] 4 is an example diagram of a logging system of the CAN IDS of FIG. 3. [Figure 14] 14 is an example diagram of a message format that can be adopted in the logging system of FIG. 13. [Figure 15] 4 is an exemplary diagram showing a message structure of a detection log buffer that can be used in the CAN IDS of FIG. 3. [Figure 16]4 is an exemplary diagram illustrating a detection log-related operation procedure of the CAN IDS of FIG. 3. [Figure 17] 17 is an exemplary diagram for explaining a gateway operation procedure for the CAN IDS operation procedure of FIG. 16. [Figure 18] 4 is an exemplary diagram showing a message structure of a status log buffer that can be used in the CAN IDS of FIG. 3. [Figure 19] 4 is an exemplary diagram illustrating a status log-related operation procedure of the CAN IDS of FIG. 3. [Figure 20] FIG. 13 is a schematic configuration diagram of a CAN IDS according to another embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] The present invention can be modified in various ways and can have various embodiments, and therefore, a specific embodiment will be illustrated in the drawings and described in detail. However, this is not intended to limit the present invention to a specific embodiment, and it should be understood that the present invention includes all modifications, equivalents, and alternatives within the spirit and technical scope of the present invention.

[0032] Terms such as first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only to distinguish one component from another. For example, a first component may be named a second component and similarly, a second component may be named a first component without departing from the scope of the invention. The term and / or includes a combination of multiple associated listed items or any item of multiple associated listed items.

[0033] In the embodiments of the present application, "at least one of A and B" may mean "at least one of A or B" or "at least one of a combination of one or more of A and B." Also, in the embodiments of the present application, "one or more of A and B" may mean "one or more of A or B" or "one or more of a combination of one or more of A and B."

[0034] When a component is said to be "coupled" or "connected" to another component, it should be understood that it may be directly coupled or connected to the other component, but there may be other components in between. Conversely, when a component is said to be "directly coupled" or "directly connected" to another component, it should be understood that there are no other components in between.

[0035] The terms used in this application are merely used to describe certain embodiments and are not intended to limit the present invention. A singular expression includes a plural expression unless the context clearly indicates otherwise. In this application, the terms "include" or "have" are intended to specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0036] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which the present invention belongs. Terms as defined in commonly used dictionaries should be interpreted to have a meaning consistent with the meaning they have in the context of the relevant art, and should not be interpreted in an idealized or overly formal sense unless expressly defined in this application.

[0037] Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In the description of the present invention, the same reference numerals are used for the same components in the drawings to facilitate overall understanding, and duplicate descriptions of the same components are omitted.

[0038] FIG. 1 is an exemplary diagram illustrating one embodiment of a controller area network (CAN) to which an intrusion detection system (IDS) according to the present disclosure can be applied.

[0039] Referring to Figure 1, CAN is a communication method developed to ensure reliability in vehicle environments where electrical noise is common. CAN has a structure in which multiple controllers are connected in parallel to exchange data. All controllers sharing the communication line act as masters, so they can communicate with each other at any time. In other words, if data is placed on the communication line, any controller can bring in and use the data whenever necessary. The CAN communication module in the controller consists of a microcontroller (MCU) and a CAN transceiver, and exchanges CAN high and CAN low signals through the external CAN bus.

[0040] The controllers are connected through a gateway (190) and at least one of switches 191, 191a, 191b, 192, and 193. Each controller corresponds to one of end nodes 301, 302, 303, 311, 312, 313, 321, 322, and 323. The gateway 190 and each switch may correspond to an end node. Each switch may be referred to as a bridge.

[0041] The gateway 190 constituting the vehicle network may be connected to at least one switch 191, 191a, 191b, 192, 193, and may connect different networks to each other. For example, the gateway 190 may connect between end nodes supporting communication protocols such as controller area network (CAN), FlexRay, media oriented system transport (MOST), local interconnect network (LIN), etc., and switches supporting the Ethernet protocol.

[0042] Each of the switches 191, 191a, 191b, 192, and 193 may be connected to at least one end node 301, 302, 303, 311, 312, 313, 321, 322, and 323. Each of the switches may interconnect the end nodes and control the end nodes connected to it.

[0043] Each of the end nodes 301, 302, 303, 311, 312, 313, 321, 322, and 323 may refer to an electronic control unit (ECU) that controls various devices included in a vehicle. For example, the end nodes 301, 302, 303, 311, 312, 313, 321, 322, and 323 may refer to individual ECUs such as a display device, a navigation device, and an around view monitoring device included in an infotainment device of the vehicle.

[0044] Meanwhile, the end nodes constituting the vehicle network, i.e., the gateway 190, each switch, end node, etc., can be connected in a star topology, bus topology, ring topology, tree topology (see FIG. 1), mesh topology, etc.

[0045] The apparatus and methods according to the following embodiments of the present disclosure may be applied to the network topologies described above, but are not limited thereto, and may be configured to be applied to at least one selected from a variety of network topologies that are already widely known.

[0046] FIG. 2 is a configuration diagram of a CAN IDS according to a comparative example.

[0047] Referring to FIG. 2, the CAN IDS 100 of the comparative example includes an AUTOSAR (AUTomotive Open System ARchitecture) and ECU (electronic control unit) layer 110a, an IDS core layer (130a), and an IDS detect layer (150a).

[0048] Here, the AUTOSAR and ECU layer 110a includes a CAN driver and a CAN packet mirroring system, the IDS core layer 130 includes an IDS-core, and the IDS detection layer 150a includes a detection engine base, a number of policy rules, and a logging system.

[0049] The CAN IDS 100 of the comparative example is applied to a general ECU system. The CAN IDS 100 of the comparative example has a system configuration based on the existing AUTOSAR. Here, the CAN packet mirroring system is included in a Pdu router (PduR) or complex drivers in the communication service layer of basic software (BSW).

[0050] FIG. 3 is a configuration diagram of a CAN IDS according to an embodiment of the present disclosure.

[0051] 3, the CAN IDS may include an ECU (electronic control unit) layer or AUTOSAR layer 110 mounted on hardware (102), a real time environment (RTE) or interface (120) that connects components of the AUTOSAR layer 110 and an application (App, 160) using a virtual functional bus, etc., and an IDS core layer (130) and an IDS detection layer (150) mounted on the application 160. The application 160 may be mounted on a compiler (170) such as a transpiler or a speedy web compiler (SWC).

[0052] Here, the hardware (102) may include a microcontroller (104). The AUTOSAR layer 110 may include a driver layer (111) for device drivers such as a microcontroller abstraction layer (MCAL), an abstraction layer (112) for ECUs, a services layer (113), complex drivers (116), and a CAN packet mirroring system (117). The services layer 113 may include a communication service layer (114) and a Pdu router (PduR, 115).

[0053] The IDS-core layer 130 may also include an IDS-Core (140). In this embodiment, the IDS-Core 140 may be referred to as a detection engine from a microscopic perspective. The IDS-detection layer 150 may also include a detection engine base (152), policy rules (154), and a logging system (156).

[0054] The CAN IDS of the present embodiment includes an IDS core layer 130 and an IDS detection layer 150 having structures and functions different from those of the comparative example. The IDS core layer 130 and the IDS detection layer 150 are configured to detect and process CAN messages according to new detection rules.

[0055] The CAN driver provided in the CAN IDS receives messages from physical CAN devices. The CAN driver initializes the CAN devices and receives data from the CAN bus. The CAN driver can exist across the PduR 115 domain and the composite driver 116 domain of the communication service layer 114 of the service layer 113 of the AUTOSAR hierarchy 110. Such a CAN driver can be referred to as existing in the AUTOSAR PduR domain.

[0056] In addition, the CAN packet mirroring system 117 provided in the CAN IDS copies messages received by the CAN driver to a memory area and performs buffering management to prevent the messages from being lost. The CAN packet mirroring system 117 can perform a function of generating and managing CAN messages and additional metadata. In addition, the CAN packet mirroring system 117 operates in an ECU application program in a system without a classic AUTOSAR hierarchy, but can exist in a basic software (BSW) area in a system based on a typical AUTOSAR platform.

[0057] FIG. 4 is a diagram for explaining the operation principle of the CAN packet mirroring system of the CAN IDS of FIG.

[0058] 4, the CAN packet mirroring system 117 receives a CAN message from a CAN driver 115a present in the AUTOSAR PduR area (S41), and copies and stores the received CAN message in a random access memory (RAM) area of ​​a memory (106) (S43). At this time, the CAN packet mirroring system 117 can store message data in a plurality of storage areas that are called shared memories and are managed separately from each other.

[0059] CAN standard message data (hereinafter also referred to as "first message data") may be stored and managed in a first storage area 104a, and CAN flexible data (FD) message data (hereinafter also referred to as "second message data") may be stored and managed in a second storage area 104b. The first storage area 104a and the second storage area 104b may be referred to as a first shared memory area and a second shared memory area, respectively.

[0060] The space of the memory 106, i.e., the storage area, may be configured in a circular queue structure, and the buffer size of each storage area may be flexibly set differently for each system. For example, a shared memory buffer structure forming the storage area of ​​the memory 106 may include a first buffer (buffer[0]), a second buffer (buffer[1]), a third buffer (buffer[2]), etc., each of which may store CAN data.

[0061] The structure of the CAN data may be stored in the buffer according to the first format of [Table 1] or the second format of [Table 2]. The difference between the first format and the second format may be the size of the message field of the received message. For example, the size of the message field for received CAN message data according to the CAN standard may be 8 bytes, and the size of the message field for received CAN FD message data may be 64 bytes.

[0062] [Table 1]

[0063] [Table 2]

[0064] 1 again, the IDS core 140 of the IDS core layer 130 can perform a function of reading data copied by the CAN packet mirroring system 117 and transmitting it to the detection engine base 152. At this time, the IDS core 140 can separately manage a first memory area for storing a policy binary file of an IDS policy rule (154) and a second memory area for storing a buffering table for buffering and storing CAN messages.

[0065] IDS core 140 may also include another buffer for retrieving CAN data stored in memory 106 by CAN packet mirroring system 117. Such a buffer may be referred to as engine memory.

[0066] FIG. 5 is a diagram for explaining the structure and operation principle of an engine memory connected to the CAN packet mirroring system of FIG.

[0067] 5, the CAN packet mirroring system can copy message data stored in a first storage area 104a and a second storage area 104b, which are called a shared memory and managed separately from each other, to a third storage area 104c and a fourth storage area 104d, which are called engine memories. The third storage area 104c and the fourth storage area 104d can be called a first engine memory area and a second engine memory area, respectively.

[0068] That is, the CAN packet mirroring system can copy and store the CAN standard message data stored in the first shared memory area 104a in the first engine memory area 104c, and copy and store the CAN FD message data stored in the second shared memory area 104b in the second engine memory area 104d.

[0069] Each engine memory may have a circular queue structure similar to the shared memory, and may store CAN data in a structure similar or the same as the shared memory.

[0070] The IDS core (see 140 in FIG. 3) can copy the CAN data from the shared memory to the engine memory before it is transmitted to the detection engine base. The CAN message brought to the engine memory can be stored in a buffering table. At this time, to store the CAN message in the buffering table, the IDS core can search a lookup table of the policy binary file through the bus information and CAN ID (ID: identification) of the brought CAN message. The CAN ID can include a lookup key or correspond to a lookup key.

[0071] The IDS core can store the CAN message in a specific storage area of ​​the RAM 106 based on the previously searched buffering table type information of the CAN message. The buffering table type information can include buffer type information, buffer index information, etc.

[0072] The buffering of the above-mentioned CAN message can be handled in at least one of three ways: when there is no matching information after searching the lookup table, when buffering is not necessary, and when processing must be performed for the buffered case.

[0073] FIG. 6 is an exemplary diagram illustrating a CAN message buffering process that can be adopted in the CAN IDS of FIG.

[0074] Referring to FIG. 6, a case where the CAN message does not match the lookup table of the policy binary during the three buffering processes of the CAN message is illustrated.

[0075] First, the IDS core searches for a detection policy in a lookup table (180) through a binary search based on the bus and CAN ID of the CAN message retrieved from the engine memory (S61). For example, the bus of the CAN message can be represented as BUS(0xFF) and the CAN ID can be represented as CAN ID(0xFF).

[0076] The lookup table 180 can store information for a plurality of lookup keys, a plurality of policy body types, and a plurality of buffering table types. Each lookup key can have a field for storing information for a bus and a field for storing information for an arbitration ID. Each policy body type can have a field for storing information for a policy index. And each buffering table type can have a field for storing information for a buffer index and, optionally, a field for storing a buffer type.

[0077] Messages not found in the lookup table 180 may be stored in a buffering table (182) in the RAM area through the unknown message buffering table information stored first in the lookup table 180 (S63, S65). That is, when there is no matching policy in the lookup table 180, the IDS core may store the CAN message in an unknown message buffer in the buffering table (182) in the RAM area through the unknown message buffering table information (S63, S65). The unknown message buffer may have a head, a tail, and multiple storage areas (see 0 to 4).

[0078] When the message is stored, the IDS core can increment the head value of the stored message by one. Then, the address of the buffering table 182 of the currently copied item, the address for the detection policy rule, the buffer type, and the buffer index information can be transmitted to the detection engine base of the detection engine 160a through an interface 108 such as an API (application programming interface) (S67, S69). The address for the detection policy rule can be simply referred to as a detection policy address, and the buffer index information can include index information of the buffering table 182. In this manner, the IDS core can transmit the information stored in the buffering table 182 to the detection engine 160a. The detection engine 160a can be a type of application (see 160 in FIG. 3).

[0079] FIG. 7 is an exemplary diagram illustrating another buffering process of a CAN message that can be adopted in the CAN IDS of FIG.

[0080] Referring to FIG. 7, a case where the CAN message matches in the policy binary lookup table among three buffering processes of the CAN message is illustrated.

[0081] First, the IDS core searches for a detection policy in a lookup table (180) through a binary search based on the bus and CAN ID of the CAN message retrieved from the engine memory (S71). For example, the bus of the CAN message may be BUS(0xFF) and the CAN ID may be CAN ID(0x3FD).

[0082] If the CAN message is found in the lookup table 180, the IDS core can store the CAN message in a buffering table (182) in the RAM area according to the buffering table type information of the message (S73, S75). The buffering table 182 can include a number of unknown message buffers (UMB). For example, the address of the 98th UMB can be set to Ox2C1, the address of the 99th UMB to 0x2DC, and the address of the 100th UMB to 0x3FD. Each unknown message buffer can have a head, a tail, and a number of storage areas (see 0 to 4).

[0083] When the message is stored, the IDS core can increment the head value of the stored message by 1. Then, the address of the buffering table 182 of the currently copied item, the address for the detection policy rule, and information on the buffer type and buffer index can be transmitted to the detection engine base of the detection engine 160a through the interface 108 such as an API (S77, S79). In this way, the IDS core can transmit the information stored in the buffering table 182 to the detection engine 160a.

[0084] FIG. 8 is an exemplary diagram illustrating another buffering process of a CAN message that can be adopted in the CAN IDS of FIG.

[0085] Referring to FIG. 8, a case where the CAN message matches the policy binary lookup table but does not require buffering is illustrated among the three buffering processes of the CAN message.

[0086] First, the IDS core can search the lookup table 180 using the bus and CAN ID or lookup key of the CAN message retrieved from the engine memory (S81). The search can include searching for the detection policy through a binary search. And, the CAN message can include, for example, BUS(0x2) as information for the bus and CAN ID(0x110) as information for the CAN ID.

[0087] When a CAN message is found in the lookup table 180, the IDS core can store the corresponding CAN message in a buffering table in the RAM area based on the buffering table type information of the corresponding message (S83).

[0088] At this time, if the buffer index information of the buffering table type information is 0, the IDS core can determine or decide that the corresponding CAN message is a message that does not require buffering. A message that does not require buffering is not stored in the buffering table, and the copied message including the message address of the currently copied item and address information for the detection policy rule can be transmitted to the detection engine 160a through the interface 108 such as an API (S85).

[0089] The detection engine base (see 152 in FIG. 3) can detect or delete buffered messages through the information transmitted from the IDS core. The detection engine including the detection engine base can search the lookup table through the transmitted information to detect or delete messages.

[0090] FIG. 9 is an exemplary diagram for explaining a CAN message detection procedure in an IDS detection layer that can be adopted in the CAN IDS of FIG.

[0091] Referring to FIG. 9, a detection engine 160a can detect CAN messages for a policy binary lookup table.

[0092] Specifically, the detection engine 160a can detect CAN messages through information in a buffering table (182) of the CAN messages delivered from the IDS core. When buffer index and buffer type information is delivered to the interface 108 including the API, the buffering table 182 can be queried one by one starting from the latest message based on head and tail information of the buffering table.

[0093] For example, the buffering table 182 has a specific identifier (e.g., buf-5-rec-num), and when buffering table information, such as a buffer type (e.g., 00) and a buffer index (e.g., 100), is transmitted from the detection engine 160a to the interface 108 (S92), the address where the latest CAN message is stored in the buffering table 182 can be accessed through the head and tail information of the buffering table 182.

[0094] Here, the latest CAN messages may be CAN messages stored sequentially in storage area addresses (0, 1, 2) of buffer index 100 of address 0x3FD, and the latest CAN message among them may be the CAN message stored in buffer address (2) of buffer index 100 of the 0x3FD sequence.

[0095] FIG. 10 is an exemplary diagram for explaining a CAN message deletion procedure in an IDS detection layer that can be adopted in the CAN IDS of FIG.

[0096] Referring to FIG. 10, the detection engine 160a can delete the CAN message from a lookup table of a policy binary.

[0097] Specifically, the detection engine 160a can delete CAN messages based on information in a buffering table (182) of the CAN message delivered from the IDS core. When buffer index and buffer type information is delivered from the detection engine 160a through an interface 108 including an API, the buffering table 182 can move to older messages in the buffering table based on the head and tail information and delete the older messages one by one.

[0098] For example, the buffering table 182 has a specific identifier (e.g., buf-5-rec-num), and when the detection engine 160a receives buffering table information and the number of messages to be deleted through the interface 108 (S104), it can move to the old message address of the buffering table 182 through the head and tail information of the buffering table 182 and delete the old CAN messages one by one. Here, the buffering table information includes a buffer type (e.g., 00) and a buffer index (e.g., 100), and the number of messages to be deleted can be specified by a number such as 2.

[0099] Here, the old CAN messages may be CAN messages stored sequentially in storage area addresses (0, 1, 2) of buffer index 100 of address 0x3FD, and the oldest CAN message among them may be the CAN message stored in buffer address (0) of buffer index 100 of the 0x3FD sequence.

[0100] FIG. 11 is an exemplary diagram for explaining yet another CAN message deletion procedure in an IDS detection layer that can be adopted in the CAN IDS of FIG.

[0101] Referring to FIG. 11, the detection engine 160a can delete all CAN messages in a lookup table of a policy binary.

[0102] Specifically, the detection engine 160a can delete all CAN messages in the buffering table based on the information in the buffering table of the CAN message delivered from the IDS core. When a request to delete all messages is delivered from the detection engine 160a to the interface 108 including the API (S112), the buffering tables 182a and 182b can delete the entire message from the start position of the buffering tables 182a and 182b in response to the request to delete all messages delivered through the interface 108, and initialize the head information and tail information (S114, S116).

[0103] The detection engine retrieves CAN messages from the buffering table and detects each message based on the message detection policy rules in the policy body of the policy binary stored in memory such as flash memory through the policy index information transmitted from the IDS core. The detection policy for CAN messages can include a detection policy order in which BUS detection, message detection, signal detection, and message interval detection (e.g., every second) are processed in the listed order. Such detection policies for each CAN message are independent, and whether or not they are activated can be determined depending on the detection policy settings.

[0104] 12a to 12c are flowcharts showing a process for executing a CAN message detection policy that can be adopted in the CAN IDS of FIG.

[0105] Referring to Fig. 12a, when the detection engine starts detection according to a detection policy for each CAN message, it can first initialize the detection end (DE) (S121). According to DE initialize (DE initialize, S121), default settings for the bus, arbitration ID for bus arbitration, raw message, policy header, policy index, buffering index, etc. can be initialized. If DE initialization (S121) is not performed normally, the current detection process can be terminated according to a pre-set procedure.

[0106] Next, the detection engine can determine whether a bus_detect flag is on or off (S122). If the bus_detect flag is off, the detection engine can proceed to a detection end state.

[0107] If the bus detect flag is on, the detection engine can determine whether the bus_load_detect flag is on or off (S123).

[0108] If the bus load detection flag is on, the detection engine can determine whether the corresponding bus load detection flag is an invalid bus load (S123a). If the bus load detection flag is an invalid bus load, the detection engine can make a detection log (S123b). On the other hand, if the bus load detection flag is not an invalid bus load, the detection engine can proceed to the step where the bus load detection flag is off.

[0109] If the bus load detection flag is off, the detection engine may determine whether a message header exists (S124). If the message header does not exist or if the message header is null, the detection engine may determine whether an unknown CAN ID detection flag (unknown_canid_detect flag) is on or off (S124a). If the unknown CAN ID detection flag is on, the detection engine may generate a detection log (S124b). Meanwhile, the detection engine may progress the current state of the detection process to the detection end stage after the unknown CAN ID detection flag is off or the detection log is generated.

[0110] The above steps (S123, S123a, S123b, S124, S124a, S124b) may correspond to a bus detection procedure.

[0111] On the other hand, if a message header exists (Yes in S124), the detection engine can determine whether the data length code (DLC) is correctly defined (S125). If it determines that the DLC is incorrect, the detection engine can determine whether the DLC detection flag (dlc_detect flag) is on or off (S125a). If the DLC detection flag is on, the detection engine can generate a detection log (S125b) and end the current detection process. On the other hand, if the DLC detection flag is off, the current state of the detection process can proceed to a stage where the DLC is determined to be correct, regardless of the DLC.

[0112] The above steps (S125, S125a) may correspond to a message detection procedure.

[0113] Referring to FIG. 12b, the detection engine can determine in parallel or selectively whether a constraint is available (constraint enabled, S126a), whether a cyclic redundancy check (CRC) is available (CRC enabled, S126b), whether a checksum is available (checksum enabled, S126c), whether a counter is available (counter enabled, S126d), whether an enumeration (enum enabled, S126e), whether overflow is available (overflow enabled, S126f), whether underflow is available (underflow enabled, S126g), and whether a custom rule is available (custom rule enabled, S126h) for a CAN message placed on the CAN bus.

[0114] The detection engine may then execute a constraint detection logic (S127a) if a constraint is available, execute a CRC calculate logic (S127b) if a CRC is available, execute a checksum calculate logic (S127c) if a checksum is available, compare counter patterns (S127d) if a counter is available, compare enumeration values ​​(S127e) if an enumeration is available, test overflow value (S127f) if overflow is available, test underflow value (S127g) if underflow is available, and test custom condition (S127h) if custom rule is available.

[0115] Next, as shown in Figure 12c, the detection engine can determine what has been detected (something detected, S129). If it determines that nothing has been detected, the detection engine can determine whether there are still signals to be detected (are there still signals to be detected, S129a), and if there are still signals being detected, it can return to the previous steps (S126a-S126h) to repeat the signal detection process for all signals.

[0116] On the other hand, if something has been detected, the detection engine can generate a detection log (S130), and if no signal is being detected, the detection engine can proceed with the state of the current detection process after generating the detection log (S130).

[0117] The above-mentioned detection steps (S126a to S126h, S127a to S127h, S129, S129a, S130) are for a signal detection process, and the signal detection results by the detection engine can be placed on the CAN bus.

[0118] Continuing to refer to FIG. 12c, the detection engine may determine whether the interval flag (interval_flag) is on or off (S131). If the interval flag is on, the detection engine may determine whether the interval is correct (interval correct, S131a). If the interval is incorrect, the detection engine may determine whether the current message is invalid (Is current message is invalid, S131b). If the current message is invalid, the detection engine may create a detection log (make detection log, S131c).

[0119] On the other hand, in each case where a detection log is generated because the period flag is off, the period value of the period flag is correct, or the current message is not invalid, i.e., the old message is abnormal, or the current message is invalid, the detection engine can operate as if detection of one message has been completed.

[0120] The above steps (S131, S131a, S131b, and S131c) may correspond to message interval detection or simply interval detection.

[0121] FIG. 13 is a diagram illustrating an example of a logging system of the CAN IDS of FIG.

[0122] 13, the logging system can manage and record detection logs received from an IDS core, a detection engine, and policy rules, and can transmit the recorded logs to an external system such as a cloud server.

[0123] The logging system can transmit detection log records of CAN messages in a vehicle using a data identifier (DID) of the unified diagnostic service (UDS) protocol to deliver log messages to an external system. For this purpose, the logging system can be implemented to share a shared memory address between a first node (Node#1) and a second node (Node#2).

[0124] Here, the memory 106a may include a semiconductor memory such as a static random access memory (SRAM). A detection log record may be stored in a predetermined size, for example, 104 bytes. The memory 106a may store a read position (read pos), a write position (write pos), and a status log of a predetermined size (for example, 48 bytes).

[0125] The first node may start an IDS logging feature (107) and update the read position upon anomaly detection (update read pos) and update the write position (update write pos) if the buffer is overflowed (update write pos). The updated records may be stored in the read or write position of memory 106a. The first node may also store a status log in the status log of memory 106a at a period of one minute.

[0126] The second node starts the gateway (GW) UDS feature 109 and polls the read and write locations of the memory 106a at 100 millisecond intervals, thereby obtaining four pieces of detection log data. The second node can also read the status log at 10 minute intervals and store its own status in the status log.

[0127] The logging system described above may correspond to the IDS logging feature 107 of the first node and may be configured to utilize the gateway GW of the second node to provide log messages containing detection log information to external systems.

[0128] The logging system described above operates when an abnormal situation is detected on the CAN bus by an IDS, i.e., a detection engine. The generated log message can be transmitted to an external system through the gateway's UDS protocol. The logging system can have a shared memory address that has been previously shared through the message transmission function using the UDS protocol.

[0129] FIG. 14 is an example diagram of a message format that can be adopted in the logging system of FIG.

[0130] Referring to FIG. 14, message formats that can be employed by the logging system can include message formats that utilize the UDS protocol.

[0131] The message format may consist of a buffer header, a detection log, and a status log.

[0132] The buffer header has a size of 1 byte and can include a head and a tail. The head and tail can each have a size of 4 bits, but are not limited to this. That is, the buffer header can be configured with a write position corresponding to the header and a read position corresponding to the tail. The read position can be managed by the second node, and the write position can be managed by the first node.

[0133] The detection log has a size of 1040 bytes and can contain 10 buffers of 104 bytes each (buffer[0] to buffer[9]), but is not limited to this.

[0134] When a detection log occurs, the write position of the buffer header is read to find the detection log position to record, then the message is saved at the corresponding position and the read position is updated to the detection log position of the next position. The status log can record the current status of the IDS or detection engine every minute. The status log is 48 bytes in size and can record status information (status info) of the IDS or detection engine.

[0135] In the above case, the second node can check every 100 ms whether there are detection logs to transmit at the write or read position of the buffer header of the shared memory. If there are detection logs to transmit, the second node can determine the number of detection logs to transmit and transmit the corresponding detection logs to an external system using the UDS protocol.

[0136] In addition, the second node can read the status log and transmit it to the UDS at the request of a UDS request event or every 10 minutes. The time can be modified according to customer requirements, and the gateway status value can be transmitted regardless of the presence or absence of an IDS attack.

[0137] FIG. 15 is an example diagram showing a message structure of a detection log buffer that can be used in the CAN IDS of FIG.

[0138] 15, the message structure of the detection log for the detection log buffer includes a 1-byte log type. The log type is composed of a 1-bit type and a 7-bit log size, where the type identifies the log type and the log size indicates the overall size including the log type. The log type of the detection log can be set to 0, for example.

[0139] In addition, the message structure of the detection log is composed of a 1-byte CAN bus number indicating the CAN bus number where the abnormality was detected, a 1-byte violation rule ID indicating the violation rule number, a 2-byte signal start bit indicating the signal start position of the message in a numeric form, a 2-byte signal length indicating the signal length of the CAN message in a numeric form, a 1-byte raw message length indicating the signal length of the CAN message in a numeric form, a 4-byte CAN ID of the CAN message, a 4-byte detection time indicating the time when the abnormality was detected in a base number that can be converted to year, month, day, hour, minute, and second, an 8-byte detection reason indicating the content of the abnormality detection in a numeric form, a 2-byte duplication number indicating the number of times the log was duplicated in a numeric form, a 14-byte reserved field indicating the reserved space for adding additional required information that can be initialized to 0x0 by default, and a 64-byte raw message body indicating the entire data of the CAN message. It can contain fields consisting of:

[0140] FIG. 16 is an example diagram for explaining a detection log-related operation procedure of the CAN IDS of FIG.

[0141] Referring to FIG. 16, when an anomaly detection message occurs in the CAN IDS 160b, the detection engine records the anomaly detection message in a detection log buffer in a buffer area of ​​a corresponding memory by referring to a write value in the buffer header.

[0142] Specifically, if an anomaly detection message occurs, the CAN IDS 160b may record a first detection log (Detection log #1) at the read position of the buffer header (S162). When the read position is buffer[0], the write position may be set to buffer[1].

[0143] Next, if an anomaly detection message occurs, the CAN IDS 160b may record a second detection log (Detection log #2) at the read position of the buffer header (S164). At this time, the read position may be maintained at buffer[0], and the write position may be set to buffer[2], which is the next buffer position after the buffer position where the previous message was recorded.

[0144] Next, if an anomaly detection message occurs, the CAN IDS 160b may record a third detection log (Detection log #3) at the read position of the buffer header (S166). At this time, the read position may be maintained at buffer[0], and the write position may be set to buffer[3], which is the next buffer position after the buffer position where the previous message was recorded.

[0145] Meanwhile, the gateway 190 must record the DID data transmission status, and since the gateway cannot make a duplicate request for a DID that has already been read by an external system, an appropriate DID data transmission procedure is required for the gateway 190.

[0146] FIG. 17 is an example diagram for explaining a gateway operation procedure for the CAN IDS operation procedure of FIG.

[0147] Referring to FIG. 17, the gateway 190 may first check the buffer count by comparing the read value and the write value in the buffer header or through the read value and the write value (S171).

[0148] Next, the gateway 190 can include the address of the buffer counted by the difference between the read value and the write value in the data extraction request signal and transmit it to the external system 200 (S172). For example, if the counted buffer address is 3, the gateway 190 can transmit information on the three log data to be transmitted to the external system 200. In this embodiment, the gateway 190 is illustrated as requesting data extraction with up to four DID numbers, but is not limited thereto.

[0149] The gateway 190 can also perform exception handling for the OTA (over the air) DIAG and generate a request message to read the DIDs of the three log data, and can transmit an exception handling related message for the remote DIAG to the external system 200 (S173).

[0150] At this time, the external system 200 may transmit a UDS DID read request message to the gateway 190 in response to the request transmitted from the gateway 190 (S174). That is, the gateway 190 may receive a UDS DID read request message corresponding to the request previously transmitted from the external system 200.

[0151] Next, upon receiving the UDS DID read request message, the gateway 190 may read buffer data referring to the read value of the buffer header and transmit the read data to the external system 200 (S175). For example, the gateway 190 may read first log data (0 log data or log data #0) from the buffer upon receiving the UDS DID read request message and provide the first log data to the external system 200 as a response to the UDS DID read request message.

[0152] If the external system 200 receives a message from the gateway 190, it can transmit a success message to the gateway 190 (S176). The gateway 190 that receives the success message can add 1 to the read value. That is, the gateway 190 can update the read position of the buffer header by receiving the success message.

[0153] Meanwhile, a status log including version information of the CAN IDS distributed to the vehicle and system resource usage information is configured to record data in an assigned address area. At this time, the gateway 190 can provide one DID storage space in the status log buffer.

[0154] FIG. 18 is an example diagram showing a message structure of a status log buffer that can be used in the CAN IDS of FIG.

[0155] Referring to Figure 18, the message structure of the status log for the status log buffer is one DID storage space and can be composed of multiple fields. First, the message structure of the status log can include a 1-byte log type. The log type is composed of a 1-bit type and a 7-bit log size, where the type distinguishes the log type and the log size can indicate the entire size including the log type. The log type of the status log can be set to 0, for example.

[0156] Additionally, the message structure of the status log may contain a 2-byte sequence number that indicates the number of the status message that occurred sequentially. The sequence number is incremented when writing a status message, and may be initialized when the gateway has a previously saved sequence number.

[0157] The status log message structure may also include a 4-byte memory usage that indicates the RAM memory being used by the CAN IDS. The unit of memory usage may be, but is not limited to, a percentage (%).

[0158] The status log message structure may also include a 4-byte flash usage that indicates the amount of flash memory the IDS is using to store policy. The flash usage may be in percent (%) of the policy file size, and may use the most significant 4 bytes of the policy binary file.

[0159] In addition, the message structure of the status log can include a 6-byte policy version that indicates policy version information. The policy version can include major, minor, release information, etc. For example, major can be indicated by 1 and minor by 0, and release information can be indicated by 1 for primary, 2 for secondary, etc.

[0160] In addition, the message structure of the status log can include a 6-byte IDS firmware version that displays IDS firmware version information. The IDS firmware version can include major, minor, and release information. For example, major can be displayed as 1 and minor as 0, and release information can be displayed as 1 for primary, 2 for secondary, etc.

[0161] Additionally, the status log message structure may be initialized with 0x0 as a base or default and may contain 25 reserved bytes indicating reserved space for additional required information.

[0162] The above-mentioned status log can be recorded in the status log buffer by overwriting every minute.

[0163] FIG. 19 is an example diagram for explaining a status log-related operation procedure of the CAN IDS of FIG.

[0164] 19, the CAN IDS 160b or a detection engine of the CAN IDS 160b may periodically record a status log in a status info buffer 192. The size of the status information buffer 192 may be, but is not limited to, 48 bytes.

[0165] As an example, the CAN IDS 160b may write a first status log (status log #0) to the status information buffer 192 (S190). Then, at intervals of 1 minute (1Min), the CAN IDS 160b may sequentially write a second status log (status log #1), a third status log (status log #2), and an n-th status log (status log #n) to the status information buffer 192 (S191, S192, S19n). n may be any natural number equal to or greater than 4.

[0166] FIG. 20 is a schematic configuration diagram of a CAN IDS according to another embodiment of the present disclosure.

[0167] 20, the CAN IDS 2000 may include at least one processor (2010), a memory (2020), and a transceiver (2060) that is connected to a network to perform communication. The CAN IDS 2000 may further include a storage device (2030), an input interface device (2040), an output interface device (2050), etc. Each component included in the CAN IDS 2000 may be connected by a bus to perform communication.

[0168] The processor 2010 may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed.

[0169] Each of the memory 2020 and the storage device 2030 may be composed of at least one of a volatile storage medium and a non-volatile storage medium, for example, the memory 2020 may be composed of at least one of a read only memory (ROM) and a random access memory (RAM).

[0170] Additionally, the processor 2010 may execute program commands stored in at least one of the memory 2020 and the storage device 2030. The program commands may include at least one instruction, and the at least one instruction may be included in a software module or program.

[0171] The input interface device 2040 may include at least one selected from input means such as a keyboard, a microphone, a touchpad, a touch screen, etc., and an input signal processing unit that maps or processes a signal input through the at least one input means with a pre-stored command.

[0172] The output interface device 2050 may include an output signal processing unit that maps or processes a signal output under the control of the processor 2010 in a pre-stored signal form or level, and at least one output means that outputs a signal or information in the form of vibration, light, etc. according to a signal from the output signal processing unit. The at least one output means may include at least one selected from output means such as a speaker, a display device, a printer, an optical output device, a vibration output device, etc.

[0173] The transceiver device 2060 may include communication interfaces or sub-communication systems for short-range wireless networks or cable connections, communication with satellites, wired or wireless communication with general-purpose base stations, and connections to mobile edge core networks or core networks via ideal backhaul links or non-ideal backhaul links.

[0174] The methods according to the present invention may be embodied in the form of program instructions that can be executed by various computer means and recorded on a computer readable medium. The computer readable medium may include, alone or in combination with the program instructions, data files, data structures, and the like. The program instructions recorded on the computer readable medium may be those specially designed and constructed for the present invention, or they may be of the kind commonly known and available to those skilled in the art of computer software.

[0175] Examples of computer readable media include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include high level language codes that may be executed by a computer using an interpreter, as well as machine code, such as produced by a compiler. The aforementioned hardware devices may be configured to operate with at least one software module to perform the operations of the present invention, and vice versa.

[0176] Although some aspects of the invention have been described in the context of an apparatus, it may also be presented as a corresponding method description, where the blocks or apparatus correspond to method steps or features of the method steps. Similarly, aspects described in the context of a method may also be presented as corresponding blocks or items or features of the corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or electronic circuitry. In some embodiments, at least one or more of the most significant method steps may be performed by such an apparatus.

[0177] In some embodiments, a programmable logic device, such as a field programmable gate array, may be used to perform some or all of the functionality of the methods described herein. In some embodiments, a field programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

[0178] Although the present invention has been described with reference to the embodiments, it will be understood that those skilled in the art can make various modifications and variations of the present invention without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. A method for operating an intrusion detection system (IDS) in a controller area network (CAN), comprising: an electronic control unit (ECU) layer or an AUTOSAR layer mounted on hardware; a real time environment (RTE) or an interface connecting components of the AUTOSAR layer and an application (App); and an IDS core layer and an IDS detect layer mounted on the application, comprising: receiving a CAN message from a CAN driver present in an AUTOSAR Pdu Router (PduR) area of ​​the AUTOSAR layer by a CAN packet mirroring system of the AUTOSAR layer; storing the received CAN messages in a plurality of storage areas of a memory by the CAN packet mirroring system; reading the copied data in the CAN packet mirroring system by an IDS core of the IDS core hierarchy and transmitting the data to a detection engine base of the IDS core; and a first memory area for storing a policy binary file of an IDS policy rule and a second memory area for storing a buffering table for buffering and storing the CAN message, the first memory area being managed separately by an IDS core of the IDS core layer.

2. 2. The method of claim 1, further comprising copying and storing CAN standard message data stored in a first shared memory area of ​​the memory to a first engine memory area by the CAN packet mirroring system, and copying and storing CAN flexible data (FD) message data stored in a second shared memory area of ​​the memory to a second engine memory area by the CAN packet mirroring system.

3. 3. The method of claim 2, further comprising the step of copying and bringing the CAN data from the shared memory to the engine memory by the IDS core before the CAN data is transmitted to the detection engine base, wherein the CAN message brought to the engine memory is stored in a buffering table.

4. 4. The method of claim 3, further comprising searching a lookup table of a policy binary file through bus information and a CAN ID (ID: identification) of the previously retrieved CAN message to store the CAN message in a buffering table by the IDS core.

5. 5. The method of claim 4, further comprising storing the CAN message in a specific storage area of ​​the memory based on buffering table type information of the CAN message previously searched by the IDS core, wherein the buffering table type information includes buffer type information and buffer index information.

6. 6. The method of claim 5, further comprising the step of processing the CAN message in at least one of the following cases: searching the lookup table by the IDS core and finding no matching information; not needing buffering for the CAN message; and having to process the buffered CAN message.

7. 7. The method of claim 6, further comprising searching a detection policy in a lookup table through a binary search by the IDS core based on the bus and CAN ID of the CAN message retrieved from the engine memory.

8. storing the CAN message in an unknown message buffer of a buffering table in a memory according to unknown message buffering table information when there is no matching policy in the lookup table by the IDS core; incrementing a head value of the stored message by the IDS core; and 8. The method of claim 7, further comprising transmitting information regarding the address of the buffering table of the currently copied item, the address for the detection policy rule, the buffer type and the buffer index to the detection engine base via an interface by the IDS core.

9. storing a corresponding CAN message in a buffer table of a memory according to buffer table type information of the corresponding CAN message when a matching detection policy is found in the lookup table by the IDS core; incrementing a head value of the stored message by the IDS core; and 8. The method of claim 7, further comprising transmitting information regarding the address of the buffering table of the currently copied item, the address for the detection policy rule, the buffer type and the buffer index to the detection engine base via an interface by the IDS core.

10. storing the corresponding CAN message in a buffering table in a memory area according to buffering table type information of the corresponding CAN message when a detection policy matching the CAN message is found in the lookup table by the IDS core; determining, by the IDS core, whether a buffer index of the buffering table type information is 0, null, inactive, or minor; and 8. The method of claim 7, further comprising the step of determining, by the IDS core, that the corresponding CAN message is a message that does not require buffering.

11. The method of claim 10, further comprising the step of: not storing the corresponding CAN message in a buffering table by the IDS core, and transmitting the message address of the currently copied item and address information for the detection policy rule to the detection engine base via an interface.

12. 1. A controller area network (CAN) intrusion detection system (IDS), comprising: An ECU (electronic control unit) layer or an AUTOSAR layer implemented on the hardware; A real time environment (RTE) or interface that connects the components of the AUTOSAR layer with applications (App); and The IDS core layer and the IDS detect layer are mounted on the application, The AUTOSAR layer includes a CAN packet mirroring system, The CAN packet mirroring system receives a CAN message from a CAN driver present in an AUTOSAR Pdu Router (PduR) area of ​​the AUTOSAR layer, stores the received CAN message in a plurality of storage areas of a memory, and the plurality of storage areas are managed separately from each other as a shared memory; The IDS core of the IDS core layer reads the data copied in the CAN packet mirroring system and transmits it to the detection engine base of the IDS core, and separately manages a first memory area that stores a policy binary file of the IDS policy rule and a second memory area that stores a buffering table for buffering and storing the CAN message, in a controller area network intrusion detection system.

13. 13. The controller area network intrusion detection system of claim 12, wherein the CAN packet mirroring system copies and stores the CAN standard message data stored in the first shared memory area of ​​the memory to a first engine memory area, and copies and stores the CAN flexible data (FD) message data stored in the second shared memory area of ​​the memory to a second engine memory area.

14. The controller area network intrusion detection system of claim 13, wherein the IDS core copies the CAN data from the shared memory to the engine memory before the CAN data is transmitted to the detection engine base, and the CAN message brought to the engine memory is stored in a buffering table.

15. The controller area network intrusion detection system of claim 14, wherein the IDS core searches a lookup table of a policy binary file through bus information and a CAN ID (ID: identification) of the received CAN message to store the CAN message in a buffering table.

16. 16. The controller area network intrusion detection system of claim 15, wherein the IDS core stores the CAN message in a specific storage area of ​​the memory based on buffering table type information of the previously searched CAN message, wherein the buffering table type information includes buffer type information and buffer index information.

17. The controller area network intrusion detection system of claim 16, wherein the IDS core processes the CAN message in at least one of the following cases: when there is no matching information after searching the lookup table; when buffering is not required for the CAN message; and when processing must be performed for a buffered case.

18. The IDS core searches for a detection policy in a lookup table through a binary search based on the bus and CAN ID of the CAN message retrieved from the engine memory; when there is no matching policy in the lookup table, stores the CAN message in an unknown message buffer of a buffering table in the memory through unknown message buffering table information; increments a head value of the stored message by one; and transmits information on the buffering table address of the currently copied item, the address for the detection policy rule, the buffer type and the buffer index to the detection engine base through an interface.

19. The IDS core searches for a detection policy in a lookup table through a binary search based on the path and CAN ID of the CAN message retrieved from the engine memory; when a matching policy or message is found in the lookup table, stores the corresponding CAN message in a buffering table in the memory through buffering table type information of the corresponding CAN message; increments a head value of the stored message by one; and transmits information on the buffering table address, address for the detection policy rule, buffer type and buffer index of the currently copied item to the detection engine base through an interface.

20. 20. The controller area network intrusion detection system of claim 17, wherein the IDS core searches for a detection policy through a binary search in a lookup table based on the path and CAN ID of the CAN message retrieved from the engine memory; when a detection policy matching the CAN message is found in the lookup table, the IDS core stores the corresponding CAN message in a buffering table in a memory area through buffering table type information of the corresponding CAN message; if a buffer index of the buffering table type information is 0, null, inactive or minor, the IDS core determines that the corresponding CAN message is a message that does not require buffering; and does not store the corresponding CAN message in a buffering table, and transmits a message address of the currently copied item and address information for the detection policy rule to the detection engine base through an interface.

Images