Message detection method and device and electronic equipment

Abstract

The invention discloses a message detection method and device and electronic equipment, and relates to the technical field of information security. According to the invention, validity verification is carried out on the obtained first message, and the malformed message is discarded. Further, whether a target detection field pair for detecting the first message is a preset compliance field pair is detected, and the compliance field pair represents the clock ID and the source IP which have the binding relationship. And if the preset compliance field pair contains the target detection field pair and the target detection field in the first message meets a preset receiving condition, determining that the first message passes detection. According to the method and the device, the forged or invalid message is detected and filtered, so that the consumption of the ECU and the application program caused by the forged or invalid message can be effectively avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and more particularly to a message detection method and device and electronic equipment. BACKGROUND

[0002] The Precision Time Protocol (PTP) is used to synchronize all clocks in a distributed network, and has a very important application in the automatic driving industry.

[0003] With the continuous development of automotive electronics technology, the functions of the vehicle-mounted system are becoming more and more rich, and the requirements for vehicle performance are becoming higher and higher. Therefore, the vehicle-mounted system is configured with multiple electronic control units (ECU), such as engine management systems, electric automatic transmission systems, and automatic anti-lock systems, which can all include ECUs. Moreover, in the vehicle-mounted system, multiple ECUs can be clock-synchronized based on PTP protocol messages or PTP data packets.

[0004] However, the ECUs in the vehicle-mounted system have a potential risk of being attacked. Once the ECUs are successfully attacked, the normal operation of the vehicle-mounted system is affected, and even a great threat to the safety of the vehicle is caused. SUMMARY

[0005] In view of the above problems, the present application provides a message detection method, device and electronic equipment to reduce the risk of ECU attack. The specific scheme is as follows:

[0006] In a first aspect, the present application provides a message detection method, comprising:

[0007] Obtaining a first message, the first message being used to synchronize a clock;

[0008] Performing a legality check on a message header of the first message to determine whether the first message is a malformed message;

[0009] In the case where the first message is not the malformed message, obtaining a target detection field pair in the first message, the target detection field pair including a first detection field representing a source IP and a second detection field representing a clock ID;

[0010] Determining whether the target detection field pair is contained in a preset compliance field pair, the preset compliance field pair containing multiple compliance field pairs, and the compliance field pair being a first detection field and a second detection field having a binding relationship;

[0011] If the target detection field pair is contained in the preset compliance field pair, and the target detection field in the first message meets a preset receiving condition, it is determined that the first message passes the detection.

[0012] In one possible design, in another implementation of the first aspect of this application, the process of determining whether the target detection field in the first message meets the preset reception conditions includes:

[0013] Obtain at least one target detection field from the first message, wherein the target detection field includes at least: a third detection field representing the message type of the first message, and / or the second detection field representing the clock ID;

[0014] Determine whether the target detection field is included in the preset filter field. The preset filter field includes: at least one preset field, and an execution action corresponding to each preset field. The execution action includes: allow passage or discard.

[0015] If the preset filter field does not contain all of the target detection fields, then query the default policy to determine the action to be taken if the preset filter field does not contain all of the target detection fields.

[0016] If the preset filter field contains any of the target detection fields, then the execution action corresponding to the target detection field contained in the preset filter field is determined;

[0017] If the execution action is to allow passage, it is determined that the target detection field in the first message meets the preset reception conditions;

[0018] If the action is to discard, it is determined that the target detection field in the first message does not meet the preset reception conditions.

[0019] In one possible design, in another implementation of the first aspect of the embodiments of this application, after determining that the first message detection has passed, the method further includes:

[0020] Check if a corresponding preset forwarding rule exists for the message type of the first message;

[0021] If the message type of the first message does not have a corresponding preset forwarding rule, then the first message is forwarded;

[0022] If the message type of the first message has a corresponding preset forwarding rule, then determine whether the first message meets the preset forwarding rule, and forward the first message that meets the preset forwarding rule.

[0023] In one possible design, in another implementation of the first aspect of the embodiments of this application, determining whether the first message satisfies the preset forwarding rule includes:

[0024] Obtain the preset forwarding rule, which limits the interval threshold conditions for the receiving time interval or sending time interval between each sub-message in the first message;

[0025] Detect whether the receive time interval or send time interval between every two adjacent sub-messages in the first message meets the interval threshold condition;

[0026] If the receiving time interval or sending time interval between any two adjacent sub-messages in the first message does not meet the interval threshold condition, then it is determined that the first message does not meet the preset forwarding rule.

[0027] If the receiving time interval or sending time interval between any two adjacent sub-messages in the first message meets the interval threshold condition, then the first message is determined to meet the preset forwarding rule.

[0028] In one possible design, in another implementation of the first aspect of the embodiments of this application, the method further includes:

[0029] Based on the field content of the first message, the execution action, and the reason corresponding to the execution action, a log file corresponding to the first message is generated.

[0030] In one possible design, in another implementation of the first aspect of the embodiments of this application, the method further includes:

[0031] Detect the speed at which the log file is generated;

[0032] If the speed exceeds a preset threshold, adjust the generation speed of the log file.

[0033] In one possible design, in another implementation of the first aspect of the embodiments of this application, the method further includes:

[0034] The total number of messages sent and received is counted, and a statistical file is generated. The total number of messages sent and received includes at least: the total number of the first messages sent and received through different interfaces, and the total number of the first messages that were detected as passed or discarded.

[0035] In one possible design, in another implementation of the first aspect of the embodiments of this application, the method further includes:

