In-vehicle communication method, electronic device, vehicle and program product

Abstract

The invention relates to the technical field of communication, in particular to an in-vehicle communication method, electronic equipment, a vehicle and a program product, and the method comprises the steps: constructing protocol data of a to-be-sent information message; a communication message is generated based on a secure communication protocol and protocol data, the secure communication protocol comprises a DataID mechanism of a functional security protocol E2E, a message authentication code MAC mechanism of an information security protocol SecOC and a target counter, and the target counter comprises a Counter verification mechanism of the E2E, a freshness value FV data structure of the SecOC and an FV verification mechanism. Generating a communication message based on the DataID mechanism, the MAC mechanism and the target counter; and performing in-vehicle communication based on the communication message. Therefore, the problems of resource redundancy, occupation of more operation resources and the like caused by simultaneous deployment of a function security protocol and an information security protocol in related technologies are solved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to an in-vehicle communication method, electronic equipment, vehicle and program product. Background Art

[0002] With the development of the Internet of Vehicles market and the emergence of on-board electronic controllers and emerging electronic and electrical architectures, countries are strengthening the construction of automotive network security, among which the security of in-vehicle network message communication is particularly critical. The main problems faced by in-vehicle message communication are divided into two aspects: the first aspect is that some factors in the message transmission process cause abnormal functions of the car, mainly including message duplication, loss, disorder, delay, disguise, destruction and asymmetry. In order to solve these problems, the industry has developed a set of E2E (End to End) functional safety communication protocols. On the other hand, security issues involve human attacks, such as vehicle theft or remote control, which include malicious forgery, tampering and replay of messages by attackers. In order to deal with this problem, the industry has developed a set of SecOC (Secure Onboard Communication) information security communication protocols.

[0003] In the vehicle bus network environment, in order to ensure both network security and functional safety, relevant technologies deploy both functional safety and information security protocols at key signal locations. However, the simultaneous use of the two protocols will result in resource redundancy and occupy more CPU (Central Processing Unit) computing resources. Summary of the invention

[0004] The present application provides an in-vehicle communication method, electronic equipment, vehicle and program product to solve the problems in the related technology of simultaneously deploying two sets of functional safety and information security protocols, resulting in resource redundancy and occupying more computing resources.

[0005] The first aspect of the present application provides an in-vehicle communication method, which is applied to a sending end, wherein the method includes the following steps: constructing protocol data of a message message to be sent; generating a communication message based on a secure communication protocol and the protocol data, wherein the secure communication protocol includes a DataID mechanism of a functional safety protocol E2E and a message authentication code MAC mechanism and a target counter of an information security protocol SecOC, wherein the target counter includes a Counter verification mechanism of E2E, a freshness value FV data structure and an FV verification mechanism of SecOC, and generating a communication message based on the DataID mechanism, the MAC mechanism and the target counter; and performing in-vehicle communication based on the communication message.

[0006] Optionally, a communication message is generated based on a secure communication protocol and protocol data, including: selecting a counter value CT of a target counter; obtaining a port identification number SID based on a DataID mechanism; inputting the protocol data, the CT of the target counter, SID and a preset key into a MAC calculator, the MAC calculator calculating a MAC based on a MAC mechanism; and filling in CT and MAC in sequence after the protocol data to obtain a communication message.

[0007] A second aspect embodiment of the present application provides an in-vehicle communication method, which is applied to a receiving end, wherein the method includes the following steps: obtaining a communication message sent by a sending end, wherein the sending end generates a communication message based on a secure communication protocol and protocol data, the secure communication protocol includes a DataID mechanism of a functional safety protocol E2E, a message authentication code MAC mechanism and a target counter of an information security protocol SecOC, the target counter includes a Counter verification mechanism of E2E, a freshness value FV data structure and an FV verification mechanism of SecOC, and a communication message is generated based on the DataID mechanism, the MAC mechanism and the target counter; and the communication message is parsed to obtain the protocol data of the message to be sent.

[0008] Optionally, parsing the communication message to obtain the protocol data of the message message to be sent includes: parsing the communication message to obtain the protocol data, the CT and the MAC of the target counter; verifying the validity of the CT based on the Counter verification mechanism, and verifying the uniqueness of the CT based on the FV verification mechanism; discarding the protocol data if the verification fails, and identifying the SID of the sender if the verification succeeds; inputting the protocol data, CT, SID and a preset key into the MAC calculator, and the MAC calculator calculates the MAC based on the MAC mechanism; if the MAC obtained by the analysis is consistent with the MAC calculated by the MAC calculator, the protocol data is passed to the application layer, otherwise the protocol data is discarded.

[0009] Optionally, the secure communication protocol also includes an E2E timeout verification mechanism, and before parsing the communication message to obtain the protocol data, CT and MAC, it also includes: performing a timeout verification on the communication message based on the timeout verification mechanism.

[0010] Optionally, the communication nodes in the vehicle include a master node and a slave node, and the state synchronization update action of the target counter is triggered according to the synchronization request of the slave node or the synchronization request of the master node, wherein the state synchronization update action of the slave node includes: obtaining the synchronization message broadcast by the master node; after verifying that the synchronization message passes, updating the current state to the first state, and feeding back the response message to the receiving end, if the verification fails, no feedback is given, wherein the master node broadcasts the current state of all slave nodes after obtaining the response messages of all slave nodes; if the current state of all slave nodes broadcast by the master node is received, the current state is updated to the second state, otherwise the current state is retained as the first state.

