Message Sending Method, Receiving Method, Sending Device, Receiving Device and ECU

Abstract

The present application relates to the field of communication technologies, and provides a message sending method, a receiving method, a sending device, a receiving device, and an ECU. After obtaining the message information to be sent including the source address and the destination address, the method first verifies the source address and the destination address. After the verification passes, a custom format CAN message is generated, the source address is configured in the source address field of the data field of the custom format CAN message, and finally the custom format CAN message is sent. It can 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 field of the CAN message and is difficult for attackers to obtain, thereby improving the security of the CAN message and enhancing the user experience.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a method for sending a message, a method for receiving a message, 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 advantages such as low cost, immunity to electrical interference, self-diagnosis, and error correction.

[0003] However, in related technologies, CAN messages are usually sent in a broadcast manner, and the source address and destination address in the message are not verified. Therefore, an attacker can attack the CAN network by sending illegal messages through a forged node, thus bringing security risks to users. Summary of the Invention

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

[0005] In the first aspect of the embodiments of this application, a method for sending a message is provided. The message is a Controller Area Network (CAN) message, and the method includes:

[0006] Obtain message information to be sent; the message information to be sent includes at least a source address and a destination address;

[0007] In response to determining that the source address and destination address pass the verification, obtain a custom-format CAN message according to the message information to be sent; at least a source address field including the source address is included in the data field of the custom-format CAN message;

[0008] Send the custom-format CAN message.

[0009] In the second aspect of the embodiments of this application, a method for receiving a message is provided. The message is a Controller Area Network (CAN) message, and the method includes:

[0010] Receive a CAN message;

[0011] Obtain the source address, priority, and broadcast flag from the data field of the CAN message;

[0012] In response to determining that the priority is the highest priority in the CAN message to be parsed, determine the CAN message sending type according to the broadcast flag;

[0013] In response to determining that the CAN message is a unicast message according to the broadcast flag, obtain the destination address from the message identifier of the CAN message;

[0014] In response to determining that the CAN message passes the verification based on the source address and the destination address, and determining that the destination address is the network node address for receiving the CAN message, parse the CAN message to obtain the message data; or

[0015] In response to determining that the CAN message is a broadcast message according to the broadcast flag, and determining that the CAN message passes the verification based on the source address, parse the CAN message to obtain the message data.

[0016] In a third aspect of the embodiments of the present application, a message sending device is provided. The message is a Controller Area Network (CAN) message, and the device includes:

[0017] An obtaining module, configured to obtain information of a message to be sent; the information of the message to be sent includes at least a source address and a destination address;

[0018] An encapsulating module, configured to, in response to determining that the source address and the destination address pass the verification, obtain a CAN message in a custom format according to the information of the message to be sent; at least a source address field including the source address is included in the data field of the CAN message in the custom format;

[0019] A sending module, configured to send the CAN message in the custom format.

[0020] In a fourth aspect of the embodiments of the present application, a message receiving device is provided. The message is a Controller Area Network (CAN) message, and the device includes:

[0021] A receiving module, configured to receive a CAN message;

[0022] An obtaining module, configured to obtain a source address, a priority, and a broadcast flag from the data field of the CAN message;

[0023] An analyzing module, configured to, in response to determining that the priority is the highest priority in the CAN message to be analyzed, determine the CAN message sending type according to the broadcast flag;

[0024] In response to determining that the CAN message is a unicast message according to the broadcast flag, obtain the destination address from the message identifier of the CAN message;

[0025] In response to determining that the CAN message passes the verification based on the source address and the destination address, and determining that the destination address is the network node address for receiving the CAN message, parse the CAN message to obtain the message data; or

[0026] In response to determining that the CAN message is a broadcast message according to the broadcast flag, and determining that the CAN message passes the verification based on the source address, parse the CAN message to obtain the message data.

[0027] In a fifth aspect of the embodiments 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 described above.

