Message sending method, message receiving method, message sending device, message receiving device and ECU

Abstract

The invention relates to the technical field of communication, and provides a message sending method, a message receiving method, a message sending device, a message receiving device and an ECU. According to the method, after to-be-sent message information including a source address and a destination address is obtained, the source address and the destination address are verified firstly, a CAN message in a self-defined format is generated after verification is passed, the source address is configured to a source address field of a data field of the CAN message in the self-defined format, and finally the CAN message in the self-defined format is sent. According to the embodiment of the invention, the method can recognize and stop sending the CAN message composed of the illegal source address and the target address of the illegal node, and the source address is hidden in the data field of the CAN message and is difficult to be obtained by an attacker, thereby improving the safety of the CAN message, and improving the user experience.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a message sending method, a receiving method, a sending device, a receiving device and an ECU. Background Art

[0002] As the most common in-vehicle communication protocol in vehicle applications, CAN (Controller Area Network) has the advantages of low cost, no electrical interference, self-diagnosis and error correction.

[0003] However, in the related art, CAN messages are usually sent in a broadcast mode, and the source address and destination address in the message are not verified. Therefore, attackers can attack the CAN network by forging nodes to send illegal messages, thus bringing security risks to users. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a message sending method, a receiving method, a sending device, a receiving device and an ECU to solve the problem of low security in sending and receiving CAN messages in the prior art.

[0005] In a first aspect of an embodiment of the present application, a method for sending a message is provided, where the message is a controller area network (CAN) message, and the method includes: Obtaining information of a message to be sent; the information of the message to be sent at least includes a source address and a destination address; In response to determining that the source address and the destination address are verified, a custom format CAN message is obtained according to the message information to be sent; the data field of the custom format CAN message includes at least a source address field, and the source address field includes a source address; Send CAN messages in custom format.

[0006] A second aspect of an embodiment of the present application provides a method for receiving a message, wherein the message is a controller area network (CAN) message, and the method includes: Receive CAN messages; Get the source address, priority and broadcast flag from the data field of the CAN message; In response to determining that the priority is the highest priority among the CAN messages to be parsed, determining a CAN message sending type according to a broadcast tag; In response to determining that the CAN message is a unicast message according to the broadcast tag, obtaining a destination address from a message identifier of the CAN message; In response to determining that the CAN message has passed verification based on the source address and the destination address, and determining that the destination address is an address of a network node receiving the CAN message, parsing the CAN message to obtain message data; or In response to determining that the CAN message is a broadcast message according to the broadcast tag and determining that the CAN message passes verification based on the source address, the CAN message is parsed to obtain message data.

[0007] In a third aspect of an embodiment of the present application, a message sending device is provided, where the message is a controller area network (CAN) message, and the device includes: The acquisition module is configured to acquire information of the message to be sent; the information of the message to be sent at least includes a source address and a destination address; The encapsulation module is configured to obtain a custom format CAN message according to the message information to be sent in response to determining that the source address and the destination address are verified, wherein the data field of the custom format CAN message includes at least a source address field, and the source address field includes a source address; The sending module is configured to send CAN messages in a custom format.

[0008] In a fourth aspect of an embodiment of the present application, a message receiving device is provided, where the message is a controller area network (CAN) message, and the device includes: A receiving module, configured to receive CAN messages; An acquisition module is configured to acquire a source address, a priority and a broadcast flag from a data field of a CAN message; A parsing module, configured to determine a CAN message sending type according to a broadcast tag in response to determining that the priority is the highest priority among the CAN messages to be parsed; In response to determining that the CAN message is a unicast message according to the broadcast tag, obtaining a destination address from a message identifier of the CAN message; In response to determining that the CAN message has passed verification based on the source address and the destination address, and determining that the destination address is an address of a network node receiving the CAN message, parsing the CAN message to obtain message data; or In response to determining that the CAN message is a broadcast message according to the broadcast tag and determining that the CAN message passes verification based on the source address, the CAN message is parsed to obtain message data.

[0009] According to a fifth aspect of an embodiment of the present application, an electronic control unit is provided, which is configured to execute the steps of any one of the methods in the first to fourth aspects above.

[0010] Compared with the prior art, the embodiments of the present application have the following beneficial effects: after obtaining the message information to be sent including the source address and the destination address, the embodiments of the present application first verify the source address and the destination address, generate a custom format CAN message after the verification, configure the source address in the source address field of the data domain of the custom format CAN message, and finally send the custom format CAN message. It can identify and stop sending CAN messages composed of illegal nodes using illegal source addresses and destination addresses, and the source address is hidden in the data domain of the CAN message and is difficult to be obtained by attackers, thereby improving the security of the CAN message and enhancing the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0012] Figure 1 It is a flow chart of a message sending method provided in an embodiment of the present application.

[0013] Figure 2 It is a flow chart of a method for obtaining a CAN message in a custom format according to message information to be sent, provided in an embodiment of the present application.

[0014] Figure 3 This is a schematic diagram of the frame structure of a standard CAN message.

[0015] Figure 4 It is a schematic diagram of the frame structure of a custom format CAN message provided in an embodiment of the present application.

[0016] Figure 5 It is a schematic diagram of a method for respectively determining a first verification value and a second verification value provided in an embodiment of the present application.

[0017] Figure 6 It is a schematic diagram of a method for generating a custom format CAN message based on message information to be sent provided in an embodiment of the present application.

[0018] Figure 7 It is a flow chart of a message receiving method provided in an embodiment of the present application.