[0011] Optionally, after triggering the state synchronization update action of the target counter according to the synchronization request of the slave node or the synchronization request of the master node, selecting the counter value CT of the target counter includes: identifying the current state of the target counter; if the current state is the first state, selecting the old CT stored in the target counter; if the current state is the second state, selecting the new CT stored in the target counter.

[0012] The third aspect of the present application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the in-vehicle communication method as described in the above embodiment.

[0013] A fourth aspect of the present application provides a vehicle, comprising an electronic device as described in the above embodiment.

[0014] The fifth aspect of the present application provides a computer program product, including a computer program or instructions, which are executed by a processor to implement the in-vehicle communication method as described in the above embodiment.

[0015] Therefore, this application includes the following beneficial effects:

[0016] The embodiment of the present application can integrate the functional safety protocol E2E and the information security protocol SecOC to obtain a new secure communication protocol, retaining the DataID mechanism of E2E and the message authentication code MAC mechanism of SecO, and integrating the Counter verification mechanism in E2E for judging whether a message is repeated, lost or disordered and the freshness value FV data structure and FV verification mechanism in SecOC for anti-replay to obtain a target counter, retaining the respective advantages of the two protocols, and removing the CRC redundant part in E2E, reducing resource redundancy and reducing the computing resource occupation, and then generating communication messages based on protocol data and secure communication protocols to realize communication within the vehicle. Therefore, the technical problems of simultaneously deploying two sets of functional safety and information security protocols in the related technology, resulting in resource redundancy and occupying more computing resources, etc.

[0017] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0019] Figure 1 A flow chart of an in-vehicle communication method provided according to an embodiment of the present application;

[0020] Figure 2 It is a schematic diagram of the E2E protocol;

[0021] Figure 3 It is a schematic diagram of the data structure of FV in SecOC;

[0022] Figure 4 This is a diagram of the deployment of the SecOC protocol in the car;

[0023] Figure 5 Schematic diagram of MAC and FV verification of SecOC;

[0024] Figure 6 A flowchart of an in-vehicle communication method provided according to another embodiment of the present application;

[0025] Figure 7 A schematic diagram of synchronously updating a target counter state according to an embodiment of the present application;

[0026] Figure 8 A schematic diagram of a fused protocol mechanism provided according to an embodiment of the present application;

[0027] Fig. 9 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0028] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0029] Figure 1 A schematic flow chart of an in-vehicle communication method provided in an embodiment of the present application.

[0030] like Figure 1 As shown, the in-vehicle communication method, applied to the sending end, includes the following steps:

[0031] In step S101, protocol data of a message to be sent is constructed.

[0032] Among them, the message message is the basic data unit for communication and exchange of information between ECUs (Electronic Control Units) in the vehicle. It encapsulates the specific information that needs to be exchanged and related control information; the protocol data PDU is the core content of the message message used for transmission, and is data organized according to the rules and format of a specific communication protocol.

[0033] It can be understood that the embodiment of the present application can construct a PDU of the message message to be sent, so as to subsequently generate a communication message based on the PDU.

[0034] In step S102, a communication message is generated based on a secure communication protocol and protocol data, wherein the secure communication protocol includes a DataID mechanism of the functional safety protocol E2E and a MAC (Message Authentication Codes) mechanism and a target counter of the information security protocol SecOC, and the target counter includes a Counter verification mechanism of E2E, a FV (Freshness Value) data structure and an FV verification mechanism of SecOC, and a communication message is generated based on the DataID mechanism, the MAC mechanism and the target counter.

[0035] It should be noted that E2E is a secure communication protocol, a mechanism used in communication systems to ensure the security, integrity and authenticity of data throughout the entire transmission process. The specific protocol format is mainly: protocol data + CT + CRC (Cyclic Redundancy Check), where protocol data is the actual transmitted data, including the content of the message, CT is Counter, a counter used to detect duplication, loss or disorder of messages, and CRC is a cyclic redundancy check code used to detect whether the data is damaged or whether the data is wrong. The schematic diagram of E2E is as follows: Figure 2 As shown, Figure 2 Sig1 in the packet is used to identify a specific part or purpose of the packet or to verify the integrity and correctness of the packet, which can be achieved through a hash function or other encryption methods.

[0036] SecOC is an in-vehicle network security communication protocol defined by the AUTOSAR (Automotive Open System Architecture) organization. It aims to provide security for communications between ECUs in the vehicle's internal network to deal with potential network attacks such as tampering, replay attacks or message forgery. The specific protocol format is mainly: protocol data + CT + MAC. CT is a counter used to determine whether the message is repeated, lost or out of order. This counter increases by 1 every time a new message is sent; MAC is used to verify the authenticity and integrity of the message to prevent malicious forgery. The AES128-CMAC algorithm is usually used in combination with the secret key K to perform MAC calculation on the entire message to obtain a message digest value for verifying the authenticity and integrity of the message.