[0028] The beneficial effects of the embodiments of the present application compared with the prior art are as follows: 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. After the verification passes, a custom format CAN message is generated. The source address is configured in the source address field of the data field of the custom format CAN message, and finally the custom format CAN message is sent. It can 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 field 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

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0030] Figure 1 It is a schematic flowchart of a message sending method provided by the embodiments of the present application.

[0031] Figure 2 It is a schematic flowchart of a method for obtaining a custom format CAN message according to the message information to be sent provided by the embodiments of the present application.

[0032] Figure 3 It is a schematic diagram of the frame structure of a standard format CAN message.

[0033] Figure 4 It is a schematic diagram of the frame structure of a custom format CAN message provided by the embodiments of the present application.

[0034] Figure 5 It is a schematic diagram of a method for respectively determining a first check value and a second check value provided by the embodiments of the present application.

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

[0036] Figure 7 It is a schematic flowchart of a message receiving method provided by the embodiments of the present application.

[0037] Figure 8It is a schematic structural diagram of an ECU for implementing the message sending method and message receiving method provided by the embodiments of the present application.

[0038] Figure 9 It is a schematic diagram of a message sending device provided by the embodiments of the present application.

[0039] Figure 10 It is a schematic diagram of a message receiving device provided by the embodiments of the present application.

[0040] Figure 11 It is a schematic diagram of an electronic control unit provided by the embodiments of the present application. Detailed implementation manners

[0041] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system architectures and technologies are presented to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can 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 avoid unnecessary details from interfering with the description of the present application.

[0042] The message sending method and device according to the embodiments of the present application, as well as the message receiving method and device, will be described in detail below with reference to the accompanying drawings.

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

[0044] In the past few decades, the automotive industry has undergone earth-shaking changes. Automobiles have achieved extensive automation and are equipped with a series of sensors and computing systems. These sensors are controlled by embedded ECUs (Electronic Control Units), which are designed to optimize the management of a series of functions from engine control to ABS (Anti-lock Braking System) and ADAS (Advanced Driving Assistance System). The number of ECUs in a modern car exceeds 100, and this number is expected to increase in the future. These ECUs are distributed around the car and communicate with each other through in-vehicle communication networks such as CAN networks.

[0045] Although CAN has many advantages, the increasing inter-vehicle and intra-vehicle communications make CAN vulnerable to network attacks. The existing built-in security functions of the CAN bus are mainly for ensuring reliable communication rather than network security. Therefore, CAN cannot prevent in-vehicle networks from being attacked by networks.

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

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

[0048] In view of this, the embodiments of the present application provide a method for sending CAN messages. After obtaining the message information to be sent including the source address and destination address, the source address and destination address are first verified. After the verification passes, a CAN message in a custom format is generated. The source address is configured in the source address field of the data field of the CAN message in the custom format, and finally the CAN message in the custom format is sent. It can 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 field of the CAN message and is difficult for attackers to obtain, thereby improving the security of CAN messages and enhancing the user experience.

[0049] Figure 1 It is a schematic flowchart of a message sending method provided by the embodiments of the present application. As Figure 1 shown, the method includes the following steps:

[0050] In step S101, obtain the message information to be sent.

[0051] Among them, the message information to be sent includes at least the source address and destination address.

[0052] In step S102, in response to determining that the source address and destination address pass the verification, obtain a CAN message in a custom format according to the message information to be sent.

[0053] Among them, the data field of the CAN message in the custom format includes at least a source address field, and the source address field includes the source address.

[0054] In step S103, send the CAN message in the custom format.

[0055] In some embodiments of the present application, the method can be executed by an ECU to send CAN messages. Or, the method can also be executed by other network nodes in the CAN network to send CAN messages.

[0056] 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 the source address and destination address.

[0057] The ECU can verify the source address and destination address in the message information to be sent obtained, so as to determine whether the source address and destination address are legal.

[0058] If it is determined that the source address and destination address in the message information pass the verification, the message information to be sent can be encapsulated to obtain a CAN message in a custom format. The data field of the CAN message in the custom format includes at least a source address field, and the source address field includes the source address in the message information to be sent.