[0019] Figure 8 The present invention is a structural diagram of an ECU that implements the message sending method and the message receiving method provided in the embodiments of the present application.

[0020] Fig. 9It is a schematic diagram of a message sending device provided in an embodiment of the present application.

[0021] Fig.10 It is a schematic diagram of a message receiving device provided in an embodiment of the present application.

[0022] Fig.11 It is a schematic diagram of an electronic control unit provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0024] The following will describe in detail a message sending method and device, and a message receiving method and device according to an embodiment of the present application in conjunction with the accompanying drawings.

[0025] As mentioned above, as the most common in-vehicle communication protocol in vehicle applications, CAN has the advantages of low cost, no electrical interference, self-diagnosis and error correction.

[0026] The automotive industry has undergone tremendous changes over the past few decades, with cars becoming extensively automated and equipped with a range of sensors and computing systems. These sensors are controlled by embedded ECUs (Electronic Control Units), which are designed to optimize the management of a range of functions from engine control to ABS (Anti-lock Braking System) and ADAS (Advanced Driving Assistance System). A modern car has more than 100 ECUs, and this number is expected to increase in the future. These ECUs are distributed around the car and communicate with each other through in-car communication networks such as the CAN network.

[0027] Although CAN has many advantages, the increasing communication between and within vehicles makes CAN vulnerable to cyber attacks. The existing CAN bus built-in security features are mainly to ensure the reliability of communication, not network security. Therefore, CAN cannot prevent the vehicle network from cyber attacks.

[0028] In the related art, CAN messages are usually sent in a broadcast mode, and the source address and destination address in the message are not verified. Therefore, attackers can attack the CAN network by forging nodes to send illegal messages, thus bringing security risks to users.

[0029] For example, if a vehicle's airbag or ABS system is attacked by a cyberattack, it could endanger the safety of the driver and passengers. Or if an ECU such as the odometer of a used car is tampered with, it could also have adverse effects on consumers and vehicle suppliers.

[0030] In view of this, an embodiment of the present application provides a CAN message sending method. After obtaining the message information to be sent including the source address and the destination address, the source address and the destination address are first verified, and a custom format CAN message is generated after the verification is passed. The source address is configured in the source address field of the custom format CAN message data domain, and finally the custom format CAN message is sent. The method can identify and stop sending CAN messages composed of illegal nodes using illegal source addresses and destination addresses, and the source address is hidden in the data domain of the CAN message and is difficult to be obtained by attackers, thereby improving the security of the CAN message and enhancing the user experience.

[0031] Figure 1 FIG. 1 is a flow chart of a message sending method provided in an embodiment of the present application. Figure 1 As shown, the method comprises the following steps: In step S101, information of a message to be sent is obtained.

[0032] The message information to be sent includes at least a source address and a destination address.

[0033] In step S102, in response to determining that the source address and the destination address are verified, a custom format CAN message is obtained according to the message information to be sent.

[0034] The data field of the custom format CAN message at least includes a source address field, and the source address field includes a source address.

[0035] In step S103, a CAN message in a custom format is sent.

[0036] In some embodiments of the present application, the method may be executed by an ECU to send a CAN message. Alternatively, the method may also be executed by other network nodes in a CAN network to send a CAN message.

[0037] In certain embodiments of the present application, when the ECU needs to send a CAN message, it can obtain the message information to be sent, and the message information to be sent includes at least a source address and a destination address.

[0038] The ECU can verify the source address and the destination address in the acquired message information to be sent to determine whether the source address and the destination address are legal.

[0039] If the source address and destination address in the message information are verified, the message information to be sent can be encapsulated to obtain a custom format CAN message. The data field of the custom format CAN message at least includes a source address field, and the source address field includes the source address in the message information to be sent.

[0040] That is to say, in the data field of the custom format CAN message, in addition to the data field in the traditional standard format CAN message, an additional source address field is provided, and the source address in the message information to be sent can be written into the source address field.

[0041] In certain embodiments of the present application, the custom format CAN message may be sent, thereby achieving secure transmission of the CAN message.

[0042] According to the technical solution provided in the embodiment of the present application, after obtaining the message information to be sent including the source address and the destination address, the source address and the destination address are first verified, and then a custom format CAN message is generated after the verification is passed, and the source address is configured in the source address field of the custom format CAN message data domain, and finally the custom format CAN message is sent. It is possible to identify and stop sending CAN messages composed of illegal source addresses and destination addresses by illegal nodes, and the source address is hidden in the data domain of the CAN message and is difficult to be obtained by attackers, thereby improving the security of the CAN message and enhancing the user experience.

[0043] That is to say, in the related art, CAN messages of small vehicles such as cars are usually standard format CAN messages, whose CANID (CAN Identify, message identification) includes 11 bits, which are used to represent the request ID or response ID of the CAN message. If the CAN message is a request message sent by a certain ECU, the CANID is the request ID of the ECU. If the CAN message is a response message sent by the ECU, the CANID is the response ID of the ECU. Usually, the difference between the response ID and the request ID is a fixed value.

[0044] After an attacker learns the request ID or response ID of an ECU, it is easy for him to use the request ID or response ID to forge CAN messages, thus bringing great security risks to the CAN network.