[0037] It should be noted that in order to prevent human attacks, the design of SecOC's counter is slightly more complicated, and it is necessary to strictly ensure that the counter will not overflow or restart. For this reason, FV is designed to ensure that there is enough counter volume to prevent overflow and can be safely stored on the medium. Therefore, FV adopts a three-layer counter technology, such as Figure 3 As shown, it includes a trip counter TripCounter, a reset counter ResetCounter and a message counter MessageCounter. Among them, TripCounter and ResetCounter are maintained by the Master ECU, and MessageCounter is maintained by the Slave ECU, which ensures the uniqueness of the counter and can avoid replay attacks.

[0038] Taking the deployment of SecOC protocol in a car as an example, the deployment diagram is as follows: Figure 4 The specific implementation process of the SecOC protocol is as follows Figure 5 As shown in the figure, the SecOC protocol implements the counter and MAC (Message Authentication Codes) functions. MAC refers to AES128-CMAC, which is combined with the secret key K to calculate the MAC of the entire message to obtain a message digest value. The receiving end performs the same calculation and compares the obtained MAC with the MAC value in the message to determine whether the message is correct, forged or tampered with. SecOC ensures that the counter will increase by 1 for each message sent, and the MAC protection ensures that it can resist message replay attacks.

[0039] In short, the E2E protocol uses the CRC algorithm to detect whether the data is damaged or wrong, uses the DataID and CRC mechanisms to jointly check whether the data source is correct, and uses the Counter to determine whether the message is repeated, lost, or out of order. The SecOC protocol uses MAC to verify the authenticity and integrity of the message to prevent malicious forgery, and uses FV to prevent malicious replay. In order to meet the security functions of E2E and SecOC at the same time, the existing technology uses the two protocols in a superimposed manner.

[0040] However, due to limited resources in the car and the 8-byte message of the CAN network, if the two protocols are used in combination, each protocol will add information to the original message. This resource occupancy ratio is very high for the CAN network, which limits the space available for actual data transmission, and may require major adjustments to the original communication matrix. In addition, the risk of signal delay or loss may increase due to packet transmission, and the ECU computing power resources are also relatively tight. Both CRC and MAC in the two protocols occupy relatively more CPU computing resources, which also has a greater impact on the real-time response of the ECU and increases the computing burden of the ECU.

[0041] Therefore, the embodiment of the present application integrates the two protocols E2E and SecOC, retains the respective advantages of the two protocols, and removes the redundant parts, specifically: retains the DataID used to identify data and data sources in E2E and the MAC used to prevent tampering and counterfeiting in SecOC. Since MAC has both integrity and authenticity effects, but CRC only has integrity check effects, the CRC mechanism in E2E is removed, the MAC in SecOC is retained, and the counter Counter mechanism in E2E is retained, and the freshness value FV data structure and FV verification mechanism of SecOC are retained, and the counter Counter in E2E used to determine whether the message is repeated, lost or disordered and the freshness value FV data structure and FV verification mechanism in SecOC are retained to form a new target counter. Therefore, the embodiment of the present application can generate communication messages based on secure communication protocols and protocol data, reduce resource redundancy, and reduce computing resource usage.

[0042] In an embodiment of the present application, the secure communication protocol includes the DataID mechanism of the functional safety protocol E2E and the message authentication code MAC mechanism and target counter of the information security protocol SecOC. The target counter includes the Counter verification mechanism of E2E, the freshness value FV data structure and FV verification mechanism of SecOC, and generates communication messages based on the DataID mechanism, MAC mechanism and Counter. The DataID used to identify data and data sources in E2E and the MAC used for anti-tampering and anti-counterfeiting in SecOC are retained, and the Counter verification mechanism of E2E, the freshness value FV data structure and FV verification mechanism of SecOC are retained to form a new target counter to ensure the integrity and correctness of the message, so as to make in-vehicle communication safer.

[0043] Specifically, the embodiment of the present application integrates the two security protocols of E2E and SecOC, eliminates redundancy, generates a new integrated security communication protocol, and further generates communication messages based on the integrated security communication protocol and protocol data, that is, retains the E2E DataID mechanism and the SecOC message authentication code MAC mechanism and the Counter verification mechanism of E2E, the SecOC freshness value FV data structure and the target counter of the FV verification mechanism, and then generates communication messages based on the DataID mechanism, MAC mechanism and the target counter.

[0044] For example, taking Profile 1 as an example, in the original E2E Profile 1, the message includes an 8-bit Counter and an 8-bit CRC. The 8-bit Counter is used to prevent replay attacks. By ensuring that each message has a unique sequence number, the receiver can verify the freshness of the message. The 8-bit CRC is used to detect any data corruption that may occur during the transmission process. The original SecOC Profile 1 includes an 8-bit FV and a 16-bit CMAC value. The 8-bit FV is used to ensure the freshness of the message, and the 16-bit CMAC value is used to verify the authenticity and integrity of the message.

[0045] E2E Profile 1:8-bit Counter+8-bit CRC=16bits;

[0046] SecOC Profile 1:8-bit Freshness Value+16-bit CMAC=24bits;

[0047] Total: 16 bits + 24 bits = 40 bits, which will occupy 5 bytes (2 bytes E2E and 3 bytes SecOC), which means that in the 8-byte message, security-related information occupies 62.5% of the space resources.