[0059] That is to say, in the data field of the CAN message in the custom format, in addition to the data fields in the traditional standard format CAN message, a source address field is additionally set, and the source address in the message information to be sent can be written in the source address field.

[0060] In some embodiments of the present application, the CAN message in the custom format can be sent, so as to realize the secure sending of the CAN message.

[0061] According to the technical solution provided by the embodiments of the present application, after obtaining the message information to be sent including the source address and destination address, first verify the source address and destination address, generate a CAN message in a custom format after the verification passes, configure the source address in the source address field of the data field of the CAN message in the custom format, and finally send the CAN message in the custom format, which can 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 field 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.

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

[0063] After an attacker knows the request ID or response ID of an ECU, it is very easy to forge a CAN message using the request ID or response ID, thus bringing great security risks to the CAN network.

[0064] Adopting the technical solution of the embodiment of the present application, before generating a CAN message, the source address and destination address in the message information to be sent are verified. Only when the verification passes, a CAN message in a custom format is generated, avoiding attackers generating illegal messages using illegal source addresses and destination addresses. At the same time, the source address of the CAN message is hidden in the data field, so that attackers cannot obtain the request ID and response ID of each network node by parsing the CAN ID, and thus cannot generate illegal messages using legal source addresses.

[0065] Figure 2 It is a schematic flowchart of a method for obtaining a CAN message in a custom format according to the message information to be sent provided by an embodiment of the present application. As Figure 2 shown, the method includes the following steps:

[0066] In step S201, in response to determining that the source address and destination address pass the verification, the message information to be sent is encrypted.

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

[0068] In step S203, a CAN message in a custom format is generated.

[0069] Among them, the data field of the CAN message in the custom format further includes a first check bit field, and the first check bit field includes the first check value.

[0070] 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. Among them, the message information to be sent can further include the message length, message data, etc.

[0071] Before passing the verification of the source address and destination address and encapsulating the message information to be sent, 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 according to 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.

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

[0073] In the related art, the priorities of CAN message sending and receiving are determined according to the sequence number of the CAN ID. The smaller the sequence number of the CAN ID, the higher the priority. This way of determining priorities may be exploited by attackers to achieve a DOS (Denial Of Service) attack by modifying the CAN ID sequence number in the message identifier. For example, sending CAN messages with small sequence numbers at a high frequency will cause CAN messages with low priorities to never be transmitted, thus leading to network anomalies.

[0074] In view of this, embodiments of the present application can define priorities in the message information to be sent. The sending and receiving of CAN messages are both based on the defined priorities, thereby effectively avoiding DOS attacks.

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

[0076] That is to say, the priorities of different CAN messages can be customized. For example, CAN messages related to the power domain and the chassis domain are set with higher priorities, and CAN messages related to IVI (In-Vehicle Infotainment) are set with lower priorities. The priorities of different messages can be set according to the actual situation and are not limited here.

[0077] This priority can be encapsulated as the message information to be sent in the custom format CAN message, and when encapsulating, this priority can be written into the priority field of the custom format CAN message data field.

[0078] When the ECU sends a message, after completing the encapsulation of the custom format CAN message, it can determine whether there are multiple CAN messages to be sent currently. If not, that is, there is only one CAN message to be sent currently, then directly send this custom format CAN message.

[0079] On the contrary, if there are multiple CAN messages to be sent currently, then extract the priorities in each CAN message. In one example, the priorities can be extracted from the priority fields of the data fields of each CAN message, and then determine the CAN message with the highest priority, and first send the CAN message with the highest priority. Perform such iterative operations until all CAN messages are sent.

[0080] In the related art, a specific address can be pre-configured as the default broadcast address, and this default broadcast address is set as the destination address of the CAN message. At this time, if this default broadcast address is leaked, attackers can easily forge CAN messages using this default broadcast address, and the security is relatively poor.