[0036] If, based on the statistical file, the total number of the first messages that have been dropped exceeds a preset dropping threshold, a message indicating an abnormal message transmission / reception is sent to the front end.

[0037] Secondly, this application provides a message detection device, comprising:

[0038] A message acquisition unit is used to acquire a first message, which is used to synchronize the clock.

[0039] A validity verification unit is used to perform validity verification on the header of the first message to determine whether the first message is a malformed message;

[0040] The field pair acquisition unit is used to acquire the target detection field pair in the first packet when the first packet is not the malformed packet. The target detection field pair includes a first detection field representing the source IP and a second detection field representing the clock ID.

[0041] The field pair detection unit is used to determine whether the target detection field pair is included in the preset compliance field pair. The preset compliance field pair includes multiple compliance field pairs, and the compliance field pair is a first detection field and a second detection field that have a binding relationship.

[0042] The detection result determination unit is used to determine that the first message has passed detection when the detection result of the detection unit for the field is yes and the target detection field in the first message meets the preset reception conditions.

[0043] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0044] The memory is used to store programs;

[0045] The processor is configured to execute the program to implement the message detection method described in any of the first aspects of this application.

[0046] By employing the above technical solution, the message detection method provided in this application first performs a preliminary legality check on the message header of the acquired first message, which can initially filter out malformed messages. Furthermore, considering that ECUs are often attacked by forged and invalid messages, this application performs deep detection on the field content of the first message to determine whether the first message is a forged or invalid message. First, based on preset compliance field pairs, the binding relationship of the target detection field pairs in the first message is detected to determine whether the message has been tampered with, thus filtering out forged messages. Simultaneously, the target detection fields of the first message are checked to see if they meet preset receiving conditions, thereby filtering out invalid messages. Based on this, by performing deep detection on the message content and filtering out forged or invalid messages, the subsequent forwarding of messages that pass detection can effectively avoid the consumption of ECUs and applications by forged or invalid messages, reducing the possibility of malicious messages attacking the ECU. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0048] Figure 1 This is a schematic flowchart illustrating the implementation of a message detection method provided in an embodiment of this application.

[0049] Figure 2 A system architecture diagram for implementing the message detection method provided in this application embodiment;

[0050] Figure 3 This is a schematic diagram of the structure of a message detection device provided in an embodiment of this application;

[0051] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0052] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0053] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0054] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0055] This application can be applied to fields such as information security and vehicle network information security. The following uses intelligent driving and vehicle networking as examples to illustrate the application scenarios of a message detection method.

[0056] This application can be applied, but is not limited to, to functional units or devices in vehicle systems that require high-precision time synchronization, such as vehicle Ethernet switches, ECUs, V2X communication modules, etc. The functional units or devices can synchronize their clocks based on PTP protocol messages or PTP data packets, so that the clocks of all functional units / devices in the vehicle system remain synchronized.

[0057] According to existing automotive Ethernet protocols, all PTP packets based on IP (Internet Protocol Address) can be delivered to the application layer of each functional unit or device for processing through the complete network protocol stack. Therefore, any user can send PTP packets between different ECUs for time synchronization. However, since the transmitted PTP protocol packets may be tampered with, or a large number of invalid PTP packets may be transmitted simultaneously, overwhelming the automotive system, the ECUs in the automotive system are at potential risk of being attacked. Once an ECU is successfully attacked, it will affect the normal operation of the automotive system and even pose a great threat to vehicle safety.

[0058] To address the aforementioned problems, this application proposes a message detection method that can be applied to ECUs or other functional units / devices capable of receiving or sending PTP messages. (Refer to...) Figure 1 This application provides a flowchart illustrating a message detection method, which explains the steps involved in implementing the method. Specifically, the steps may include the following:

[0059] Step S110: Obtain the first message, which is used to synchronize the clock.

[0060] After the vehicle starts, the ECU or functional unit / device of the on-board system powers on and loads the computer program product or detection module used to implement the message detection method. PTP receives messages using a UDP protocol port at the transport layer. Once the first message is received, it begins detection of the first message based on the computer program product or detection module. In this embodiment, the first message refers to a precision clock synchronization message used for synchronizing the clock, i.e., a PTP message.

[0061] Optionally, the ECU or functional unit / device can also pre-configure default policies and user-defined policies. Default policies typically refer to default behavior rules set for situations where the user / system / protocol has not explicitly configured them. User-defined policies can be understood as behavior rules customized by the user for specific detection scenarios during message detection. For example, through steps S120-S150 below, if the detection result of the first message obtained from the braking ECU is a failure, the message should be discarded. However, according to the default policy or user-defined policy, the first message obtained from the braking ECU, regardless of its detection result, cannot be discarded. Therefore, the final detection result can be determined as successful, thus driving subsequent forwarding operations.

[0062] Step S120: Perform a validity check on the header of the first message to determine whether the first message is a malformed message. If not, proceed to step S130; if yes, terminate the detection.

[0063] A PTP message must contain three parts: a message header, a message body, and message extension bytes. In this embodiment, the message header of the PTP message is validated for legality. In one possible implementation, the protocol version number corresponding to the PTP message can be determined through the message header. Based on the official protocol document corresponding to that version number, the PTP message header is validated for legality. For example, whether the byte length is within the protocol threshold, and whether all or some fields are standard fields defined by the protocol. For instance, if the field indicating the message meaning in the header of the first message is "0x0F", but the message type "0x0F" is not defined in any version of the Precision Clock Synchronization Protocol, then the first message is a malformed message. The validation can be terminated according to the predetermined action set in the default policy for cases where the first message is a malformed message.