[0048] The protocol integrated in the present application only requires an 8-bit FV and a 16-bit MAC value, wherein the 8-bit FV is used as the CT value of the target counter in the embodiment of the present application, i.e., 3 bytes (1-byte CT + 2-byte MAC), and the occupancy rate is only 37.5, which is much smaller than the case where the two protocols are used at the same time. As the configuration files occupy larger resources, the advantage becomes more obvious.

[0049] In an embodiment of the present application, a communication message is generated based on a secure communication protocol and protocol data, including: selecting a counter value CT of a target counter; obtaining a port identification number SID based on a DataID mechanism; inputting the protocol data, the CT of the target counter, SID and a preset key into a MAC calculator, and the MAC calculator calculates a MAC based on a MAC mechanism; and filling in CT and MAC in sequence after the protocol data to obtain a communication message.

[0050] It can be understood that the embodiment of the present application can select the counter value CT of the target counter, where CT is the value corresponding to the FV data structure, and obtain the SID (source ID, port identification number) based on the DataID mechanism, that is, directly identify the SID of the sender based on the DataID mechanism, and input the protocol data PDU, the CT of the target counter, the SID and the preset key Key into the MAC calculator. The MAC calculator calculates the MAC based on the MAC mechanism, and fills in CT and MAC in sequence after the PDU to obtain the communication message.

[0051] Specifically, the port identification number SID, key Key, original protocol data PDU, and target counter CT are input into the MAC calculator to calculate the MAC value, combine the PDU, CT, and MAC values, and the communication message format is PDU followed by 1 byte of CT (the last 8 bits of the original CT), and CT followed by 2 bytes of MAC value (the first 16 bits of the original MAC).

[0052] In step S103, in-vehicle communication is performed based on the communication message.

[0053] It can be understood that the embodiment of the present application performs in-vehicle communication based on the communication message generated as above, saves communication message load resources, combines the E2E and SecOC protocols, retains the DataID used to identify data and data sources in E2E, and the MAC used for anti-tampering and anti-counterfeiting in SecOC. Since MAC has both integrity and authenticity effects, but CRC in E2E only has integrity check effects, the CRC mechanism in E2E is removed, the MAC in SecOC is retained, and the Counter mechanism is retained. Therefore, the target counter includes the Counter verification mechanism of E2E, the freshness value FV data structure and FV verification mechanism of SecOC. The Counter verification mechanism of E2E is used to determine whether the message is repeated, lost or out of order. The freshness value FV data structure and FV verification mechanism of SecOC are used to prevent replay. The respective advantages of the two protocols are retained, and the redundant parts are removed. In addition, communication messages are generated based on the integrated secure communication protocol to perform in-vehicle communication, which saves more computing resources and avoids redundancy.

[0054] According to the in-vehicle communication method proposed in the embodiment of the present application, the functional safety protocol E2E and the information security protocol SecOC can be integrated to obtain a new security communication protocol, which retains the DataID mechanism in E2E for identifying data and data sources and the message authentication code MAC mechanism in SecOC for anti-tampering and anti-counterfeiting, and the Counter verification mechanism in E2E for determining whether a message is repeated, lost or disordered and the freshness value FV data structure and FV verification mechanism in SecOC for anti-replay are integrated to obtain the target counter, retaining the respective advantages of the two protocols, and removing the CRC redundant part in E2E, reducing resource redundancy and reducing the occupancy of computing resources, thereby generating communication messages based on protocol data and the security communication protocol to realize in-vehicle communication.

[0055] The above embodiments focus on describing the in-vehicle communication method of the present application from the transmitting end, and the following embodiments will describe the in-vehicle communication method of the present application from the receiving end. The incomplete parts between the embodiments can be referenced to each other.

[0056] like Figure 6 As shown, the in-vehicle communication method, applied to a receiving end, comprises the following steps:

[0057] In step S201, a communication message sent by the sender is obtained, wherein the sender generates the communication message based on a secure communication protocol and protocol data, the secure communication protocol includes the DataID mechanism of the functional safety protocol E2E, the message authentication code MAC mechanism and the target counter of the information security protocol SecOC, the target counter includes the Counter verification mechanism of E2E, the freshness value FV data structure and FV verification mechanism of SecOC, and the communication message is generated based on the DataID mechanism, the MAC mechanism and the target counter.

[0058] It can be understood that the embodiments of the present application can obtain the communication message of the sending end, wherein the specific generation method of the communication message has been explained in the above embodiments and will not be repeated here.

[0059] In step S202, the communication message is parsed to obtain the protocol data of the message message to be sent.

[0060] It can be understood that the embodiment of the present application can parse the communication message to obtain the protocol data of the message message to be sent, so as to realize safe communication within the vehicle.

[0061] In an embodiment of the present application, a communication message is parsed to obtain protocol data of a message message to be sent, including: parsing the communication message to obtain protocol data, a CT and a MAC of a target counter; verifying the validity of the CT based on a Counter verification mechanism, and verifying the uniqueness of the CT based on an FV verification mechanism; discarding the protocol data if the verification fails, and identifying the SID of the sender if the verification succeeds; inputting the protocol data, CT, SID and a preset key into a MAC calculator, and the MAC calculator calculates the MAC based on the MAC mechanism; if the MAC obtained by the parsing is consistent with the MAC calculated by the MAC calculator, the protocol data is passed to the application layer, otherwise the protocol data is discarded.