[0045] By adopting the technical solution of the embodiment of the present application, the source address and destination address in the message information to be sent are first verified before the CAN message is generated. Only after the verification is passed, the CAN message of the custom format is generated, thereby preventing the attacker from using illegal source addresses and destination addresses to generate illegal messages. At the same time, the source address of the CAN message is hidden in the data domain, so that the attacker cannot obtain the request ID and response ID of each network node by parsing the CANID, and thus cannot use the legal source address to generate illegal messages.

[0046] Figure 2 1 is a flow chart of a method for obtaining a CAN message in a custom format according to the message information to be sent provided in an embodiment of the present application. Figure 2 As shown, the method comprises the following steps: In step S201, in response to determining that the source address and the destination address are verified, the message information to be sent is encrypted.

[0047] In step S202, a first check value is obtained according to the encrypted message information to be sent.

[0048] In step S203, a CAN message in a user-defined format is generated.

[0049] The data field of the custom format CAN message also includes a first check bit field, and the first check bit field includes a first check value.

[0050] In some embodiments of the present application, the message information to be sent can be encapsulated to obtain a CAN message in a custom format, wherein the message information to be sent can also include message length, message data, and the like.

[0051] After the source address and the destination address are verified and before the message information to be sent is encapsulated, the message information to be sent can be encrypted first to further improve security. After the encryption is completed, a first check value can also be generated based on the encrypted message information to be sent. In one example, the first check value can be a CRC (Cyclic Redundancy Check) value, or other check values, which are not limited here.

[0052] In some embodiments of the present application, other fields of the custom format CAN message except the data field can be filled according to the message information to be sent. In the data field of the custom format CAN message, the source address field, the first check bit field and the data field can be set, wherein the source address field is written with the encrypted source address, the first check bit field is written with the first check value, and the data field is written with the message data in the message information to be sent. In this way, the encapsulation of the custom format CAN message can be completed.

[0053] In the related art, the priority of sending and receiving CAN messages is determined by the CANID sequence number. The smaller the CANID sequence number, the higher the priority. This priority determination method may be exploited by attackers to implement DOS (Denial Of Service) attacks by modifying the CANID sequence number in the message identifier. For example, sending small sequence number CANID messages at a high frequency will cause low-priority CAN messages to be unable to be transmitted, thereby causing network abnormalities.

[0054] In view of this, the embodiment of the present application can define a priority in the message information to be sent, and the sending and receiving of the CAN message are performed based on the defined priority, thereby effectively avoiding DOS attacks.

[0055] In some embodiments of the present application, the message information to be sent may also include a priority, which is used to indicate the order of sending or receiving different CAN messages. The custom format CAN message data field also includes a priority field, which includes a priority.

[0056] In other words, you can customize the priorities of different CAN messages, for example, set a higher priority for CAN messages related to the power domain and chassis domain, and set a lower priority for CAN messages related to IVI (In-Vehicle Infotainment). The priorities of different messages can be set according to actual conditions, and there is no restriction here.

[0057] The priority can be encapsulated in a custom format CAN message as message information to be sent, and the priority can be written into the priority field of the data domain of the custom format CAN message during encapsulation.

[0058] When sending a message, the ECU can determine whether there are multiple CAN messages to be sent after completing the encapsulation of the custom format CAN message. If not, that is, there is only one CAN message to be sent, the custom format CAN message is directly sent.

[0059] On the contrary, if there are multiple CAN messages to be sent, the priority of each CAN message is extracted. In one example, the priority can be extracted from the priority field of the data field of each CAN message, and then the CAN message with the highest priority is determined and sent first. This iterative operation is performed until all CAN messages are sent.

[0060] In the related art, a specific address can be pre-configured as a default broadcast address, and the default broadcast address is set as the destination address of the CAN message. At this time, if the default broadcast address is leaked, an attacker can easily use the default broadcast address to forge a CAN message, which is less secure.

[0061] In view of this, the default broadcast address used to characterize the destination address is no longer set in the CAN message of the embodiment of the present application, and the message is sent in unicast or broadcast mode by the broadcast tag. If the broadcast tag identifies that this CAN message is sent in unicast mode, the destination address is the unicast destination address, that is, the address of the CAN network node that receives this CAN message. If the broadcast tag identifies that this CAN message is sent in broadcast mode, the destination address can be empty, or any unicast address that is not the default broadcast address. For example, if the default broadcast address is set to 0x7ff, the destination address of the CAN message can be empty, or any other unicast address except 0x7ff.

[0062] That is, in some embodiments of the present application, the message information to be sent may also include a broadcast tag, which is used to identify that the CAN message is sent in unicast or broadcast mode. The custom format CAN message data field also includes a broadcast tag field, and the broadcast tag field includes a broadcast tag. At the same time, the message identification field of the custom format CAN message includes the destination address of the CAN message to be sent. Among them, when the broadcast tag is unicast, the destination address is a unicast destination address; when the broadcast tag is broadcast, the destination address is empty or any unicast address that is not the default broadcast address, or a specified unused address.

[0063] In this way, by hiding the broadcast tag in the data field and setting the destination address to empty or to any unicast address that is not the default broadcast address when the broadcast tag is set to broadcast, attackers cannot parse the CANID or the default broadcast address after intercepting the CAN message, nor can they use the default broadcast address to forge messages, further improving the security of CAN message transmission and privacy protection.

[0064] In some embodiments of the present application, determining that the source address and the destination address have passed verification may include obtaining a pre-stored legal source address set and a legal destination address set from a trusted zone; in response to determining that the source address is an address in the legal source address set and the destination address is an address in the legal destination address set, determining that the source address and the destination address have passed verification.