[0064] In another possible implementation, the process of validating the header of the first message may also include: obtaining the field representing the PTP protocol version number from the header of the first message, and determining whether it conforms to the protocol version specified in the IEEE 1588 protocol (Precision Clock Synchronization Protocol for Network Measurement and Control Systems, hereinafter referred to as the 1588 protocol). The 1588 protocol specifies two versions, PTPv1 and PTPv2. Optionally, considering that PTPv1 is not currently widely used, PTPv1 messages can be exempted from inspection, that is, all received PTPv1 version messages can be directly allowed to pass.

[0065] The following example of a message is used to illustrate: The first message A in hexadecimal is: 0x 10 0[5]00 2c 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 80 63 ff ff 00 09 ba 00 01 00 73 0000 00 00 45 b1 11 59 0a 65 77 25. Excluding "0x", each pair of characters is a byte. In the PTP message format rules, the lower 4 bits of the second byte represent the PTP version, such as 0x02, which represents the PTPv2 version. Based on this, the protocol version represented by the lower 4 bits of the second byte of the first message, 0x05, is PTPv5, which is not a protocol version specified by the 1588 protocol. Therefore, it can be determined that the protocol version number of the first message is incorrect. The square brackets "[]" and spaces in the example message are for highlighting purposes, making it easier for readers to find the target character. The original message does not contain these symbols. The same applies to the following examples, so we will not repeat them here.

[0066] Retrieve the message type field from the header of the first message, and check whether the message type of the first message conforms to the 1588 protocol. The protocol specifies two categories of PTPv2 messages: time messages and general messages, as detailed in Table 1 below:

[0067] Table 1 Message Types in Message Headers

[0068]

[0069] The following example of a message is used to illustrate the situation. The first message B is: 0x0[6]020036000004000000000000000000000000000484952fffe41108100016b12037f000061cf957708d6fb98484952fffe41608c0001. Among them, according to Table 1 above, 0x6 of this message does not have a corresponding message type specified by the protocol. Therefore, this message is a malformed message.

[0070] Furthermore, the matching degree between PTP message type and transport layer port is checked. It is understood that PTP uses port 319 of the UDP protocol for event message transmission and port 320 for general message transmission at the transport layer. This application embodiment transmits and monitors the correctness of message transmission according to this UDP protocol specification. If the message type of the transmitted message does not match the corresponding port, the message may contain errors. For example, the first message A is transmitted using port 320 as specified by the UDP protocol. However, the message type corresponding to "0x00" in the header field of the first message A is the event message "Sync," which should be transmitted using port 319. Therefore, the message type of the first message A does not match the transmission port, and the actual message type of the first message A should be a general message, resulting in an incorrect message header.

[0071] Optionally, the field representing the message length is obtained from the header of the first message, and the message length represented by the field is checked to see if it is equal to the actual length of the header field. If they are not equal, it proves that there is an error in the header field.

[0072] The following example illustrates the PTP message: 0x1002[002c]00000000000000000000000000000000008063ffff0009ba000100730000000045b111590a657725. The message length should be 002c, which is 44 bytes, but it is actually only 40 bytes. Therefore, the field corresponding to the message length in this message is incorrect. The correct length should be 0028.

[0073] Based on this, the embodiments of this application perform in-depth analysis of PTP messages, and verify the legality of the protocol version number, message type, PTP message length, and PTP message transport layer port and message type matching degree in the PTP general message header according to the official 1588 protocol documentation to prevent attacks from malformed messages. After the message is determined to be a legitimate message, the following steps are then performed.

[0074] Step S130: Obtain the target detection field pair in the first message. The target detection field pair includes: a first detection field representing the source IP and a second detection field representing the clock ID.

[0075] Step S140: Determine whether the preset compliance field pair contains the target detection field pair. If so, proceed to step S150.

[0076] It is understandable that the IP address and clock ID of a clock synchronization device are usually bound together. If the source IP and clock ID recorded in the received first message are not bound together, the message may be maliciously tampered with or have its IP or ID forged. If this message is transmitted, there is a risk of being attacked by an unknown device. Therefore, in this embodiment, the binding relationship between the source IP and clock ID in the first message is detected to determine whether the message has been tampered with or forged. It should be noted that the source IP of the first message refers to the IP address of the clock synchronization device that sent the first message.

[0077] First, the first message contains a field representing the source IP or clock ID. Extract the corresponding field to determine the source IP and clock ID corresponding to the first message. For example, part of the content of the first message is as follows: 01 00 5e 00 01 81 48 49 5241 10 91 08 00 45 00 00 48 40 6d 40 00 01 11 a0 11 [ac 14 0b 91] e0 00 01 8101 3f 01 3f 00 34 99 6c 00 02 00 2c 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [48 49 52 ff fe 41 10 91] 00 01 00 0e 00 00 00. The source IP is the first detection field "ac 14 0b 91", and the clock ID is the second detection field "48 49 52 ff fe 41 10 91". If there is a binding relationship between the source IP and the clock ID, the message is sent by a known device and there is no possibility of tampering or forgery.

[0078] Furthermore, the pre-defined compliance field pairs are obtained. These pre-defined compliance field pairs contain multiple compliance field pairs, which are the first and second detection fields with a binding relationship. That is, the pre-defined compliance fields specify multiple pairs of source IPs and clock IDs with a binding relationship. The source IP "ac 14 0b 91" and clock ID "48 49 52 ff fe 41 1091" field pair in the packet are compared with the multiple compliance field pairs in the pre-defined compliance fields. If two completely identical field pairs exist, it proves that the source IP and clock ID corresponding to the first packet have a binding relationship and belong to the specified compliant IP and ID, thus the verification passes.