[0081] In view of this, in the CAN message of the embodiment of the present application, the default broadcast address for representing the destination address is no longer set, and whether the message is sent in unicast or broadcast mode is identified by a broadcast flag. If the broadcast flag indicates 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 flag indicates that this CAN message is sent in broadcast mode, the destination address can be empty, or a 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 other than 0x7ff.

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

[0083] In this way, by hiding the broadcast flag in the data field and setting the destination address to be empty or a unicast address that is not the default broadcast address when the broadcast flag is broadcast, an attacker cannot, after intercepting this CAN message, parse the CAN ID or the default broadcast address, and also cannot forge a message using the default broadcast address, further improving the security of CAN message transmission and improving privacy protection.

[0084] In some embodiments of the present application, determining that the source address and the destination address pass the verification may include obtaining a pre-stored set of legal source addresses and a set of legal destination addresses from the trusted area; 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, determining that the source address and the destination address pass the verification.

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

[0086] When verifying the source address and destination address in the message information to be sent, the source address can be used to query in the set of legal source addresses, and the destination address can be used to query in the set of legal destination addresses. If it is determined 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, then it is determined that the verification of the source address and destination address passes.

[0087] In some other embodiments, a set of legal communication links can also be pre-stored in the trusted area of the ECU. The set of legal communication links is all the legal communication links from the source address to the destination address in this CAN network. At this time, when verifying the source address and destination address in the message information to be sent, it can be that if it is determined that the source address is an address in the set of legal source addresses, the destination address is an address in the set of legal destination addresses, and the communication link from the source address to the destination address is a communication link in the set of legal communication links, then it is determined that the verification of the source address and destination address passes.

[0088] For example, in this CAN network, if ECU1 can be used as the source address, both ECU2 and ECU3 can be used as the destination addresses, and the communication link from ECU1 to ECU2 is a legal communication link, while 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) in this CAN network, ECU1 can be saved in the set of legal source addresses, ECU2 and ECU3 can be saved in the set of legal destination addresses, and the communication link from ECU1 to ECU2 can be saved in the set of legal communication links.

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

[0090] If the source address in the message information to be sent is ECU1 and the destination address is ECU3, at this time, since ECU1 is an address in the set of legal source addresses, ECU3 is an address in the set of legal destination addresses, but the communication link from ECU1 to ECU3 is not a communication link in the set of legal communication links, therefore the verification of the source address and destination address does not pass.

[0091] If the source address in the message information to be sent is ECU1 and the destination address is ECU4, and this ECU4 is not an address in the set of legal destination addresses, at this time the verification of the source address and destination address also does not pass.

[0092] Figure 3 It is a schematic diagram of the frame structure of a standard format CAN message. Such as Figure 3As shown, a standard format CAN message may include a CAN ID, 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 the request ID plus a preset value, such as 0x40. Knowing the request ID of the ECU also means knowing its response ID, resulting in poor security.

[0093] 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 may carry the message data of the CAN message. The CRC check value is obtained by performing a CRC calculation on each field in the standard format CAN message.

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

[0095] 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 this CAN message, and the priority field includes the priority of this CAN message.

[0096] If the value in the broadcast flag field is false, the address in the CAN ID may be a unicast destination address, and at this time, this CAN message can be directly sent to this destination address in a unicast manner. If the value in the broadcast flag field is true, the address in the CAN ID may be empty or a unicast address other than the default broadcast address, and at this time, this CAN message can be sent in a broadcast manner.

[0097] The CRC field in the data field may be referred to as the first CRC field. The first CRC field includes a first check value, which is obtained by performing a CRC calculation on the destination address, source address, message length, priority, broadcast flag, and message data of this CAN message. In some embodiments, it is also possible to first encrypt the destination address, source address, message length, priority, broadcast flag, and message data of this CAN message, and then perform a CRC calculation on the encrypted information to obtain the first check value.

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

[0099] 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 the content of this CAN message except this second CRC field.