[0065] That is to say, the legal source address set and destination address set of this CAN network can be pre-stored in the trusted area of ​​ECU, where the legal source address set is the address set of all ECUs in this CAN network that can be used as source addresses, and the legal destination address set is the address set of all ECUs in this CAN network that can be used as destination addresses.

[0066] When verifying the source address and destination address in the message to be sent, the source address can be used to query the legal source address set, and the destination address can be used to query the legal destination address set. If it is determined that the source address is an address in the legal source address set, and the destination address is an address in the legal destination address set, then it is determined that the source address and destination address verification pass.

[0067] In some other embodiments, a legal communication link set may be pre-stored in the trusted area of ​​the ECU, and the legal communication link set is the communication links from all legal source addresses to destination addresses in the CAN network. At this time, the source address and the destination address in the message information to be sent may be verified, if it is determined that the source address is an address in the legal source address set, the destination address is an address in the legal destination address, and the communication link from the source address to the destination address is a communication link in the legal communication link set, then it is determined that the source address and the destination address have been verified.

[0068] For example, if in this CAN network, ECU1 can be used as the source address, ECU2 and ECU3 can both be used as the destination address, and the communication link from ECU1 to ECU2 is a legal communication link, and the communication link from ECU1 to ECU3 is not a legal communication link. At this time, in the trusted area of ​​each network node (such as ECU) of this CAN network, ECU1 can be saved in the legal source address set, ECU2 and ECU3 can be saved in the legal destination address set, and the communication link from ECU1 to ECU2 can be saved in the legal communication link set.

[0069] If the source address in the message to be sent is ECU1 and the destination address is ECU2, at this time, since ECU1 is an address in the legal source address set, ECU2 is an address in the legal destination address set, and the communication link from ECU1 to ECU2 is a communication link in the legal communication link set, the verification of the source address and destination address passes.

[0070] If the source address in the message to be sent is ECU1 and the destination address is ECU3, at this time, since ECU1 is an address in the legal source address set and ECU3 is an address in the legal destination address set, but the communication link from ECU1 to ECU3 is not a communication link in the legal communication link set, the verification of the source address and destination address fails.

[0071] If the source address in the message to be sent is ECU1, the destination address is ECU4, and ECU4 is not an address in the legal destination address set, the verification of the source address and the destination address will also fail.

[0072] Figure 3 This is a schematic diagram of the frame structure of a standard CAN message. Figure 3As shown in the figure, the standard format CAN message may include a CANID, which may be a request ID or a response ID. The request ID may be the default broadcast address for each ECU to send CAN messages, and the response ID may be the address for each ECU to receive request responses. For the same ECU, the response ID is usually a request ID plus a preset value, such as 0x40. Knowing the request ID of the ECU also means knowing its response ID, which is less secure.

[0073] The standard format CAN message may also include the message length (DLC), the frame type and data length in the diagnostic protocol control information (DoCAN PCI), the data field and the CRC check value. Among them, the data field can carry the message data of the CAN message. The CRC check value is obtained by performing CRC calculation on each field in the standard format CAN message.

[0074] Figure 4 : is a schematic diagram of the frame structure of a custom format CAN message provided in an embodiment of the present application. Figure 4 As shown in the figure, in the custom format CAN message, the DLC field and the DoCAN PCI field are the same as those in the standard format. The CANID of the custom format CAN message is no longer configured as a request ID or a response ID, but is directly written to the destination address. The destination address can be empty or a unicast address.

[0075] The data field of the custom format CAN message may include multiple fields, such as a source address field, a priority field, a broadcast flag field, a CRC field, and a data field. Among them, the source address field includes the source address of the CAN message, and the priority field includes the priority of the CAN message.

[0076] If the value in the broadcast flag field is false, the address in the CANID can be a unicast destination address, and the CAN message can be sent directly to the destination address in a unicast manner. If the value in the broadcast flag field is true, the address in the CANID can be empty or any unicast address that is not the default broadcast address, and the CAN message can be sent in a broadcast manner.

[0077] The CRC field in the data domain may be referred to as a first CRC field, and the first CRC field includes a first check value, and the first check value is obtained by performing CRC calculation on the destination address, source address, message length, priority, broadcast flag, and message data of the present CAN message. In some implementations, the destination address, source address, message length, priority, broadcast flag, and message data of the present CAN message may be first encrypted, and then the encrypted information may be subjected to CRC calculation to obtain the first check value.

[0078] Among them, when the broadcast mark in the data field is broadcast, since the destination address can be empty or any unicast address that is not the default broadcast address, the destination address has no valid meaning at this time. Therefore, the first check value can be obtained by performing CRC calculation on the source address, message length, priority, broadcast mark and message data of this CAN message.

[0079] The custom format CAN message may further include a second CRC field, which is located after the data field and includes a second check value, which is obtained by performing a CRC calculation on all contents in the CAN message except the second CRC field.

[0080] Figure 5 is a schematic diagram of a method for determining a first check value and a second check value respectively provided in an embodiment of the present application. Figure 5 As shown, when encapsulating the message information to be sent into a custom format CAN message, the destination address, source address, message length, priority, broadcast mark and message data can be first encrypted, and then the encrypted information is CRC calculated to obtain a first check value. Then, the CANID, DLC, DoCAN PCI, data field and other fields in the custom format CAN message are CRC calculated to obtain a second check value. Among them, the values ​​of each field in the data field, including the source address, priority, broadcast mark, first CRC and message data, are all involved in the CRC calculation.