[0079] The preset compliance fields can be preset based on the actual IP / ID of the vehicle system or functional unit / device. For example, a compliance field pair can be set based on the following fields: ebpftables-A-ieth0-pptp-fbind--source-ip192.168.1.28--clock-id0x484952FFFE41608C. This means that interface eth0 is allowed to receive PTP packets with a source IP of 192.168.1.28 and a clock ID of 0x484952FFFE41608C. The verification is confirmed to be successful only when the source IP and clock ID of the packet are completely consistent with the compliance field pair defined by this field.

[0080] Understandably, if the above verification fails, i.e., the source IP and clock ID in the first message do not belong to a known source IP and clock ID with a binding relationship, the detection can be terminated, the message can be determined to have been tampered with or forged, and the message can be discarded.

[0081] In another possible implementation, the appropriate action or behavior rule for the current situation can be determined based on a default policy or a user-defined policy. For example, the default policy stipulates that for packets with a source IP of 192.168.1.28 that do not meet the above binding rules, the predetermined action is ACCEPT, which confirms that the detection result of step S140 is successful and allows subsequent steps to be executed. However, if the detection result of step S140, as well as the default policy or user-defined policy, are combined, and the detection result of the first packet is unsuccessful, the detection is terminated and the packet is discarded.

[0082] Step S150: Determine whether the target detection field in the first message meets the preset reception conditions. If yes, proceed to step S160; otherwise, determine that the message detection fails and discard the first message.

[0083] Step S160: Confirm that the first message has passed the detection.

[0084] Furthermore, if it is determined that the first message has not been tampered with or forged, the target detection field of the first message is further checked to see if it meets the preset reception conditions, so as to determine whether the first message is an invalid message and avoid invalid messages from consuming the application layer.

[0085] Understandably, preset reception conditions can be set as the basis for determining valid and invalid packets. Specifically, for example, a packet with a source IP of 192.168.1.28 can be determined as an invalid packet. Therefore, in the preset reception conditions, 192.168.1.28 is bound to "invalid packet / not allowed," generating an invalid packet rule. If the first packet meets this invalid packet rule, then the first packet is determined to be an invalid packet. Understandably, preset reception conditions can limit multiple invalid or valid rules. If the first packet meets any one of these invalid rules, then the first packet is determined to be an invalid packet that is not allowed, and therefore does not meet the preset reception conditions. Conversely, if the first packet does not meet all invalid rules but meets any one of the valid rules, then the first packet is determined to be a valid packet that is allowed, and therefore meets the preset reception conditions.

[0086] In another possible implementation, the process of determining whether the target detection field in the first message meets the preset reception conditions includes: obtaining at least one target detection field in the first message, wherein the target detection field includes at least a third detection field representing the message type of the first message, and / or a second detection field representing the clock ID; determining whether the preset filtering field contains the target detection field, wherein the preset filtering field includes at least one preset field, and an execution action corresponding to each preset field, the execution action including: allow passage or discard; if the preset filtering field does not contain all target detection fields, querying the default policy for the execution action when the preset filtering field does not contain all target detection fields; if the preset filtering field contains any target detection field, determining the execution action corresponding to the target detection field contained in the preset filtering field; if the execution action is to allow passage, determining that the target detection field in the first message meets the preset reception conditions; if the execution action is to discard, determining that the target detection field in the first message does not meet the preset reception conditions.

[0087] It is understandable that determining whether the target detection field in the first message meets the preset reception conditions is essentially a process of filtering out messages that are not allowed to pass based on pre-defined fields. Therefore, the preset filtering fields include multiple preset fields that are allowed to pass and multiple preset fields that are not allowed to pass. In one possible implementation, the preset fields can be set by configuring filtering rules. For example: ebpftables-A-ieth0-pptp--v2-type0x9--clock-id0x484952FFFE411081-jACCEPT. This filtering rule indicates that interface eth0 is allowed to receive PTP messages with PTPv2 message type 0x09 (i.e., Delay_Resp messages) and clock ID 0x484952FFFE411081. The preset fields corresponding to this filtering rule are: PTPv2 message type 0x09 and clock ID 0x484952FFFE411081, and its corresponding action is: allow to pass. Alternatively, the filter rule `ebpftables-A-oeth0-pptp--clock-id0x484952fffe41608c-jDROP` indicates that interface eth0 is not allowed to send PTP packets with clock ID 0x484952fffe41608c. The default field configured for this filter rule is: clock ID 0x484952fffe41608c, and the corresponding action is: discard.

[0088] Therefore, the preset fields can contain two fields representing the message type and the clock ID respectively, or they can contain only one field containing the message type or the clock ID. According to the matching order shown in Table 2 below, the message type field and the clock ID field of the first message can be compared with each preset field respectively.

[0089] Table 2 Matching Order

[0090]

[0091] First, the message type field and clock ID are treated as a combined field and matched against a preset field that is also a combined field. It should be noted that, in this embodiment, if a matching preset field is found, the execution action corresponding to that preset field is considered the highest-level execution action determined in step S150. Even if the preset field is subsequently matched separately by the message type field or the clock ID field, the highest-level execution action determined by the combined field is still the only result.