[0100] Figure 5 It is a schematic diagram of the method for separately determining the first check value and the second check value provided by an embodiment of the present application. As Figure 5 shown, when encapsulating the message information to be sent into a custom format CAN message, the destination address, source address, message length, priority, broadcast flag, and message data can be first encrypted, and then a CRC calculation is performed on the encrypted information to obtain the first check value. Then, a CRC calculation is performed on fields such as CANID, DLC, DoCAN PCI, and data field in this custom format CAN message to obtain the second check value. Among them, the values of each field in the data field, including the source address, priority, broadcast flag, first CRC, and message data, all participate in the CRC calculation.

[0101] Figure 6 It is a 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. As Figure 6 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.

[0102] The message information to be sent can be first encapsulated into a custom format CAN message. When encapsulating, 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 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 flag can be written into the broadcast flag 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 also be calculated as the second check value and written into the CRC field after the data field.

[0103] In the encapsulated custom - format CAN message, the CAN ID field can be 11 bits, the DLC field can be 4 bits, the frame type is 4 bits, the data length is 4 bits, the data field can include 0 to 8 bytes, where 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.

[0104] This custom - format CAN message is basically corresponding to the standard - format CAN message. As Figure 6 shown, the data field of the custom - format CAN message corresponds to the data of the standard - format CAN message. The difference is that there are no multiple fields set in the data field of the standard - format CAN message, which is only used to write data. Different from this, in the custom - format CAN message, the source address, priority, broadcast flag, and the first check value are also recorded as message data in the data field.

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

[0106] Figure 7 is a schematic flow chart of a message receiving method provided by an embodiment of the present application. As Figure 7 shown, the method includes the following steps:

[0107] In step S701, receive a CAN message.

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

[0109] In step S703, in response to determining that the priority is the highest priority in the CAN message to be received, determine the CAN message sending type according to the broadcast flag.

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

[0111] In step S705, in response to determining that the CAN message passes the check based on the source address and the destination address, and determining that the destination address is the network node address of the receiving CAN message, parse the CAN message to obtain the message data.

[0112] In step S706, in response to determining that the CAN message is a broadcast message according to the broadcast flag, and determining that the CAN message passes the check based on the source address, parse the CAN message to obtain the message data.

[0113] In some embodiments of the present application, the method can be executed by an ECU to receive CAN messages. Alternatively, the method can also be executed by other network nodes in the CAN network to receive CAN messages.

[0114] In certain embodiments of the present application, the ECU can receive CAN messages. Among them, the received CAN message is a custom format CAN message.

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

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

[0117] If it is determined that the CAN message is complete and legal, the priority of the CAN message can be judged. If there is only one CAN message to be parsed currently, the CAN message can be directly parsed. If there are multiple CAN messages to be parsed currently, the priorities of the CAN messages to be parsed can be compared, and each message can be received in order from highest to lowest priority.

[0118] If it is determined that the priority of the present CAN message is the highest priority among the CAN messages to be parsed, the present CAN message can be parsed. When parsing, the sending type of the present CAN message can be determined according to the broadcast flag obtained from the data field.

[0119] If it is determined that the present CAN message is a unicast message according to the broadcast flag, the destination address can be obtained from the CAN ID of the present CAN message, and then the CAN message is verified again. When verifying again, the message information of the CAN message can be verified according to the first verification value of the CAN message, and the first verification value is obtained from the first verification bit of the CAN message, and the first verification bit is the verification bit in the data field of the CAN message, and the first verification bit is calculated using the destination address, source address, message length, priority, broadcast flag, and message data.

[0120] If the verification of the first verification value passes, the legality of the destination address and the source address can be verified to determine whether the destination address and the source address are legal. In some embodiments, the priority in the message information can also be verified to determine whether the priority is correct.

[0121] 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 both the destination address and source address in the message information are 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.

[0122] After all the above verifications pass, it can also be determined whether the destination address is the same as the address of the network node itself that receives the CAN message. If so, the network node can parse the CAN message to obtain the message data.