[0062] Among them, validity includes whether there are duplications, packet loss, disorder, etc., and uniqueness refers to whether it is a historical old message, that is, whether there are duplications.

[0063] Since the MessageCounter in E2E increments each time a message is sent, the receiving end can detect the validity of the message by comparing the CT. Since the counter design in SecOC ensures the uniqueness of the counter and prevents replay attacks, the uniqueness of the CT can be verified based on the FV verification mechanism. Therefore, the embodiment of the present application can verify the validity of the CT based on the Counter verification mechanism and the uniqueness of the CT based on the FV verification mechanism. If the verification fails, the PDU is discarded, thereby retaining the duplication, packet loss, and disorder checking capabilities of E2E and the anti-replay capability of SecOC.

[0064] If the verification is successful, the SID of the sender is identified, and the PDU, CT, SID and Key are input into the MAC calculator. The MAC calculator calculates the MAC based on the MAC mechanism. If the parsed MAC is consistent with the MAC calculated by the MAC calculator, the PDU is passed to the application layer, otherwise the PDU is discarded and the integrity capability of the MAC is used instead of the CRC to ensure the integrity and authenticity of the message and prevent replay attacks and other security threats. By using Counter, FV and MAC, the receiver can verify the sequence, freshness and source of the message, thereby improving the security of the entire in-vehicle communication.

[0065] In an embodiment of the present application, the secure communication protocol also includes an E2E timeout verification mechanism. Before parsing the communication message to obtain the protocol data, CT and MAC of the target counter, it also includes: performing a timeout verification on the communication message based on the timeout verification mechanism.

[0066] It can be understood that the secure communication protocol of the embodiment of the present application also retains the E2E timeout verification mechanism. Before parsing the communication message to obtain the protocol data, CT and MAC, the communication message is verified based on the timeout verification mechanism to ensure that the received message is sent within a reasonable time, which helps prevent attackers from using long-retained messages to perform replay attacks. By checking the reception time of the message, the receiving end can ensure that the received message is sent recently, rather than an old message from the past, thereby reducing the risk of replay attacks.

[0067] In an embodiment of the present application, the communication nodes in the vehicle include a master node and a slave node, and the state synchronization update action of the target counter is triggered according to the synchronization request of the slave node or the synchronization request of the master node, wherein the state synchronization update action of the slave node includes: obtaining the synchronization message broadcast by the master node; after verifying that the synchronization message passes, updating the current state to the first state, and feeding back the response message to the master node, if the verification fails, no feedback is given, wherein the master node broadcasts the current state of all slave nodes after obtaining the response messages of all slave nodes; if the current state of all slave nodes broadcast by the master node is received, the current state is updated to the second state, otherwise the current state is retained as the first state.

[0068] In order to ensure that the target counters between all slave nodes in the vehicle network remain synchronized, thereby avoiding problems such as message verification failure caused by asynchronous response messages, the present application can select any one of all communication nodes as the master node, and the remaining communication nodes as slave nodes. Both the sender and the receiver can serve as the master node, and a state synchronization mechanism is implemented based on the master node. Through this mechanism, all slave nodes can update their own target counter states in a timely manner, ensuring that the states of the target counters of all slave nodes in the network that serve as senders and receivers remain synchronized, which is the key to preventing message verification failures. In addition, through the pre-synchronization state, it is ensured that in the event of possible delays in the network, the sender can use the old counter to send messages, thereby avoiding the receiver from discarding legitimate messages due to asynchronous target counters.

[0069] In addition, a feedback mechanism has been established. The master node can confirm that all slave nodes have received the synchronization message, ensuring that all slave nodes in the network are in the same target counter state, thereby improving the reliability of the entire network. Therefore, even in the case of high network latency, the slave node can send messages through the pre-synchronization state, thereby reducing the impact of latency on functional safety. For slave nodes that fail to receive the synchronization message in time, the synchronization mechanism allows these nodes to restore the synchronization state through subsequent synchronization messages or actively request synchronization messages, thereby ensuring the overall connectivity and security of the network.

[0070] Specifically, in the embodiment of the present application, the master node broadcasts a synchronization message to all slave nodes in the network. The slave node can obtain the synchronization message broadcast by the master node, verify the synchronization message, confirm its authenticity, and update the current state to the first state after the verification of the synchronization message passes, and feed back a response message to the receiving end. If the verification fails, the slave node will not feed back any information. The master node collects the reception results of all slave nodes. If all slave nodes successfully receive and verify the synchronization message, the master node will broadcast the current state of all slave nodes. After the slave node receives the current state of all slave nodes broadcast by the master node, the slave node updates the current state to the second state. If the current state of all slave nodes is not received, the slave node will continue to remain in the first state, ensuring that all senders and receivers in the network are in the same state, thereby improving the security of in-vehicle communications. In this way, the state inconsistency between the sender and the receiver can be avoided, replay attacks and other security threats can be prevented, and the reliability and security of the vehicle network can be improved.

[0071] In an embodiment of the present application, after the state synchronization update action of the target counter is triggered according to the synchronization request of the slave node or the synchronization request of the master node, the counter value CT of the target counter is selected, including: identifying the current state of the target counter; if the current state is the first state, then selecting the old CT stored in the target counter; if the current state is the third state, then selecting the new CT stored in the target counter.