[0081] Figure 6 Schematic diagram of a method for generating a custom format CAN message based on the message information to be sent provided by an embodiment of the present application. Figure 6 As shown, the message information to be sent may include a destination address, a source address, a message length, a priority, a broadcast flag, and message data.

[0082] First, the message information to be sent can be encapsulated into a custom format CAN message. During encapsulation, the destination address can be written into the CANID field, the message length can be written into the DLC field, the frame type and data length information related to the diagnosis can be obtained and written into the DoCANPCI field, the source address can be written into the source address field in the data field, the priority can be written into the priority field in the data field, the broadcast tag can be written into the broadcast tag field in the data field, the message data can be written into the data field in the data field, and the first check value can be calculated and written into the CRC field in the data field. Finally, the CRC value of all fields in the full text can be calculated as the second check value and written into the CRC field after the data field.

[0083] In the encapsulated custom format CAN message, the CANID field can be 11 bits, the DLC field can be 4 bits, the frame type can be 4 bits, the data length can be 4 bits, the data field can include 0 to 8 bytes, among which the source address field can be 11 bits, the priority field can be 4 bits, the broadcast flag field can be 1 bit, and the CRC check field can be 1 byte.

[0084] The custom format CAN message is basically the same as the standard format CAN message. Figure 6 As shown in the figure, the data field of the custom format CAN message corresponds to the data of the standard format CAN message, the difference is that the data field of the standard format CAN message does not have multiple fields and is only used to write data. Different from this, in the custom format CAN message, the source address, priority, broadcast flag and first check value are also recorded in the data field as message data.

[0085] In addition, the CANID of the custom format CAN message records the destination address in the message information to be sent, while the CANID of the standard format CAN message records the request ID or response ID. The contents of other fields in the standard format CAN message are the same as those in the custom format CAN message.

[0086] Figure 7 Schematic diagram of a message receiving method provided in an embodiment of the present application. Figure 7 As shown, the method comprises the following steps: In step S701, a CAN message is received.

[0087] In step S702, the source address, priority and broadcast flag are obtained from the data field of the CAN message.

[0088] In step S703, in response to determining that the priority is the highest priority among the CAN messages to be received, the CAN message sending type is determined according to the broadcast tag.

[0089] In step S704, in response to determining that the CAN message is a unicast message according to the broadcast tag, a destination address is obtained from the message identifier of the CAN message.

[0090] In step S705 , in response to determining that the CAN message has passed verification based on the source address and the destination address, and determining that the destination address is the address of the network node receiving the CAN message, the CAN message is parsed to obtain message data.

[0091] In step S706, in response to determining that the CAN message is a broadcast message according to the broadcast tag and determining that the CAN message passes verification based on the source address, the CAN message is parsed to obtain message data.

[0092] In some embodiments of the present application, the method may be executed by an ECU to receive a CAN message. Alternatively, the method may also be executed by other network nodes in a CAN network to receive a CAN message.

[0093] In some embodiments of the present application, the ECU may receive a CAN message, wherein the received CAN message is a CAN message in a custom format.

[0094] The ECU can filter the custom format CAN message and obtain the source address, priority and broadcast flag from its data field.

[0095] The acquired CAN message can be verified to determine whether the CAN message is complete and legal. In one example, the CAN message can be first verified according to a second verification value of the CAN message, the second verification value is obtained from a second verification bit of the CAN message, and the second verification bit is the end verification bit of the CAN message.

[0096] If the CAN message is determined to be complete and legal, the priority of the CAN message can be determined. If there is only one CAN message to be parsed, the CAN message can be parsed directly. If there are multiple CAN messages to be parsed, the priorities of the CAN messages to be parsed can be compared, and each message can be received in order from high to low priority.

[0097] If it is determined that the priority of the current CAN message is the highest priority among the CAN messages to be parsed, the current CAN message can be parsed. During parsing, the sending type of the current CAN message can be determined based on the broadcast tag obtained from the data field.

[0098] If the CAN message is determined to be a unicast message according to the broadcast mark, the destination address can be obtained from the CANID of the CAN message, and then the CAN message can be verified again. When verifying again, the message information of the CAN message can be verified according to the first check value of the CAN message, and the first check value is obtained from the first check bit of the CAN message, and the first check bit is the check bit in the data field of the CAN message, and the first check bit is calculated using the destination address, source address, message length, priority, broadcast mark and message data.

[0099] If the first check value is checked, the destination address and the source address may be checked for legitimacy to determine whether the destination address and the source address are legal. In some implementations, the priority in the message information may also be verified to determine whether the priority is correct.

[0100] In one example, the destination address, source address and priority can be compared with the legal destination address, source address and priority information pre-stored in the ECU trusted area. If it is determined that the destination address and source address in the message information are both legal addresses, the communication link from the source address to the destination address is a legal link, and the message priority between the source address and the destination address also matches the pre-stored priority, then it can be determined that the destination address and source address are legal.

[0101] After the above checks are passed, it can also be determined whether the destination address is the same as the address of the network node receiving the CAN message. If so, the network node can parse the CAN message to obtain the message data.

[0102] On the other hand, if the CAN message is determined to be a broadcast message according to the broadcast mark, the second check value can also be checked first, and the first check value can be checked after the check passes. After the above checks pass, the CAN message is parsed to obtain the message data.