[0123] On the other hand, if it is determined according to the broadcast flag that the CAN message is a broadcast message, the second verification value can also be verified first, and after the verification passes, the first verification value can be verified. After all the above verifications pass, the CAN message is parsed to obtain the message data.

[0124] Adopting the technical solution provided by 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 flag. Under the condition that it is determined according to the priority that the CAN message needs to be parsed, different methods are used to verify unicast messages and broadcast messages according to the broadcast flag, and after the verification passes, the CAN message is parsed to obtain the message data, which can improve the security of CAN message reception and avoid DOS attacks.

[0125] Figure 8 It is a schematic structural diagram of an ECU that implements the message sending method and message receiving method provided by the embodiment of the present application. As Figure 8 shown, the ECU can be configured as a CAN message sending node or a CAN message receiving node.

[0126] When the ECU is configured as a CAN message sending node, it can sequentially call the application layer, message encapsulation module, message scheduling module, message sending module, and physical layer to send CAN messages. An address list monitoring module, encryption and decryption module, and intrusion detection module can also be configured in the trusted area of the ECU. The address list monitoring module is used to monitor the legality 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 are illegal intrusion messages.

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

[0128] In the ECU module acting as the sending node, a CRC calculation module can also be configured to perform CRC calculations on the message information and the entire CAN message to obtain the CRC check value.

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

[0130] In the ECU module acting as the receiving node, a CRC calculation module can also be configured to perform CRC verification on the received CAN message.

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

[0132] When sending a CAN message, the address list monitoring module can be called first to verify the source address and destination address. After the verification passes, encryption operations and CRC calculations are performed on the message information including the legal address, and then the calculation results are sent to the message encapsulation module for encapsulation.

[0133] In the message encapsulation module, the message information can be encapsulated into a custom format CAN message, and a CRC calculation is performed again on the encapsulated CAN message 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.

[0134] If the message scheduling module receives only one message, it directly forwards the message. On the other hand, if the message scheduling module receives multiple messages, it can perform scheduling and forwarding according to the message priority. The message priority can be obtained from the priority field in the data field of the custom format CAN message, and the priority is set according to actual needs.

[0135] In this way, it replaces the traditional scheme of determining the priority according to the CAN ID number sequence during CAN message forwarding, thereby avoiding attackers using small-sequence CAN IDs to obtain the highest priority for malicious forwarding, which may lead to system anomalies.

[0136] After the scheduling is completed, the custom-format CAN message can be sent to the message sending module. The message sending module sends the custom-format CAN message to the destination address.

[0137] When receiving a CAN message, the message filtering module first receives the custom-format CAN message from the physical layer, and performs CRC integrity verification, source address and destination address legality verification on the received message. If the verification result shows that the message is illegal, the message is directly discarded. If the verification result shows that the message is legal, the message receiving module receives the custom-format CAN message.

[0138] The message receiving module can send the custom-format CAN message to the message decryption module. The message decryption module decrypts the received custom-format CAN message, and obtains the source address, broadcast flag, and priority from the decrypted message information. By calling the address list monitoring module, it can verify the source address and priority or the source address, destination address, and priority according to different values of the broadcast flag. If it is illegal, it is discarded. If it is legal, it is sent to the application layer for service processing.

[0139] The intrusion detection module can monitor in real time messages with a very small CAN ID number (such as less than a preset threshold) and a destination address not in the address white list set by the address list monitoring module to detect DOS attack messages in a timely manner. If it detects a message with a very small CAN ID number and a destination address not in the address white list set by the address list monitoring module, the intrusion detection module can continue to detect whether the source address of the message is in the white list, and whether the priority of the source address and destination address matches the priority in the white list. If they match, it is determined as a legal message. Otherwise, an alarm message can be generated, and the sending and receiving of the message can be suppressed when appropriate.