[0092] If no matching preset field is found for the combined fields, the process continues by matching the message type field or clock ID field as a single field with other single preset fields. If a completely matching preset field is found, the corresponding action is determined. If the action is to discard, the first message is determined to be a preset message that is not allowed to pass, and the target detection field of the first message does not meet the preset reception conditions. Only if the corresponding actions for each preset field that matches the message type field and clock ID field of the first message are all allowed, is the target detection field of the first message determined to meet the preset reception conditions, and its detection is deemed successful.

[0093] If none of the above matching methods match the preset field corresponding to the first message, the predetermined execution rule or action corresponding to this situation can be determined according to the default policy or user-defined policy. If the predetermined execution rule or action is DROP, the first message is discarded and the detection is terminated; if the predetermined execution rule or action is ACCEPT, step S160 is executed to confirm that the detection has passed.

[0094] In summary, the message detection method provided in this application first performs a preliminary legality check on the header of the acquired first message, which can initially filter out malformed messages. Furthermore, considering that ECUs are often attacked by forged and invalid messages, this application performs deep detection on the field content of the first message to determine whether the first message is a forged or invalid message. First, based on preset compliance field pairs, the binding relationship of the target detection field pairs in the first message is detected to determine whether the message has been tampered with, thus filtering out forged messages. Simultaneously, the target detection fields of the first message are checked to see if they meet preset receiving conditions, thereby filtering out invalid messages. Based on this, by performing deep detection on the message content and filtering out forged or invalid messages, the subsequent forwarding of messages that pass the detection can effectively avoid the consumption of ECUs and applications by forged or invalid messages, reducing the possibility of malicious messages attacking the ECU.

[0095] Next, based on the embodiments below, other possible implementations of the message detection method provided above will be described.

[0096] In one possible implementation, after confirming that the first message has passed the detection, the process also includes forwarding the first message.

[0097] Forwarding can refer to forwarding to the application layer of the ECU, based on the clock synchronization of the first message, or it can refer to forwarding the first message to other ECUs.

[0098] In this embodiment of the application, the process of forwarding the first message may include: querying whether there is a corresponding preset forwarding rule for the message type of the first message; if there is no corresponding preset forwarding rule for the message type of the first message, then forwarding the first message; if there is a corresponding preset forwarding rule for the message type of the first message, then determining whether the first message satisfies the preset forwarding rule, and forwarding the first message that satisfies the preset forwarding rule.

[0099] Understandably, during the message detection process, it is impossible to monitor the flow status of messages received by the ECU. If a large number of messages are transmitted to the ECU in a short period of time, the ECU may be unable to process a large number of requests in a short time, resulting in delays or interruptions in normal control logic and affecting the normal operation of the vehicle system.

[0100] Therefore, after determining that the first message is allowed to pass, but before forwarding it, the message sending rules of the first message are checked. It is understood that a PTP message contains multiple sub-messages, such as the four key sub-message types: Sync, Follow_Up, Delay_Req, and Delay_Resp. When the peer device sends a PTP message to this ECU, it sequentially sends the sub-messages to this ECU. To avoid traffic attacks involving a large number of messages (including sub-messages) in a short period, this embodiment of the application can detect the received sub-messages sent by the peer and the sending time or message traffic of the PTP message.

[0101] Therefore, the preset forwarding rules can be set as follows: the number of packets allowed to be received from the peer device within a time period, or the threshold for the transmission time interval between adjacent packets sent by the peer device, or the threshold for the transmission time interval between adjacent packets of the same type in the four key sub-packets of Sync, Follow_Up, Delay_Req and Delay_Resp, etc.

[0102] Understandably, not every message type has a pre-configured forwarding rule. Therefore, when checking message sending rules, it's necessary to determine whether the message type of the first message has a corresponding pre-configured forwarding rule. If no pre-configured forwarding rule is configured, the first message is forwarded directly, or a predetermined action is determined based on the default policy or a user-defined policy. If a pre-configured forwarding rule is found, the sending time of each sub-message in the first message is used to determine whether the first message meets the pre-configured forwarding rule.

[0103] In one possible implementation, the process of determining whether the first message meets the preset forwarding rules includes: obtaining the preset forwarding rules, which limit the interval threshold conditions for the receiving time interval or sending time interval between each sub-message in the first message; detecting whether the receiving time interval or sending time interval between any two adjacent sub-messages in the first message meets the interval threshold conditions; if the receiving time interval or sending time interval between any two adjacent sub-messages in the first message does not meet the interval threshold conditions, then it is determined that the first message does not meet the preset forwarding rules; if the receiving time interval or sending time interval between any two adjacent sub-messages in the first message meets the interval threshold conditions, then it is determined that the first message meets the preset forwarding rules.

[0104] In the embodiments of this application, when the interface of the ECU or other functional unit / device receives or sends a PTP message, it is necessary to perform message detection on the PTP message. After confirming that the PTP message has passed the detection, the interface forwards the PTP message to complete the sending or receiving of the PTP message.

[0105] The preset forwarding rules define the conditions under which the first message, after passing message detection, can be forwarded through the interface of the ECU or other functional units / devices. Specifically, they define the threshold conditions for the interval between receiving or sending sub-messages within the first message. The preset forwarding rules can also be configured according to the filtering rules described above, for example: `ebpftables-A-ieth0-pptp--sync-interval2`, which sets the minimum interval for interface eth0 to receive PTPv2 SYNC messages to 2 seconds. 2 Second.