[0103] By adopting the technical solution provided in the embodiment of the present application, after receiving a CAN message, the data field is first parsed to obtain the source address, priority and broadcast mark. Under the condition that the CAN message needs to be parsed according to the priority, the unicast message and the broadcast message are verified in different ways according to the broadcast mark, and the CAN message is parsed to obtain the message data after the verification passes. This can improve the security of CAN message reception and avoid DOS attacks.

[0104] Figure 8 The present invention is a schematic diagram of the structure of an ECU that implements the message sending method and message receiving method provided in the embodiment of the present application. Figure 8 As shown, the ECU can be configured as a CAN message sending node or a CAN message receiving node.

[0105] When the ECU is configured as a CAN message sending node, it can call the application layer, message encapsulation module, message scheduling module, message sending module and physical layer in sequence to send CAN messages. In the trusted area of ​​the ECU, an address list monitoring module, an encryption and decryption module and an intrusion detection module can also be configured. The address list monitoring module is used to monitor the legitimacy of the source address and destination address of the CAN message to be sent, the encryption and decryption module is used to encrypt the message information, and the intrusion detection module is used to detect whether there is an illegal intrusion message.

[0106] For example, in the CAN message provided in the embodiment of the present application, the CANID is either a unicast destination address, or an arbitrary unicast address, or is empty, rather than a traditional default broadcast address. Therefore, if the intrusion detection module detects that the CANID of the CAN message is the default broadcast address, an alarm message can be directly generated, and if necessary, the CAN message sending thread can be directly cleared to ensure the security of CAN network communication.

[0107] A CRC calculation module may also be configured in the ECU module as a sending node to perform CRC calculation on the message information of the CAN message and the message as a whole to obtain a CRC check value.

[0108] When the ECU is configured as a CAN message receiving node, it can call the physical layer, message filtering module, message receiving module, message decapsulation module and application layer in sequence to receive CAN messages. The address list monitoring module, encryption and decryption module and intrusion detection module can also be configured in the trusted area of ​​the ECU as a receiving node. The address list monitoring module is used to monitor the legitimacy of the source address and destination address of the received CAN message, the encryption and decryption module is used to decrypt the message information, and the intrusion detection module is used to detect whether there is an illegal intrusion message.

[0109] A CRC calculation module can also be configured in the ECU module serving as a receiving node to perform CRC verification on the received CAN message.

[0110] The legal ECU addresses, encryption and decryption algorithms, and intrusion detection algorithms can be stored in the trusted area of ​​the ECU according to the actual configuration.

[0111] When sending a CAN message, the address list monitoring module can be called first to verify the source address and destination address, and after the verification, the message information including the legal address is encrypted and CRC calculated, and then the calculation result is sent to the message encapsulation module for encapsulation.

[0112] The message encapsulation module can encapsulate the message information into a custom format CAN message, and perform CRC calculation on the encapsulated CAN message again to ensure the integrity and correctness of the data. Subsequently, the custom format CAN message can be sent to the message scheduling module for processing.

[0113] If the message scheduling module receives only one message, it will directly forward the message. On the other hand, if the message scheduling module receives multiple messages, it can schedule and forward them according to the message priority. The message priority can be obtained from the priority field of the custom format CAN message data field, and the priority is set according to actual needs.

[0114] This method replaces the traditional CAN message forwarding method of determining the priority based on the CANID number, thereby preventing attackers from using small CANID numbers to obtain the highest priority for malicious forwarding, thereby causing system abnormalities.

[0115] After the scheduling is completed, the CAN message in the user-defined format may be sent to the message sending module, which sends the CAN message in the user-defined format to the destination address.

[0116] When receiving CAN messages, the message filtering module first receives the custom format CAN message from the physical layer, and performs CRC integrity check, source address and destination address legitimacy verification on the received message. If the verification result is that the message is illegal, the message is directly discarded. If the verification result is that the message is legal, the custom format CAN message is received by the message receiving module.

[0117] The message receiving module can send the custom format CAN message to the message decapsulation module. The message decapsulation module decrypts the received custom format CAN message and obtains the source address, broadcast tag and priority from the decrypted message information. The calling address list monitoring module can verify the source address and priority or the source address, destination address and priority according to the different values ​​of the broadcast tag. If it is illegal, it will be discarded. If it is legal, it will be sent to the application layer for business processing.

[0118] The intrusion detection module can monitor the real-time terminal for messages with very small CANID numbers (such as less than the preset threshold) and whose destination addresses are not in the address whitelist set by the address list monitoring module, and detect DOS attack messages in time. If a message with a very small CANID number and a destination address not in the address whitelist set by the address list monitoring module is detected, the intrusion detection module can continue to detect whether the source address of the message is in the whitelist, and whether the priority of the source address and the destination address matches the priority in the whitelist. If they match, it is determined to be a legitimate message. Otherwise, an alarm message can be generated, and the sending and receiving of the message can be suppressed when appropriate.

[0119] On the other hand, the intrusion detection module can also monitor the abnormal frequency of sending periodic messages. When the message causes the bus complexity to exceed the preset load threshold, it can meet the message sending and receiving of functional safety related ECUs to a limited extent. Among them, functional safety related ECUs can be, for example, power domain ECUs, chassis domain ECUs, etc.

[0120] By adopting the technical solution of the embodiment of the present application, the transmission is authenticated based on the source address and the destination address, instead of the broadcast transmission of the original CAN network, so that the message that does not include the source address and the destination address is sent to the bus in the form of broadcast, and any node can receive the security risks and privacy leakage risks. At the same time, the message priority transmission is designed in the message to avoid the DOS attack by only modifying the identifier when the network is invaded by a malicious attacker, resulting in the inability to transmit low-priority messages. In addition, by setting the broadcast mark in the data field and the CANID setting the unicast address, the unicast and broadcast of the CAN message can be realized on the basis of ensuring safety performance.