[0140] On the other hand, the intrusion detection module can also monitor messages with abnormal frequency transmission periods. When the message causes the bus complexity to exceed the preset load threshold, it can preferentially satisfy the message sending and receiving of function safety-related ECUs. Among them, function safety-related ECUs can be, for example, power domain ECUs, chassis domain ECUs, etc.

[0141] Adopting the technical solution of the embodiment of the present application, by authenticating the transmission based on the source address and the destination address, instead of using the broadcast transmission of the original CAN network, it avoids the security risks and privacy leakage risks brought by the messages without source address and destination address being sent to the bus in a broadcast form and being received by any node. At the same time, the message priority transmission is designed in the message to avoid that when the network is invaded by a malicious attacker, only by modifying the identifier to implement a DOS attack, resulting in the inability to transmit low-priority messages. In addition, by setting a broadcast flag in the data field and setting a unicast address for the CANID, it can ensure the unicast and broadcast of CAN messages on the basis of ensuring security performance.

[0142] On the other hand, both 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, reducing the risk of the data in the message being attacked and ensuring the protection ability of the CAN network.

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

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

[0145] Figure 9 It is a schematic diagram of a message sending device provided by an embodiment of the present application. As Figure 9 shown, the device includes:

[0146] An obtaining module 901, configured to obtain message information to be sent; the message information to be sent includes at least a source address and a destination address.

[0147] An encapsulation module 902, 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 pass the verification; at least a source address field is included in the data field of the custom format CAN message, and the source address field includes the source address.

[0148] A sending module 903, configured to send the custom format CAN message.

[0149] According to the technical solution provided by the embodiments of the present application, after obtaining the message information to be sent including the source address and the destination address, first, the source address and the destination address are verified. After the verification passes, a custom format CAN message is generated. The source address is configured in the source address field of the data field of the custom format CAN message. Finally, the custom format CAN message is sent, which can 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 field of the CAN message and is difficult for attackers to obtain, thereby improving the security of the CAN message and enhancing the user experience.

[0150] In some embodiments, obtaining a custom format CAN message according to the message information to be sent includes: in response to determining that the source address and the destination address pass the verification, encrypting the message information to be sent; obtaining a first check value according to the encrypted message information to be sent; generating a custom format CAN message; the data field of the custom format CAN message further includes a first check bit field, and the first check bit field includes the first check value.

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

[0152] In some embodiments, the message information to be sent further includes a broadcast flag, and the broadcast flag is used to identify whether this CAN message is sent in unicast or broadcast mode; the data field of the custom format CAN message further includes a broadcast flag field, and the broadcast flag field includes the broadcast flag; the message identification field of the custom format CAN message includes the destination address.

[0153] In some embodiments, the message identification field of the custom format CAN message includes the destination address; in response to determining that the broadcast flag indicates that this CAN message is sent in unicast mode, the destination address is the unicast destination address; the step of determining that the source address and the destination address pass the verification 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 flag indicates that this CAN message is sent in broadcast mode, the destination address is empty or any unicast address other than the system default broadcast address; the step of determining that the source address and the destination address pass the verification is to determine that the source address is legal and the source address can be used as a broadcast address.

[0154] Figure 10 It is a schematic diagram of a message receiving device provided by the embodiments of the present application. As Figure 10 shown, the device includes:

[0155] A receiving module 1001, configured to receive CAN messages.

[0156] An acquisition module 1002, configured to acquire a source address, a priority, and a broadcast flag from a data field of a CAN message.

[0157] A parsing module 1003, configured to determine a CAN message sending type according to the broadcast flag in response to determining that the priority is the highest priority in the CAN message to be parsed.

[0158] The parsing module 1003 is further configured to obtain a destination address from the message identifier of the CAN message in response to determining that the CAN message is a unicast message according to the broadcast flag; in response to determining that the CAN message passes the verification based on the source address and the destination address, and determining that the destination address is the network node address for receiving the CAN message, parse the CAN message to obtain message data.

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