[0106] It should be noted that the interaction regarding the first message involves a sender and a receiver, which are respectively the ECU or other functional units / devices that send and receive the message. The sender determines whether the first message conforms to the preset forwarding rules by detecting the transmission time interval between each sub-message in the first message; the receiver determines whether the first message conforms to the preset forwarding rules by detecting the reception time interval between each sub-message in the first message.

[0107] Taking the sending end's detection of the first message as an example, the sending end determines whether the sending time interval between two adjacent sub-messages meets the interval threshold condition based on the sending time corresponding to each sub-message recorded in the first message. For example, the interval threshold condition is that the sending time interval between adjacent sub-messages is not less than the minimum time interval.

[0108] If the transmission time interval between any two adjacent sub-messages in the first message meets the interval threshold condition, then the first message satisfies the preset forwarding rules, and the sending end's interface formally forwards the first message and sends it out. Conversely, if the transmission time interval between any two adjacent sub-messages in the first message does not meet the interval threshold condition, then the first message does not satisfy the preset forwarding rules. If this message is sent, for the sending end, a large number of transmission operations may block task scheduling, squeeze the communication time window, and violate system timing constraints; for the downstream receiving end, there is a risk of a traffic attack with a large number of messages input in a short period of time. Therefore, the sending end's interface discards the first message that does not satisfy the preset forwarding rules.

[0109] Therefore, the detection of the first message before forwarding according to the preset forwarding rules can be understood as a kind of rate limiting detection, that is, limiting the speed of message transmission to avoid the problem of the message overwhelming the vehicle system due to the transmission of a large number of messages in a short period of time.

[0110] In one possible implementation, the message detection method may further include: generating a log file corresponding to the first message based on the field content of the first message, the action performed, and the reason for the action performed.

[0111] The first message's fields may include key information such as clock ID, source IP, port, and message type. The action to be executed refers to whether the first message is allowed to pass or discarded. The reason for the action can be understood as the reason for determining whether to allow or discard the message during the message detection process. For example, if the first message is discarded because no matching detection field pair with a binding relationship can be found in step S130, the reason for the discard action can be recorded as: Reason=bind mismatch. Optionally, the log file may also record PTP application layer information, rate limiting conditions / rules, etc.

[0112] Each first message corresponds to a log file, which is stored in the log file in chronological order. In one possible implementation, the message detection method may also include: detecting the speed of log file generation; if the speed exceeds a preset threshold, adjusting the log file generation speed.

[0113] Understandably, monitoring PTP messages via logs helps the vehicle system or ECU identify applications that initiate the PTP protocol, allowing for targeted alerts to users regarding potential attack scenarios. Furthermore, if the log file generation rate is too fast, exceeding a preset threshold, it could indicate two things: firstly, the ECU is receiving a large number of PTP files in a short period, potentially triggering a DDoS attack. In this case, measures such as limiting or discarding messages can be implemented to mitigate the risk. Secondly, it could exceed the storage capacity of the log file storage unit. This can be addressed by adjusting the log file generation rate. For example, instead of generating 30 log files per second whenever a PTP file is received, the rate could be limited to 10 relevant log entries per second, with excess logs discarded.

[0114] In another possible implementation, the message detection method may also include: counting the total number of messages sent and received, generating a statistical file, wherein the total number of messages sent and received includes at least: the total number of first messages sent and received on different interfaces, the total number of first messages that passed detection or were discarded, etc.

[0115] Each time the first message is received, the total number of first messages sent and received by the port corresponding to the receiving and subsequent forwarding messages is counted. At the same time, the number of first messages corresponding to each detection result is counted. Optionally, the total number of messages corresponding to different message types and clock IDs detected can also be counted. The execution actions corresponding to the detection steps S130-S150 above are also counted. The number of messages matching different binding rules and filtering rules is counted. The sending and receiving statistics of messages matching different preset forwarding rules can also be performed.

[0116] Optionally, a statistical report corresponding to the current vehicle driving cycle can be generated by statistically analyzing all the first reports detected after the vehicle system starts up.

[0117] In another possible implementation, the message detection method also includes: if, based on a statistical file, the total number of first messages that have been dropped exceeds a preset drop threshold, sending a message indicating an abnormal message transmission / reception to the front end.

[0118] By analyzing the statistics of sent and received messages during the detection process, if the number of dropped messages exceeds the preset drop threshold, a message indicating an abnormality in sending and receiving messages can be sent to the front end. Alternatively, if it is determined through statistics that a certain binding rule, filtering rule, or preset forwarding rule has a low number of messages passing through or a high number of messages being lost, an abnormal message can also be sent to the front end to remind it to modify the abnormal rule.

[0119] Based on the message detection method provided above, refer to Figure 2The present application provides a system architecture diagram for implementing the message detection method, which serves as an exemplary illustration of a system architecture capable of implementing the aforementioned message detection method.

[0120] This system architecture is used to implement a packet detection method for PTP deep packet inspection. It includes two application functions: C1 application identification and security filtering and C2 application monitoring.

[0121] Implementing C1 application identification and security filtering functions includes the following steps: S1, application type identification; S2, prevention of malformed packet attacks; S3, support for binding source IP address and clock ID; S4, combined filtering function based on PTPv2 packet message type and clock ID; S5, limiting based on different PTPv2 packet message types.

[0122] Refer to steps S110-S160 described above and compare them with steps S1-S5 for understanding. S1 and S2 correspond to steps S110-S120 above, which involve obtaining PTP packets and verifying their legality based on the message type, protocol version number, and packet length in the PTP packet header to prevent attacks from malformed packets. S3, S4, and S5 are respectively understood by referring to S140 and S150 above, as well as the content corresponding to the preset forwarding rules. The specific process can be referred to the description above and will not be repeated here.