[0072] The first state and the second state are two different states of the target counter, the first state can be called a pre-synchronization state, and the second state can be called a completed synchronization state, as follows:

[0073] Pre-synchronization state: The slave node starts the synchronization process. At this time, the slave node receives the new CT sent by the master node. Since the synchronization process has not been completed yet, the slave node still stores the original old CT. In the pre-synchronization state, the slave node uses the old CT to send messages to ensure that all receiving ends can receive them normally.

[0074] Completed synchronization state: The slave node has completed the full network synchronization, and the slave node now sends messages using the new CT stored in the target counter.

[0075] After the master node sends a synchronization message, due to possible network delays, the slave nodes may receive the message at different times. In rare cases, a slave node sends a new message after receiving the synchronization message and resetting its message counter, while another slave node may receive the message first without receiving the synchronization message, resulting in the message being discarded due to a failure in the message counter verification. Therefore, the embodiment of the present application sets two states for the target counter, and can determine how to select the CT based on the current state of the target counter, thereby achieving a more effective synchronization mechanism to ensure the reliability and security of vehicle network communications. The state synchronization mechanism is as follows:

[0076] If the current state of the target counter is the pre-synchronization state, in order to prevent the reception failure caused by the time difference when the final message is received, the old CT stored in the target counter is selected; if the current state of the target counter is the completed synchronization state, it indicates that the whole network has completed synchronization at this time, and all slave nodes have at least entered the pre-synchronization state, so the new CT stored in the target counter is selected.

[0077] Specifically, the present application constructs a state synchronization subsystem of a target counter, that is, synchronously updating the state of the target counter, the process is as follows: Figure 7 As shown, including:

[0078] 1. The master node broadcasts a synchronization message, and the slave node obtains the synchronization message broadcast by the master node, and updates the current state of the target counter to the pre-synchronization state after verification.

[0079] 2. Each slave node feeds back the result of successful reception to the master node, and does not feed back if it fails.

[0080] 3. After collecting all the feedback, the master node broadcasts the "status of all nodes" again. At this time, all the slave nodes should be ready.

[0081] 4. Each slave node that receives the message will switch itself to the "Complete Synchronization" state. In order to prevent the reception failure caused by the time difference when receiving the final message, the slave node that enters the "Pre-Synchronization" state uses the old CT when sending messages to ensure that all receiving ends can receive them normally. The slave node that enters the "Complete Synchronization" state uses the new CT when sending messages, because at this time all slave nodes have at least entered the "Pre-Synchronization" state.

[0082] It should be noted that the requester of the synchronization request, ie, the synchronization initiator, may be a master node or a slave node. After the synchronization request is initiated, the synchronization update of the current state of the target counter is started according to the synchronization request.

[0083] In addition, in the case where the slave node does not receive the synchronization message sent by the master node in the first time, or the synchronization message is lost, especially when the ECU does not have the previous counter available when it is in the initial synchronization, the present application can adopt a redundant mechanism by the receiving end, that is, a short-term multiple repetition method. Because the synchronization message is a periodic message with a longer interval, the repetition mechanism has little impact on the load of the in-vehicle network. If the slave node still cannot receive it, it may be because the busoff or ECU has been restarted due to a fault, or it has suffered a denial of service attack. These three situations require detection technology, such as busoff recovery event recognition, ECU startup event recognition, and denial of service attack recovery event recognition. The first two are more common, and the third situation can be detected by the heartbeat mechanism. When the ECU recognizes these events, it needs to actively initiate a "synchronization message request" to the master node to notify the master node to immediately initiate a new round of synchronization. It should be noted that the slave node is in an initial state from the time the event is detected to the time the synchronization message is received, and other security messages other than message synchronization cannot be sent or received at this time.

[0084] The following describes the process of the sending end sending a communication message and the receiving end receiving a communication message through a specific embodiment.

[0085] 1. The sending process of the sender, combined with Figure 7 To illustrate the example of taking the sending end as any slave node, the following steps are included:

[0086] 1. Any slave node as the sender constructs a protocol data PDU based on business requirements and informs the CT manager to prepare for sending.

[0087] 2. The CT manager determines that when it is in the pre-synchronization state, it uses the old CT. If it has switched to the completed synchronization state, it selects the new CT.

[0088] 3. Input the slave node’s own port identification number SID, key Key, protocol data PDU, and selected CT value into the MAC calculator to calculate the MAC value.

[0089] 4. Combine PDU, CT, and MAC value. The message format is PDU followed by 1 byte of CT (the last 8 bits of the original CT), and CT followed by 2 bytes of MAC value (the first 16 bits of the original MAC).

[0090] 5. Send to the receiving end via the bus device.

[0091] 2. The receiving process of the receiving end. The process of receiving and parsing the communication message from the receiving node is as follows:

[0092] 1. The receiving end verifies and reads the message based on the E2E timeout verification mechanism, and breaks it into three parts: PDU, MAC, and CT. If the timeout occurs, the application layer is notified so that the application layer can respond in time;