[0160] In some embodiments, determining that the CAN message passes the verification includes: verifying the CAN message 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 an end verification bit of the CAN message; in response to determining that the CAN message passes the 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 verification bit of the CAN message, and the first verification bit is a verification 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 passes the verification, performing a legality verification on the destination address and the source address; in response to determining that the legality verification of the destination address and the source address passes, determining that the CAN message passes the verification.

[0161] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0162] Figure 11 is a schematic diagram of an electronic control unit provided by an embodiment of the present application. As Figure 11 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 method embodiments are implemented. Alternatively, when the processor 1101 executes the computer program 1103, the functions of each module / unit in the above device embodiments are implemented.

[0163] The electronic control unit 11 can be an electronic control unit such as a desktop computer, a notebook, a palm computer, and a cloud server. The electronic control unit 11 can include, but is not limited to, a processor 1101 and a memory 1102. Those skilled in the art can understand that Figure 11 merely examples of the electronic control unit 11, which do not constitute a limitation on the electronic control unit 11, may include more or fewer components than shown in the figure, or different components.

[0164] The processor 1101 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0165] The memory 1102 can be an internal storage unit of the electronic control unit 11. For example, the hard disk or memory of the electronic control unit 11. The memory 1102 can 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 can also include both the internal storage unit of the electronic control unit 11 and the external storage device. The memory 1102 is used to store computer programs and other programs and data required by the electronic control unit.

[0166] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, 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. Each functional unit and module in the embodiment can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0167] When 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 such understanding, to implement all or part of the processes in the above-described embodiment methods of this application, it can also be completed by instructing relevant hardware through a computer program. The computer program can be stored in the computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-described various method embodiments can be implemented. The computer program can include computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device that can carry the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium, etc.

[0168] The above embodiments are only used to illustrate the technical solutions of this application, rather than to limit it; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of this application, and should all be included within the protection scope of this 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 information of the message to be sent includes at least a source address, a destination address, a priority, and a broadcast mark, wherein the priority is used to indicate the order of sending or receiving different CAN messages, and the broadcast mark is used to identify whether the CAN message is sent in a unicast mode or a broadcast mode; 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, a priority field, a broadcast tag field and a first check bit field, the source address field includes the source address, the priority field includes the priority, the broadcast tag field includes the broadcast tag, and the first check bit field includes a first check value, and the first check value is determined in the following manner: 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; The message identification field of the custom format CAN message includes the destination address, and the custom format CAN message also includes a second check value, and the second check value is obtained by performing a cyclic redundancy check calculation on all fields in the custom format CAN message except the second check value; 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 indicates that the CAN message is sent in a broadcast manner, the destination address is empty or is any unicast address other than a default broadcast address; Send the custom format CAN message.

2. 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.

3. 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, parsing the CAN message to obtain message data; 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.

4. A message sending device, characterized in that: The message is a controller area network (CAN) message, and the device comprises: an acquisition module, configured to acquire information of a message to be sent; the information of the message to be sent includes at least a source address, a destination address, a priority and a broadcast mark, the priority is used to indicate the order of sending or receiving different CAN messages, and the broadcast mark is used to identify whether the CAN message is sent in a unicast mode or a broadcast mode; 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, a priority field, a broadcast tag field and a first check bit field, the source address field includes the source address, the priority field includes the priority, the broadcast tag field includes the broadcast tag, and the first check bit field includes a first check value, which is determined in the following manner: 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; The message identification field of the custom format CAN message includes the destination address, and the custom format CAN message also includes a second check value, and the second check value is obtained by performing a cyclic redundancy check calculation on all fields in the custom format CAN message except the second check value; In response to determining that the broadcast tag identifies that the present CAN message is sent in a unicast manner, the destination address is a unicast destination address; In response to determining that the broadcast tag indicates that the CAN message is sent in a broadcast manner, the destination address is empty or is any unicast address other than a default broadcast address; The sending module is configured to send the CAN message in the custom format.

5. 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, parsing the CAN message to obtain message data; 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.

6. 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 3.

Images