[0123] The C2 application monitoring functions mainly include: a rate-limitable logging function and a traffic statistics function. Please refer to the description of log files and statistics files above, which will not be repeated here.

[0124] Based on this, the message detection method proposed in this application can not only perform security detection on the first message acquired in a single instance, but also detect the message transmission and reception status of the entire vehicle system from a macroscopic perspective through log files or statistical files, thereby improving the accuracy of security detection of PTP message transmission and reception and greatly reducing the risk of ECU being attacked.

[0125] The above describes a message detection method provided by an embodiment of this application. The following describes the apparatus for performing the above-described message detection method. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of a message detection device provided in an embodiment of this application. Figure 3 As shown, the message detection device includes:

[0126] The message acquisition unit 100 is used to acquire a first message, which is used to synchronize the clock.

[0127] The legality verification unit 200 is used to perform legality verification on the header of the first message to determine whether the first message is a malformed message;

[0128] The field pair acquisition unit 300 is used to acquire the target detection field pair in the first packet when the first packet is not the malformed packet. The target detection field pair includes a first detection field representing the source IP and a second detection field representing the clock ID.

[0129] The field pair detection unit 400 is used to determine whether the target detection field pair is included in the preset compliance field pair. The preset compliance field pair includes multiple compliance field pairs, and the compliance field pair is a first detection field and a second detection field that have a binding relationship.

[0130] The detection result determination unit 500 is used to determine that the first message has passed detection when the detection result of the detection unit for the field is yes and the target detection field in the first message meets the preset reception conditions.

[0131] In summary, this application first performs a preliminary legality check on the header of the acquired first message, which can initially filter out malformed messages. Furthermore, considering that ECUs are often attacked by forged and invalid messages, this application performs deep inspection of the field content of the first message to determine whether the first message is a forged or invalid message. First, based on preset compliance field pairs, the binding relationship of the target detection field pairs in the first message is checked to determine whether the message has been tampered with, thus filtering out forged messages. Simultaneously, the target detection fields of the first message are checked to see if they meet preset receiving conditions, thereby filtering out invalid messages. Based on this, by performing deep inspection of the message content and filtering out forged or invalid messages, subsequent forwarding of messages that pass inspection can effectively avoid the consumption of ECUs and applications by forged or invalid messages, reducing the possibility of malicious messages attacking the ECU.

[0132] In one possible implementation, the functional unit for determining whether the target detection field in the first message meets the preset reception conditions includes:

[0133] A field acquisition unit is configured to acquire at least one target detection field in the first message, wherein the target detection field includes at least: a third detection field representing the message type of the first message, and / or the second detection field representing the clock ID;

[0134] A field judgment unit is used to determine whether the target detection field is included in the preset filter field. The preset filter field includes: at least one preset field, and an execution action corresponding to each preset field. The execution action includes: allowing passage or discarding.

[0135] The action query unit is used to query the default strategy and execute the action if the judgment result of the field judgment unit is negative.

[0136] An action determination unit is used to determine the action to be performed on the target detection field included in the preset filter field if the judgment result of the field judgment unit is yes.

[0137] The result determination unit is used to determine that, when the execution action is to allow passage, the target detection field in the first message meets the preset reception conditions;

[0138] The result determination second unit is used to determine, in the case that the execution action is the discard, that the target detection field in the first message does not meet the preset reception conditions.

[0139] In one possible implementation, the message detection device further includes:

[0140] The rule query unit is used to query whether there is a corresponding preset forwarding rule for the message type of the first message after the detection result determination unit determines that the first message has passed the detection.

[0141] The message forwarding unit is used to forward the first message if the query result of the rule query unit is negative;

[0142] The rule judgment unit is used to determine whether the first packet satisfies the preset forwarding rule when the query result of the rule query unit is yes, and to forward the first packet that satisfies the preset forwarding rule.

[0143] In one possible implementation, the rule determination unit includes:

[0144] The rule acquisition subunit is used to acquire the preset forwarding rule, which limits the interval threshold conditions for the receiving time interval or sending time interval between each sub-message in the first message.

[0145] The time detection subunit is used to detect whether the receiving time interval or sending time interval between every two adjacent sub-messages in the first message meets the interval threshold condition.

[0146] The judgment result determines the first subunit, which is used to determine that the first message does not meet the preset forwarding rule if the detection result of the time detection subunit is that the receiving time interval or sending time interval between any two adjacent sub-messages in the first message does not meet the interval threshold condition.

[0147] The judgment result determines the second subunit, which is used to determine that the first message satisfies the preset forwarding rule when the detection result of the time detection subunit is that the receiving time interval or sending time interval between any two adjacent sub-messages in the first message satisfies the interval threshold condition.

[0148] In one possible implementation, the message detection device further includes:

[0149] The log generation unit is used to generate a log file corresponding to the first message based on the field content of the first message, the execution action, and the reason corresponding to the execution action.

[0150] In one possible implementation, the message detection device further includes:

[0151] The log detection unit is used to detect the speed at which the log file is generated;

[0152] A generation speed adjustment unit is used to adjust the generation speed of the log file when the detection result of the log detection unit indicates that the speed exceeds a preset threshold.

[0153] In one possible implementation, the message detection device further includes:

[0154] The statistics file generation unit is used to count the total number of messages sent and received and generate a statistics file. The total number of messages sent and received includes at least: the total number of the first messages sent and received through different interfaces, and the total number of the first messages that were detected as passed or discarded.