[0121] On the other hand, the ECU address and encryption and decryption are placed in a trusted environment, the message is transmitted in an encrypted manner and the legitimacy of the ECU address is judged, which reduces the risk of data in the message being attacked and ensures the protection capability of the CAN network.

[0122] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present application, which will not be described one by one here.

[0123] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0124] Fig. 9 Schematic diagram of a message sending device provided in an embodiment of the present application. Fig. 9 As shown, the device comprises: The acquisition module 901 is configured to acquire information of a message to be sent; the information of the message to be sent at least includes a source address and a destination address.

[0125] The encapsulation module 902 is configured to obtain a custom format CAN message according to the message information to be sent in response to determining that the source address and the destination address are verified; the data field of the custom format CAN message includes at least a source address field, and the source address field includes a source address.

[0126] The sending module 903 is configured to send a CAN message in a custom format.

[0127] According to the technical solution provided in the embodiment of the present application, after obtaining the message information to be sent including the source address and the destination address, the source address and the destination address are first verified, and then a custom format CAN message is generated after the verification is passed, and the source address is configured in the source address field of the custom format CAN message data domain, and finally the custom format CAN message is sent. It is possible to identify and stop sending CAN messages composed of illegal source addresses and destination addresses by illegal nodes, and the source address is hidden in the data domain of the CAN message and is difficult to be obtained by attackers, thereby improving the security of the CAN message and enhancing the user experience.

[0128] In some embodiments, a custom format CAN message is obtained based on the message information to be sent, including: in response to determining that the source address and the destination address are verified, encrypting the message information to be sent; obtaining a first check value based on the encrypted message information to be sent; generating a custom format CAN message; the data field of the custom format CAN message also includes a first check bit field, and the first check bit field includes a first check value.

[0129] In some implementations, the message information to be sent also includes a priority, and the priority is used to indicate the order of sending or receiving different CAN messages; the custom format CAN message data field also includes a priority field, and the priority field includes a priority.

[0130] In some implementations, the message information to be sent also includes a broadcast tag, which is used to identify whether the CAN message is sent in unicast or broadcast mode; the custom format CAN message data field also includes a broadcast tag field, which includes a broadcast tag; the message identification field of the custom format CAN message includes the destination address.

[0131] In some embodiments, the message identification field of the custom format CAN message includes a destination address; in response to determining that the broadcast tag identifies that the present CAN message is sent in unicast mode, the destination address is a unicast destination address; the step of determining that the source address and the destination address verification have passed is to determine that the source address, the destination address, and the communication link between the source address and the destination address are all legal; in response to determining that the broadcast tag identifies that the present CAN message is sent in broadcast mode, the destination address is empty, or is any unicast address except the system default broadcast address; the step of determining that the source address and the destination address verification have passed is to determine that the source address is legal and the source address can be used as a broadcast address.

[0132] Fig.10 Schematic diagram of a message receiving device provided in an embodiment of the present application. Fig.10 As shown, the device comprises: The receiving module 1001 is configured to receive CAN messages.

[0133] The acquisition module 1002 is configured to acquire the source address, priority and broadcast flag from the data field of the CAN message.

[0134] The parsing module 1003 is configured to determine the CAN message sending type according to the broadcast mark in response to determining that the priority is the highest priority among the CAN messages to be parsed.

[0135] The parsing module 1003 is also configured to, in response to determining that the CAN message is a unicast message based on the broadcast mark, obtain the destination address from the message identifier of the CAN message; in response to determining that the CAN message verification has passed based on the source address and the destination address, and determining that the destination address is the address of the network node receiving the CAN message, parse the CAN message to obtain the message data.

[0136] The parsing module 1003 is further configured to, in response to determining that the CAN message is a broadcast message according to the broadcast tag and determining that the CAN message passes verification based on the source address, parse the CAN message to obtain message data.

[0137] In some embodiments, determining that a CAN message has passed verification includes: verifying the CAN message according to a second check value of the CAN message; the second check value is obtained from a second check bit of the CAN message, and the second check bit is the end check bit of the CAN message; in response to determining that the CAN message has passed verification, verifying the message information of the CAN message according to a first check value of the CAN message; the first check value is obtained from a first check bit of the CAN message, and the first check bit is a check bit in a data field of the CAN message; the message information includes a destination address, a source address, a message length, a priority, a broadcast flag, and message data; in response to determining that the message information has passed verification, performing a validity check on the destination address and the source address; in response to determining that the validity check of the destination address and the source address has passed, determining that the CAN message has passed verification.

[0138] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0139] Fig.11 Schematic diagram of an electronic control unit provided in an embodiment of the present application. Fig.11 As shown, the electronic control unit 11 of this embodiment includes: a processor 1101, a memory 1102, and a computer program 1103 stored in the memory 1102 and executable on the processor 1101. When the processor 1101 executes the computer program 1103, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 1101 executes the computer program 1103, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0140] The electronic control unit 11 may be an electronic control unit such as a desktop computer, a notebook, a palm computer, or a cloud server. The electronic control unit 11 may include but is not limited to a processor 1101 and a memory 1102. Those skilled in the art will appreciate that Fig.11The electronic control unit 11 is merely an example and does not limit the electronic control unit 11 , and may include more or less components than those shown in the figure, or different components.