[0093] 2. The receiving end uses the Counter verification mechanism and the FV verification mechanism to verify the validity of CT (whether it is duplicated, packet lost, or disordered) and the uniqueness check to see if it is an old historical message). If the verification fails, it indicates that there may be a security issue. The receiving end will discard the protocol data, retaining the duplication, packet loss, and disorder checking capabilities of E2E and the anti-replay capability of SecOC. If the CT and FV verifications are successful, the receiving end can identify the SID of the sending end, which helps to confirm the source of the message.

[0094] 3. The receiving end inputs the protocol data, CT, SID and preset key into the MAC calculator and uses the MAC mechanism to calculate a new MAC;

[0095] 4. The receiver compares the parsed MAC with the calculated MAC. If the two match, the message is authentic and the receiver passes the protocol data to the application layer. If they do not match, the message may have been tampered with and the receiver discards the protocol data.

[0096] In summary, the secure communication protocol of this application integrates the E2E protocol and the SecOC protocol and eliminates redundancy. The integrated protocol mechanism is as follows: Figure 8 As shown, including:

[0097] 1. Keep the E2E DataID mechanism: Figure 8 It is represented as SID, which is a unique number that clearly indicates the source of the message. Because in a secure network, the source of the message should always be known, so it does not need to be carried in the message. If the application layer definition cannot know the DataID information, this field needs to be carried in the message. This follows the E2E method. Regardless of whether the message carries DataID, DataID participates in the MAC calculation.

[0098] 2. Merge E2E's Counter and SecOC's FV: target counter. This target counter retains the structure of FV, that is, retains TripCounter, ResetCounter, MessageCounter and data structure definition, retains the FV verification mechanism in SecOC, and applies the Counter management mechanism in E2E to MessageCounter.

[0099] 3. Keep MAC and remove CRC: MAC has both integrity and authenticity effects, while CRC only has an integrity check effect. Therefore, remove the CRC mechanism and keep the MAC mechanism.

[0100] 4. Keep the timeout check: Keep the original E2E timeout check method at the receiving end.

[0101] In addition, the embodiment of the present application also sets three states for the target counter, namely, the initial state, the pre-synchronization state and the completed synchronization state, and sets a target counter state synchronization mechanism, thereby realizing a more effective synchronization mechanism to ensure the reliability and security of the vehicle network communication. Among them, the state synchronization mechanism has been introduced above and will not be repeated here.

[0102] Specifically, this application integrates the key attributes of the two security protocols SecOC and E2E and eliminates redundant attributes to obtain a new security protocol that can meet both functional safety and information security requirements. This protocol has obvious savings in CPU computing resources and communication message load resources compared to simply superimposing SecOC and E2E.

[0103] At the same time, through notification and feedback, the nodes in the network can maintain three counter states, thereby solving the problem of key signal communication failure caused by reset counter message synchronization delay or notification failure, thereby ensuring information security and functional safety while further improving the reliability of the network.

[0104] In summary, compared with the prior art, the present application specifically includes the following optimization points:

[0105] 1. Combine the Counter of E2E and the FV of SecOC, and unify the counter value CT.

[0106] 2. The CT value retains the data structure of the FV of SecOC.

[0107] 3. Remove CRC and retain the MAC mechanism and checksum in SecOC.

[0108] 4. The structure of the security data packet is a combination of PDU, CT, and MAC value. The message format is PDU followed by 1 byte of CT (the last 8 bits of the original CT), and CT followed by 2 bytes of MAC value (the first 16 bits of the original MAC).

[0109] 5. The validity of CT (whether there is duplication, packet loss, or disorder) is verified based on the Counter verification mechanism of E2E, and the uniqueness of CT (whether it is a historical old message) is verified based on the FV verification mechanism of SecOC. If it fails, it is discarded, retaining the duplication, packet loss, disorder inspection and anti-replay capabilities of E2E and SecOC.

[0110] 6. The receiving end determines the message source SID based on the message, and inputs the SID, PDU, CT and key Key into the MAC calculator. The calculated MAC value is compared with the MAC value in the message. If they do not match, it is discarded. Otherwise, the PDU is passed to the application layer, and the integrity capability of MAC is used instead of CRC.

[0111] 7. Each slave node in the target counter synchronization subsystem responds to the master node after receiving the synchronization message.

[0112] 8. After the master node in the target counter synchronization subsystem collects the responses from all slave nodes, it broadcasts all slave node status messages again to inform each slave node that each slave node in the entire network has received the synchronization message.

[0113] 9. In the target counter synchronization subsystem, when the slave node receives the synchronization message and passes the verification, it enters the pre-synchronization state. In this state, the slave node has two CTs, the old and the new.

[0114] 10. In the target counter synchronization subsystem, in order to prevent the reception failure caused by the time difference when receiving the final message, the party entering the pre-synchronization state uses the old CT when sending messages to ensure that all receiving ends receive them normally. The party entering the completed synchronization state uses the new CT when sending messages, because at this time all slave nodes have at least entered the pre-synchronization state.

[0115] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. The electronic device may include:

[0116] A memory 901 , a processor 902 , and a computer program stored in the memory 901 and executable on the processor 902 .

[0117] When the processor 902 executes the program, the in-vehicle communication method provided in the above embodiment is implemented.

[0118] Furthermore, the electronic device further comprises:

[0119] The communication interface 903 is used for communication between the memory 901 and the processor 902 .

[0120] The memory 901 is used to store computer programs that can be executed on the processor 902 .