[0155] In one possible implementation, the message detection device further includes:

[0156] The statistical file detection unit is used to send a message indicating abnormal message transmission to the front end when the total number of the first messages that have been dropped exceeds a preset drop threshold, based on the statistical file.

[0157] This application also provides an electronic device in its embodiments. (See reference...) Figure 4 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, tablets, large-screen teaching displays, wearable devices, etc. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0158] like Figure 4As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 1, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 2 or a program loaded from a storage device 8 into a random access memory (RAM) 3, to implement the message detection method of the foregoing embodiments of this application. When the electronic device is powered on, the RAM 3 also stores various programs and data required for the operation of the electronic device. The processing unit 1, ROM 2, and RAM 3 are interconnected via a bus 4. An input / output (I / O) interface 5 is also connected to the bus 4.

[0159] Typically, the following devices can be connected to I / O interface 5: input devices 6 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 7 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 8 including, for example, memory cards, hard drives, etc.; and communication devices 9. Communication device 9 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0160] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the message detection methods provided in this application.

[0161] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the message detection methods provided in this application.

[0162] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0163] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0164] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0165] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0166] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

Claims

1. A message detection method, characterized in that, include: Obtain the first message, which is used to synchronize the clock; The header of the first message is validated to determine whether the first message is a malformed message; If the first message is not the malformed message, obtain the target detection field pair in the first message, the target detection field pair including a first detection field representing the source IP and a second detection field representing the clock ID; Determine whether the preset compliance field pair contains the target detection field pair. The preset compliance field pair contains multiple compliance field pairs, and the compliance field pairs are first detection field and second detection field that have a binding relationship. If the preset compliance field pair includes the target detection field pair, and the target detection field in the first message meets the preset reception conditions, then the first message is determined to have passed detection.

2. The message detection method according to claim 1, characterized in that, The process of determining whether the target detection field in the first message meets the preset reception conditions includes: Obtain at least one target detection field from the first message, wherein the target detection field includes at least: a third detection field representing the message type of the first message, and / or the second detection field representing the clock ID; Determine whether the target detection field is included in the preset filter field. The preset filter field includes: at least one preset field, and an execution action corresponding to each preset field. The execution action includes: allow passage or discard. If the preset filter field does not contain all of the target detection fields, then query the default policy to determine the action to be taken if the preset filter field does not contain all of the target detection fields. If the preset filter field contains any of the target detection fields, then the execution action corresponding to the target detection field contained in the preset filter field is determined; If the execution action is to allow passage, it is determined that the target detection field in the first message meets the preset reception conditions; If the action is to discard, it is determined that the target detection field in the first message does not meet the preset reception conditions.

3. The message detection method according to claim 1, characterized in that, After determining that the first message has passed detection, the method further includes: Check if a corresponding preset forwarding rule exists for the message type of the first message; If the message type of the first message does not have a corresponding preset forwarding rule, then the first message is forwarded; If the message type of the first message has a corresponding preset forwarding rule, then determine whether the first message meets the preset forwarding rule, and forward the first message that meets the preset forwarding rule.

4. The message detection method according to claim 3, characterized in that, The step of determining whether the first message meets the preset forwarding rule includes: Obtain the preset forwarding rule, which limits the interval threshold conditions for the receiving time interval or sending time interval between each sub-message in the first message; Detect whether the receive time interval or send time interval between every two adjacent sub-messages in the first message meets the interval threshold condition; If the receiving time interval or sending time interval between any two adjacent sub-messages in the first message does not meet the interval threshold condition, then it is determined that the first message does not meet the preset forwarding rule. If the receiving time interval or sending time interval between any two adjacent sub-messages in the first message meets the interval threshold condition, then the first message is determined to meet the preset forwarding rule.

5. The message detection method according to claim 2, characterized in that, The method further includes: Based on the field content of the first message, the execution action, and the reason corresponding to the execution action, a log file corresponding to the first message is generated.

6. The message detection method according to claim 5, characterized in that, The method further includes: Detect the speed at which the log file is generated; If the speed exceeds a preset threshold, adjust the generation speed of the log file.

7. The message detection method according to any one of claims 1-6, characterized in that, The method further includes: The total number of messages sent and received is counted, and a statistical file is generated. The total number of messages sent and received includes at least: the total number of the first messages sent and received through different interfaces, and the total number of the first messages that were detected as passed or discarded.

8. The message detection method according to claim 7, characterized in that, The method further includes: If, based on the statistical file, the total number of the first messages that have been dropped exceeds a preset drop threshold, a message indicating an abnormal message transmission / reception is sent to the front end.

9. A message detection device, characterized in that, include: A message acquisition unit is used to acquire a first message, which is used to synchronize the clock. A validity verification unit is used to perform validity verification on the header of the first message to determine whether the first message is a malformed message; The field pair acquisition unit is used to acquire the target detection field pair in the first packet when the first packet is not the malformed packet. The target detection field pair includes a first detection field representing the source IP and a second detection field representing the clock ID. The field pair detection unit is used to determine whether the target detection field pair is included in the preset compliance field pair. The preset compliance field pair includes multiple compliance field pairs, and the compliance field pair is a first detection field and a second detection field that have a binding relationship. The detection result determination unit is used to determine that the first message has passed detection when the detection result of the detection unit for the field is yes and the target detection field in the first message meets the preset reception conditions.

10. An electronic device, characterized in that, include: Memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the message detection method as described in any one of claims 1 to 8.

Images