[0141] The processor 1101 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0142] The memory 1102 may be an internal storage unit of the electronic control unit 11, for example, a hard disk or memory of the electronic control unit 11. The memory 1102 may also be an external storage device of the electronic control unit 11, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic control unit 11. The memory 1102 may also include both an internal storage unit of the electronic control unit 11 and an external storage device. The memory 1102 is used to store computer programs and other programs and data required by the electronic control unit.

[0143] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0144] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0145] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A message sending method, characterized in that: The message is a controller area network (CAN) message, and the method comprises: Obtaining information of a message to be sent; the message information to be sent includes at least a source address and a destination address; In response to determining that the source address and the destination address are verified, a custom format CAN message is obtained according to the message information to be sent; the data field of the custom format CAN message includes at least a source address field, and the source address field includes the source address; Send the custom format CAN message.

2. The method according to claim 1, characterized in that Obtaining a custom format CAN message according to the message information to be sent, including: In response to determining that the source address and the destination address are verified, encrypting the message information to be sent; Obtaining a first check value according to the encrypted message information to be sent; Generate a custom format CAN message; the data field of the custom format CAN message also includes a first check bit field, and the first check bit field includes the first check value.

3. The method according to claim 1, characterized in that The message information to be sent also includes a priority, and the priority is used to indicate the order of sending or receiving different CAN messages; The user-defined format CAN message data field also includes a priority field, and the priority field includes the priority.

4. The method according to claim 1, characterized in that The message information to be sent also includes a broadcast mark, and the broadcast mark is used to identify whether the CAN message is sent in a unicast mode or a broadcast mode; The custom format CAN message data field also includes a broadcast tag field, and the broadcast tag field includes the broadcast tag; The message identification field of the self-defined format CAN message includes the destination address; In response to determining that the broadcast tag identifies that the CAN message is sent in a unicast manner, the destination address is a unicast destination address; In response to determining that the broadcast tag identifies that the present CAN message is sent in a broadcast manner, the destination address is empty or is any unicast address other than a default broadcast address.

5. The method according to claim 1, characterized in that Determining that the source address and the destination address pass verification includes: Obtaining a pre-stored legal source address set and a legal destination address set from the trusted zone; In response to determining that the source address is an address in the set of legal source addresses and the destination address is an address in the set of legal destination addresses, it is determined that the source address and the destination address have passed verification.

6. A message receiving method, characterized in that: The message is a controller area network (CAN) message, and the method comprises: Receive CAN messages; Obtaining a source address, a priority, and a broadcast flag from a data field of the CAN message; In response to determining that the priority is the highest priority among the CAN messages to be parsed, determining the CAN message sending type according to the broadcast tag; In response to determining that the CAN message is a unicast message according to the broadcast tag, obtaining a destination address from a message identifier of the CAN message; In response to determining that the CAN message passes verification based on the source address and the destination address, and determining that the destination address is an address of a network node receiving the CAN message, parsing the CAN message to obtain message data; or In response to determining that the CAN message is a broadcast message according to the broadcast tag and determining that the CAN message passes verification based on the source address, the CAN message is parsed to obtain message data.

7. The method according to claim 6, characterized in that Determining that the CAN message verification passes includes: Verifying the CAN message according to a second check value of the CAN message; the second check value is obtained from a second check bit of the CAN message, and the second check bit is an end check bit of the CAN message; In response to determining that the CAN message passes verification, verifying the message information of the CAN message according to a first verification value of the CAN message; the first verification value is obtained from a first check bit of the CAN message, and the first check bit is a check bit in the data field of the CAN message; the message information includes a destination address, a source address, a message length, a priority, a broadcast flag, and message data; In response to determining that the message information verification passes, performing a validity check on a destination address and a source address of a unicast CAN message, or performing a validity check on a source address of a broadcast CAN message; In response to determining that the validity check of the destination address and the source address of the unicast CAN message passes, or in response to determining that the validity check of the source address of the broadcast CAN message passes, it is determined that the CAN message passes the verification.

8. A message sending device, characterized in that: The message is a controller area network (CAN) message, and the device comprises: An acquisition module is configured to acquire information of a message to be sent; the information of the message to be sent at least includes a source address and a destination address; An encapsulation module is configured to obtain a custom format CAN message according to the message information to be sent in response to determining that the source address and the destination address are verified; The data field of the self-defined format CAN message includes at least a source address field, and the source address field includes the source address; The sending module is configured to send the CAN message in the custom format.

9. A message receiving device, characterized in that: The message is a controller area network (CAN) message, and the device comprises: A receiving module, configured to receive CAN messages; An acquisition module is configured to acquire a source address, a priority and a broadcast flag from a data field of the CAN message; A parsing module, configured to determine the CAN message sending type according to the broadcast mark in response to determining that the priority is the highest priority among the CAN messages to be parsed; In response to determining that the CAN message is a unicast message according to the broadcast tag, obtaining a destination address from a message identifier of the CAN message; In response to determining that the CAN message passes verification based on the source address and the destination address, and determining that the destination address is an address of a network node receiving the CAN message, parsing the CAN message to obtain message data; or In response to determining that the CAN message is a broadcast message according to the broadcast tag and determining that the CAN message passes verification based on the source address, the CAN message is parsed to obtain message data.

10. An electronic control unit, characterized in that: The electronic control unit is configured to perform the steps of the method according to any one of claims 1 to 7.

Images