[0121] The memory 901 may include a high-speed RAM (Random Access Memory) memory, and may also include a non-volatile memory, such as at least one disk memory.

[0122] If the memory 901, the processor 902 and the communication interface 903 are implemented independently, the communication interface 903, the memory 901 and the processor 902 can be connected to each other through a bus and communicate with each other. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0123] Optionally, in a specific implementation, if the memory 901, the processor 902 and the communication interface 903 are integrated on a chip, the memory 901, the processor 902 and the communication interface 903 can communicate with each other through an internal interface.

[0124] The processor 902 may be a CPU (Central Processing Unit), or an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present application.

[0125] An embodiment of the present application also provides a vehicle, comprising the above electronic device.

[0126] An embodiment of the present application also provides a computer program product, including a computer program or instructions, which implements the above-mentioned in-vehicle communication method when the computer program or instructions are executed by a processor.

[0127] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not necessarily directed to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0128] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0129] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0130] It should be understood that the various parts of the present application can be implemented in hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, the steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.

[0131] A person of ordinary skill in the art may understand that all or part of the steps carried by the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the above-mentioned program may be stored in a computer-readable storage medium, which, when executed, includes one of the steps of the method embodiment or a combination thereof.

[0132] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for in-vehicle communication, characterized in that: The method is applied to a transmitting end, wherein the method comprises the following steps: Constructing protocol data of the message to be sent; Generate a communication message based on a secure communication protocol and the protocol data, wherein the secure communication protocol includes a DataID mechanism of a functional safety protocol E2E, a message authentication code MAC mechanism and a target counter of an information security protocol SecOC, the target counter includes a Counter verification mechanism of E2E, a freshness value FV data structure and an FV verification mechanism of SecOC, and the communication message is generated based on the DataID mechanism, the MAC mechanism and the target counter; In-vehicle communication is performed based on the communication message.

2. The in-vehicle communication method according to claim 1, characterized in that: The generating of the communication message based on the secure communication protocol and the protocol data comprises: Selecting a counter value CT of the target counter; Acquire a port identification number SID based on the DataID mechanism; Inputting the protocol data, the CT of the target counter, the SID and a preset key into a MAC calculator, the MAC calculator calculating a MAC based on the MAC mechanism; The CT and the MAC are sequentially filled after the protocol data to obtain the communication message.

3. A method for in-vehicle communication, characterized in that: The method is applied to a receiving end, wherein the method comprises the following steps: Acquire a communication message sent by a sending end, wherein the sending end generates a communication message based on a secure communication protocol and the protocol data, the secure communication protocol includes a DataID mechanism of a functional safety protocol E2E, a message authentication code MAC mechanism and a target counter of an information security protocol SecOC, the target counter includes a Counter verification mechanism of E2E, a freshness value FV data structure and an FV verification mechanism of SecOC, and the communication message is generated based on the DataID mechanism, the MAC mechanism and the target counter; The communication message is parsed to obtain protocol data of the message message to be sent.

4. The in-vehicle communication method according to claim 3, characterized in that: The parsing of the communication message to obtain protocol data of the message message to be sent includes: Parsing the communication message to obtain protocol data, CT and MAC of the target counter; Verifying the validity of the CT based on the Counter verification mechanism, and verifying the uniqueness of the CT based on the FV verification mechanism; If the verification fails, the protocol data is discarded, and if the verification succeeds, the SID of the sender is identified; Inputting the protocol data, the CT of the target counter, the SID and a preset key into a MAC calculator, the MAC calculator calculating a MAC based on the MAC mechanism; If the MAC obtained by parsing is consistent with the MAC calculated by the MAC calculator, the protocol data is passed to the application layer, otherwise the protocol data is discarded.

5. The in-vehicle communication method according to claim 4, characterized in that: The secure communication protocol also includes an E2E timeout verification mechanism, and before parsing the communication message to obtain the protocol data, CT and MAC, it also includes: A timeout verification is performed on the communication message based on the timeout verification mechanism.

6. The in-vehicle communication method according to any one of claims 1 to 5, characterized in that: The communication node in the vehicle includes a master node and a slave node, and the state synchronization update action of the target counter is triggered according to the synchronization request of the slave node or the synchronization request of the master node, wherein the state synchronization update action of the slave node includes: Get the synchronization message broadcast by the master node; After verifying that the synchronization message passes, the current state is updated to the first state, and a response message is fed back to the master node. If the verification fails, no feedback is given, wherein the master node broadcasts the current state of all slave nodes after obtaining the response messages of all slave nodes; If the current status of all slave nodes broadcast by the master node is received, the current status is updated to the second status; otherwise, the current status is retained as the first status.

7. The in-vehicle communication method according to claim 6, characterized in that: After triggering a state synchronization update action of the target counter according to a synchronization request of the slave node or a synchronization request of the master node, selecting a counter value CT of the target counter includes: identifying a current state of the target counter; If the current state is the first state, selecting the old CT stored in the target counter; If the current state is the second state, the new CT stored in the target counter is selected.

8. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the in-vehicle communication method according to any one of claims 1 to 7.

9. A vehicle, characterized in that: The electronic device comprising the electronic device described in claim 8.

10. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed, the in-vehicle communication method according to any one of claims 1 to 7 is implemented.

Images