CAN network security transmission method and system based on address binding relationship credibility

Abstract

The embodiment of the application provides a CAN network security transmission method and system based on an address binding relationship, which comprises the following steps: a first ECU makes a first ECU digital certificate of a first ECU and CAN network address binding relationship, and sends a CAN message containing the first ECU digital certificate to a second ECU, and meanwhile, acquires a second ECU digital certificate of a second ECU and CAN network address binding relationship sent by the second ECU; the first ECU verifies the second ECU digital certificate in the CAN message, and obtains a first verification result; according to the first verification result and a second verification result obtained by the second ECU, it is judged whether the first ECU and the second ECU can communicate with each other; within the life cycle of the certificate, the certificate exchange and verification between the first ECU and the second ECU are performed only once, when the CAN message is sent, the first ECU uses a first process flow key to encrypt the CAN message, and the second ECU uses a second process flow key to encrypt the CAN message, wherein the first process flow key and the second process flow key are different.

Description

Technical Field

[0001] This application relates to the field of CAN network technology, and in particular to a secure CAN network transmission method and system based on a trusted address binding relationship. Background Technology

[0002] With the continuous development of the intelligent connected vehicle industry, the demand for secure transmission of electronic control units (ECUs) on the controller area network (CAN) is becoming increasingly strong.

[0003] When encrypting CAN messages, either block ciphers, such as AES, or stream ciphers, such as CHACHA20 and ZUC, can be used. For example, CN114945169B provides a CAN network encryption scheme based on block cipher algorithms; CN113132082A provides a method for improving CAN network security based on stream ciphers. Both schemes calculate a shared encryption key between the sending and receiving ECUs. That is, both ECUs use this encryption key to encrypt CAN messages when sending them. However, sharing a single key reduces the system's ability to defend against collision attacks. Especially when both sides share a stream cipher key to encrypt different CAN messages, an attacker can easily obtain the plaintext CAN message by eavesdropping, performing a simple XOR operation, and guessing. Furthermore, the ECU serial numbers in CN114945169B and CN113132082A are transmitted in plaintext, increasing the risk of the key being cracked through a plaintext attack.

[0004] Secondly, regarding the trustworthiness of the ECU identity, CN113132082A does not consider the trustworthiness of the ECU. While CN114945169B does consider the trustworthiness of the ECU, its ECU certificate does not include the ECU's CAN network address. This means that an ECU with a fake CAN network address can still impersonate a normal ECU and join the CAN network by tampering with the random numbers and timestamps in the already sent registration messages. It can even impersonate the master ECU to send network broadcasts, thereby increasing the CAN network load rate.

[0005] Third, regarding the prevention of replay attacks. CN114945169B uses timestamps while CN113132082A uses message sequence numbers. If the old ECU uses timestamps and the new ECU uses message sequence numbers, the new ECU will be unable to replace the old ECU. Although CN114945169B and CN113132082A consider the possibility of replay attacks, ECU updates and replacements are common in CAN networks. If their methods are followed, messages sent by the new ECU will be misjudged as replay attacks, causing the newly replaced ECU to malfunction. Finally, not all scenarios require prevention of replay attacks. For example, during ECU debugging, it may be necessary to replay relevant messages to locate problems. Summary of the Invention

[0006] In view of this, embodiments of this application provide a secure CAN network transmission method based on trusted address binding relationships. One or more embodiments of this application also relate to a secure CAN network transmission system based on trusted address binding relationships, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0007] According to a first aspect of the embodiments of this application, a secure CAN network transmission method based on a trusted address binding relationship is provided, comprising: The first ECU creates a digital certificate for binding the first ECU to the CAN network address and sends a CAN message containing the first ECU digital certificate to the second ECU. At the same time, the second ECU creates a digital certificate for binding the second ECU to the CAN network address and sends a CAN message containing the second ECU digital certificate to the first ECU. The first ECU verifies the digital certificate of the second ECU in the CAN message and obtains a first verification result. At the same time, the second ECU verifies the digital certificate of the first ECU in the CAN message and obtains a second verification result. Based on the first verification result and the second verification result, determine whether the first ECU and the second ECU can communicate; When it is determined that the first ECU and the second ECU can communicate, the first ECU / second ECU generates a first process flow key / second process flow key, and then uses the first process flow key / second process flow key to encrypt the CAN message containing the transmission data to obtain the encrypted CAN message. The encrypted CAN message is then sent to the second ECU / first ECU. After receiving the encrypted CAN message, the second ECU / first ECU recovers the first process flow key / second process flow key, and then uses the recovered first process flow key / second process flow key to decrypt the encrypted CAN message, thereby obtaining the transmission data in the CAN message.

[0008] Preferably, during the lifecycle of the digital certificate, the certificate exchange and verification between the first ECU and the second ECU is performed only once; the ECU digital certificate includes a digital signature, the ECU digital certificate validity period, ciphertext of ECU address and identity binding relationship information, and a DMK key index number; wherein, the DMK key index number includes the DMK key index length and the DMK key index number value; the ciphertext of ECU address and identity binding relationship information includes the ECU device serial number, the CAN network identifier and CAN network address of the CAN network where the ECU is located, the TMK key index length and the TMK key index number value, and the ECU timing credential type.

[0009] Preferably, the first ECU verifies the second ECU digital certificate in the CAN message to obtain a first verification result, including: The first ECU performs a first valid verification on the digital signature and the validity period of the second ECU digital certificate in the CAN message, and obtains a first valid verification result. If the first valid verification result fails, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is impossible. If the first valid verification result is passed, the first ECU extracts the DMK key index number and key type from the second ECU digital certificate, and uses the pre-stored key set to extract the DMK key value corresponding to the DMK key index number and key type; The first ECU uses the calculation method of the device authentication process key DSK and the DMK key value to calculate the DSK key value, and uses the DSK key value to decrypt the encrypted ECU address and identity binding relationship information in the ECU digital certificate to obtain the plaintext ECU address and identity binding relationship information.

[0010] Preferably, the first ECU verifies the second ECU digital certificate in the CAN message to obtain a first verification result, which further includes: The first ECU obtains the ECU device serial number, the CAN network identifier and the CAN network address of the CAN network where the ECU is located from the plaintext ECU address and identity binding relationship information, and obtains the comparison result by comparing the CAN network address with the source address of the CAN message; If the comparison result is inconsistent, the first ECU generates a first verification result that the first ECU and the second ECU cannot communicate. If the comparison results are consistent, the first ECU uses a pre-stored certificate replay attack detection list to effectively verify the ECU device serial number and the CAN network address; If the valid verification of the ECU device serial number and / or the CAN network address fails, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is not possible. If the validity verification of the ECU device serial number and the CAN network address both pass, the first ECU verifies the service message sent by the second ECU based on the communication replay attack detection list and the replay attack detection whitelist, and obtains the first verification result.

[0011] Preferably, the first ECU verifies the CAN message sent by the second ECU based on the communication replay attack detection list and the replay attack detection whitelist, and obtains a first verification result including: The first ECU effectively verifies the CAN network identifier and the CAN network address based on the replay attack detection whitelist, and obtains the verification result; If the verification result is valid, then the CAN messages sent from the CAN network identifier and the CAN network address will not be subject to replay attack detection. If the verification result is invalid, the first ECU uses the CAN network identifier and the CAN network address to verify the validity of the timing certificate corresponding to the CAN network identifier and the CAN network address in the pre-stored communication replay attack detection list, and obtains the validity verification result; If the validity verification result is invalid, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is not possible; If the validity verification result is valid, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is possible.

[0012] Preferably, the first ECU / second ECU generates a first process flow key / second process flow key, and then uses the first process flow key / second process flow key to encrypt the CAN message containing the transmitted data, resulting in an encrypted CAN message including: The first ECU extracts the TMK key index number and key type from the first ECU digital certificate, and uses the pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; The first ECU generates a first encryption key generation factor based on the time sequence certificate and time sequence certificate type in the first ECU digital certificate, and calculates the process key TSK for communication encryption using the first encryption key generation factor, the stream key generation algorithm and the TMK key value, and uses the process key TSK as the first process stream key for communication encryption. The first ECU uses the first process flow key for communication encryption to encrypt the CAN message containing the transmitted data, thereby obtaining the encrypted CAN message.

[0013] Preferably, after receiving the encrypted CAN message, the second ECU / first ECU recovers the first process flow key / second process flow key, and then uses the recovered first process flow key / second process flow key to decrypt the encrypted CAN message, thereby obtaining the transmitted data in the CAN message, including: The second ECU extracts the TMK key index number and key type from the first ECU digital certificate, and uses the pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; The second ECU generates a first process flow key generation factor based on the time sequence certificate and time sequence certificate type in the first ECU digital certificate, and calculates the process key TSK for communication decryption using the first process flow key generation factor, the flow key generation algorithm and the TMK key value, and uses the process key TSK as the first process flow key for communication decryption. The second ECU uses the first process flow key for communication decryption to decrypt the encrypted CAN message, thereby obtaining the transmitted data in the CAN message.

[0014] According to a second aspect of the embodiments of this application, a CAN network security transmission system based on a trusted address binding relationship is provided, comprising: The first ECU is configured to create a first ECU digital certificate that binds the first ECU to the CAN network address, and send a CAN message containing the first ECU digital certificate to the second ECU; verify the second ECU digital certificate in the CAN message to obtain a first verification result, and determine whether the first ECU and the second ECU can communicate based on the first verification result and the second verification result; when it is determined that the first ECU and the second ECU can communicate, obtain a first process key generation factor from the first ECU digital certificate, generate a first process flow key using the first process key generation factor, encrypt the CAN message containing the transmission data using the first process flow key to obtain an encrypted CAN message, and send the encrypted CAN message to the second ECU; The second ECU is configured to create a second ECU digital certificate that binds the second ECU to the CAN network address, and sends a CAN message containing the second ECU digital certificate to the first ECU; the first ECU digital certificate in the CAN message is verified to obtain a second verification result; based on the first verification result and the second verification result, it is determined whether the first ECU and the second ECU can communicate; when it is determined that the first ECU and the second ECU can communicate, after receiving the encrypted CAN message, the first process key generation factor is obtained from the first ECU digital certificate, and then the first process key generation factor is used to generate a first process flow key, and the first process flow key is used to decrypt the encrypted CAN message to obtain the transmission data in the CAN message.

[0015] According to a third aspect of the embodiments of this application, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement any of the steps of the CAN network security transmission method based on address binding relationship.

[0016] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of any one of the described methods for secure CAN network transmission based on address binding relationships.

[0017] According to a fifth aspect of the present application, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described CAN network security transmission method based on trusted address binding relationship.

[0018] The embodiments of this application provide a secure CAN network transmission scheme based on trusted address binding relationships. First, by adding a CAN network address to the ECU digital certificate, this invention achieves a trusted mapping between the ECU's CAN network address and the device serial number, thus preventing counterfeit ECUs from tampering with the CAN network address to launch denial-of-service attacks against legitimate ECUs. Secondly, by using different key generation factors in different ECUs to generate different first encryption process keys and second encryption process keys, this invention can effectively avoid the risk of plaintext leakage due to key duplication, thereby preventing collision attacks and improving communication encryption. Third, by adding a time-series credential type to the ECU digital certificate, this invention enables new and old ECUs to switch replay attack detection methods safely and smoothly. At the same time, it can further extend the replay attack detection lifecycle of the same ECU and mitigate the possibility of collision attacks that may occur after the replay attack detection field overflows. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a secure CAN network transmission method based on a trusted address binding relationship, according to one embodiment of this application. Figure 2 This is a flowchart illustrating a secure CAN network transmission method based on a trusted address binding relationship, provided in one embodiment of this application. Figure 3 This is a flowchart of a CAN network ECU secure communication method based on stream key according to an embodiment of this application; Figure 4 This is a flowchart of a business method for ECU certificate exchange provided in one embodiment of this application; Figure 5 This is a schematic diagram illustrating the rules governing the binding relationship between ECU addresses and identities, provided in one embodiment of this application. Figure 6 This is a flowchart of a CAN network address validity check method in the ECU certificate exchange process provided in one embodiment of this application; Figure 7 This is a flowchart of a method for updating replay attack detection records based on ECU digital certificates, provided in one embodiment of this application. Figure 8 This is a flowchart of a method for ECU communication according to an embodiment of this application; Figure 9 This is a flowchart of a replay attack detection method based on a replay attack detection list and a whitelist provided in one embodiment of this application; Figure 10This is a flowchart of a method for querying the serial number of a peer ECU device according to an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an ECU with address binding relationship management and replay attack prevention detection provided in one embodiment of this application; Figure 12 This is a schematic diagram of a CAN network security transmission system based on a trusted address binding relationship, provided in one embodiment of this application. Detailed Implementation

[0020] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0021] In this application, the first ECU creates a first ECU digital certificate that binds the first ECU to the CAN network address, and sends a CAN message containing the first ECU digital certificate to the second ECU. At the same time, the first ECU obtains a second ECU digital certificate that binds the second ECU to the CAN network address sent by the second ECU. The first ECU verifies the second ECU digital certificate in the CAN message and obtains a first verification result. Based on the first verification result and the second verification result obtained by the second ECU, it determines whether the first ECU and the second ECU can communicate. During the certificate's lifespan, the certificate exchange and verification between the first ECU and the second ECU is performed only once.

[0022] When communication is deemed feasible, if used as a transmitter, the first ECU and the second ECU use a stream key to encrypt and transmit the CAN message containing the data. The stream key used by the first ECU and the second ECU are completely different, and the stream key used for each encryption operation within the lifecycle of each ECU is also different. That is, the first ECU and the second ECU do not share the encryption process key, and the encryption process key is not shared between each encryption call of each ECU. If used as a receiver, the first ECU and the second ECU first perform replay attack detection on the received CAN message before decryption.

[0023] Figure 1 A flowchart of a CAN network security transmission method based on address binding relationship provided in one embodiment of this application is shown, which specifically includes the following steps.

[0024] Step S101: The first ECU creates a first ECU digital certificate that binds the first ECU to the CAN network address, and sends a CAN message containing the first ECU digital certificate to the second ECU. At the same time, the second ECU creates a second ECU digital certificate that binds the second ECU to the CAN network address, and sends a CAN message containing the second ECU digital certificate to the first ECU. In one specific embodiment of this application, the certificate exchange and verification between the first ECU and the second ECU is performed only once during the lifecycle of the digital certificate; the ECU digital certificate includes a digital signature, ECU digital certificate validity period, ECU address and identity binding relationship information ciphertext, and DMK key index number; wherein, the DMK key index number includes DMK key index length and DMK key index number value; the ECU address and identity binding relationship information ciphertext includes ECU device serial number, CAN network identifier and CAN network address of the CAN network where the ECU is located, TMK key index length and TMK key index number value, and ECU timing credential type. Step S102: The first ECU verifies the second ECU digital certificate in the CAN message to obtain a first verification result, and the second ECU verifies the first ECU digital certificate in the CAN message to obtain a second verification result; In one specific embodiment of this application, the first ECU verifies the digital certificate of the second ECU in the CAN message, and the first verification result includes: The first ECU performs a first valid verification on the digital signature and the validity period of the second ECU digital certificate in the CAN message, and obtains a first valid verification result. If the first valid verification result fails, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is impossible. If the first valid verification result is passed, the first ECU extracts the DMK key index number and key type from the second ECU digital certificate, and uses the pre-stored key set to extract the DMK key value corresponding to the DMK key index number and key type; The first ECU uses the calculation method of the device authentication process key DSK and the DMK key value to calculate the DSK key value, and uses the DSK key value to decrypt the encrypted ECU address and identity binding relationship information in the ECU digital certificate to obtain the plaintext ECU address and identity binding relationship information.

[0025] In one specific embodiment of this application, the first ECU verifies the digital certificate of the second ECU in the CAN message to obtain a first verification result, which further includes: The first ECU obtains the ECU device serial number, the CAN network identifier and the CAN network address of the CAN network where the ECU is located from the plaintext ECU address and identity binding relationship information, and obtains the comparison result by comparing the CAN network address with the source address of the CAN message; If the comparison result is inconsistent, the first ECU generates a first verification result that the first ECU and the second ECU cannot communicate. If the comparison results are consistent, the first ECU uses a pre-stored certificate replay attack detection list to effectively verify the ECU device serial number and the CAN network address; If the valid verification of the ECU device serial number and / or the CAN network address fails, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is not possible. If the validity verification of the ECU device serial number and the CAN network address both pass, the first ECU verifies the service message sent by the second ECU based on the communication replay attack detection list and the replay attack detection whitelist, and obtains the first verification result.

[0026] In one specific embodiment of this application, the first ECU verifies the CAN message sent by the second ECU based on the communication replay attack detection list and the replay attack detection whitelist, and obtains a second verification result including: The first ECU effectively verifies the CAN network identifier and the CAN network address based on the replay attack detection whitelist, and obtains the verification result; If the verification result is valid, then the CAN messages sent from the CAN network identifier and the CAN network address will not be subject to replay attack detection. If the verification result is invalid, the first ECU uses the CAN network identifier and the CAN network address to verify the validity of the timing certificate corresponding to the CAN network identifier and the CAN network address in the pre-stored communication replay attack detection list, and obtains the validity verification result; If the validity verification result is invalid, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is not possible; If the validity verification result is valid, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is possible.

[0027] It should be noted that, in the specific embodiments of this application, the second verification result generated by the second ECU includes a second verification result that the second ECU and the first ECU cannot communicate and a second verification result that the second ECU and the first ECU can communicate. The second verification result that the second ECU and the first ECU cannot communicate is similar to the first verification result generated by the first ECU that the first ECU and the second ECU cannot communicate, and the second verification result that the second ECU and the first ECU can communicate is also similar to the first verification result generated by the first ECU that the first ECU and the second ECU can communicate. Therefore, they will not be described again here.

[0028] Step S103: Based on the first verification result and the second verification result, determine whether the first ECU and the second ECU can communicate; If the first verification result indicates that the first ECU and the second ECU can communicate, and the second verification result indicates that the second ECU and the first ECU can communicate, then it is determined that the first ECU and the second ECU can communicate. If the first verification result indicates that the first ECU and the second ECU cannot communicate, and / or the second verification result indicates that the second ECU and the first ECU cannot communicate, then it is determined that the first ECU and the second ECU cannot communicate.

[0029] Step S104: When it is determined that the first ECU and the second ECU can communicate, the first ECU / second ECU generates a first process flow key / second process flow key, and then uses the first process flow key / second process flow key to encrypt the CAN message containing the transmission data to obtain the encrypted CAN message. The encrypted CAN message is then sent to the second ECU / first ECU so that after receiving the encrypted CAN message, the second ECU / first ECU can recover the first process flow key / second process flow key, and then use the recovered first process flow key / second process flow key to decrypt the encrypted CAN message to obtain the transmission data in the CAN message.

[0030] In one specific embodiment of this application, the first ECU / second ECU generates a first process flow key / second process flow key, and then uses the first process flow key / second process flow key to encrypt a CAN message containing transmitted data, resulting in an encrypted CAN message including: The first ECU extracts the TMK key index number and key type from the first ECU digital certificate, and uses the pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; The first ECU generates a first encryption key generation factor based on the time sequence certificate and time sequence certificate type in the first ECU digital certificate, and calculates the process key TSK for communication encryption using the first encryption key generation factor, the stream key generation algorithm and the TMK key value, and uses the process key TSK as the first process stream key for communication encryption. The first ECU uses the first process flow key for communication encryption to encrypt the CAN message containing the transmitted data, thereby obtaining the encrypted CAN message.

[0031] Similarly, the second ECU extracts the TMK key index number and key type from the second ECU digital certificate, and uses the pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; the second ECU generates a second encryption key generation factor based on the time sequence certificate and time sequence certificate type in the second ECU digital certificate, and uses the second encryption key generation factor, the stream key generation algorithm and the TMK key value to calculate the process key TSK for communication encryption, and uses the process key TSK as the second process stream key for communication encryption; the second ECU uses the second process stream key for communication encryption to encrypt the CAN message containing the transmitted data to obtain the encrypted CAN message.

[0032] It should be noted that because the first encryption key generation factor and the second encryption key generation factor are different, the process key TSK calculated by the first ECU is a one-time value of the first process flow key; the process key TSK calculated by the second ECU is a one-time value of the second process flow key, and the two are not the same. Only when the two keys are different can guessing attacks based on simple XOR operations on the flow key be avoided.

[0033] In one specific embodiment of this application, after the second ECU / first ECU receives the encrypted CAN message, it recovers the first process flow key / second process flow key, and then uses the recovered first process flow key / second process flow key to decrypt the encrypted CAN message, thereby obtaining the transmitted data in the CAN message, including: The second ECU extracts the TMK key index number and key type from the first ECU digital certificate, and uses the pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; The second ECU generates a first process flow key generation factor based on the time sequence certificate and time sequence certificate type in the first ECU digital certificate, and calculates the process key TSK for communication decryption using the first process flow key generation factor, the flow key generation algorithm and the TMK key value, and uses the process key TSK as the first process flow key for communication decryption. The second ECU uses the first process flow key for communication decryption to decrypt the encrypted CAN message, thereby obtaining the transmitted data in the CAN message.

[0034] Similarly, the first ECU extracts the TMK key index number and key type from the second ECU digital certificate, and uses the pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; The first ECU generates a second process flow key generation factor based on the time sequence certificate and time sequence certificate type in the second ECU digital certificate, and calculates the process key TSK for communication decryption using the second process flow key generation factor, the flow key generation algorithm and the TMK key value, and uses the process key TSK as the second process flow key for communication decryption. The first ECU uses the second process flow key for communication decryption to decrypt the encrypted CAN message, thereby obtaining the transmitted data in the CAN message.

[0035] Figure 2 This is a flowchart illustrating a specific method for secure CAN network transmission based on a trusted address binding relationship, as provided in one embodiment of this application. Figure 2 As shown, it includes: Step S1: Create an ECU digital certificate binding the ECU to the CAN network address. The ECU digital certificate uses the X.509v3 format, and the CN field in the ECU digital certificate contains the ECU's identity information. The ECU identity information includes the ECU's device serial number, the CAN network address of the CAN network it belongs to, and the CAN network identifier. The ECU identity information is encrypted using the ECU identity information protection key DSK.

[0036] Step S2: Each ECU is pre-configured with a communication encryption master key TMK, a device authentication encryption master key DMK, and an ECU digital certificate. The DMK is used to derive the key DSK for decrypting the ECU's identity information. The communication encryption master key TMK and the device authentication encryption master key DMK are two different keys, distinguished by different key types.

[0037] Step S3: The first ECU and the second ECU exchange device identity certificates and generate a certificate replay attack detection list S1. The replay attack detection list S1 contains the CAN network addresses of all ECUs communicating with the current ECU and the corresponding current and historical ECU serial numbers.

[0038] Step S4: When the first ECU sends data, it uses the first key generation factor P1 to generate the first process key TSK1 to encrypt the message and transmit it. When the second ECU receives data, it first performs communication replay attack detection, and then uses the key generation factor P1 to generate the first process key TSK1 to decrypt the message. Note that the value of the first key generation factor P1 used to generate TSK1 is different each time.

[0039] Step S5: When the second ECU sends data, it uses the second key generation factor P2 to generate a second process key TSK2 to encrypt the message and transmit it. When the first ECU receives data, it first performs communication replay attack detection, and then uses the second key generation factor P2 to generate the second process key TSK2 to decrypt the message. Note that the value of the second key generation factor P2 used each time TSK2 is generated is different, and also different from the value of the first key generation factor P1 used by the first ECU in all previous iterations.

[0040] Figure 3 This is a flowchart of a CAN network ECU secure communication method based on stream key according to an embodiment of this application, as shown below. Figure 3 As shown, the process is divided into two phases. The first phase involves both communicating parties exchanging their respective ECU digital certificates. The second phase begins with the sending ECU checking whether an ECU digital certificate has not been exchanged or if the ECU digital certificate has expired. If so, communication returns to the first phase; otherwise, both communicating parties encrypt the CAN message using their respective process keys.

[0041] Once the two parties have completed the certificate exchange, they can proceed directly to the second phase of communication without exchanging certificates again.

[0042] Figure 4 This is a flowchart of a business method for ECU certificate exchange provided in one embodiment of this application, as follows: Figure 4 As shown, it includes: Step 401: The first ECU sends its digital certificate CERT-A. The digital certificate contains encrypted identity information of the first ECU. Step 402: The second ECU verifies the legality of the first ECU's digital certificate, then decrypts the first ECU's identity information, verifies the legality of the CAN network address from which the certificate originates, and finally adds or modifies the replay attack detection record S1-A based on the received first ECU digital certificate.

[0043] Step 403: The second ECU sends its digital certificate CERT-B, which contains encrypted identity information of the second ECU. Step 404: The first ECU verifies the legality of the second ECU's digital certificate, then decrypts the second ECU's identity information, verifies the legality of the CAN network address from which the certificate originates, and finally adds or modifies the replay attack detection record S1-B based on the received second ECU digital certificate.

[0044] Figure 5 This is a schematic diagram illustrating the rules governing the binding relationship between ECU addresses and identities according to an embodiment of this application, as shown below. Figure 5 As shown, the ECU digital certificate ensures the trustworthiness of the ECU's physical identity and logical network address. The ECU certificate uses the X.509 v3 format, and the CN field in the ECU digital certificate contains information about the binding relationship between the ECU and the CAN network address.

[0045] Rules governing the relationship between ECU address and identity binding information: The calculation method for the device authentication process key DSK: DSK = GEN(DMK, "Certificate Issuance Date"||"ECU Digital Certificate Serial Number"||BITWISE_NOT("ECU Digital Certificate Serial Number")||"ECU Digital Certificate Serial Number"||BITWISE_NOT("ECU Digital Certificate Serial Number")). Where: GEN is the key generation algorithm, such as HMAC-SHA256 or HKDF; DMK is the device identity master key, 256 bits long, consisting of 10 groups stored in the key set; BITWISE_NOT is the bitwise NOT operation.

[0046] Method for calculating ciphertext of ECU identity information: ECU identity information ciphertext = ENC(DSK, "CAN network identifier"||"CAN network address"||"ECU device serial number"||"time sequence credential type"||"TMK key index number").

[0047] Where: "||" represents bit string concatenation; DSK is the device authentication process key; ENC is the encryption algorithm, which can be the same as or different from the encryption algorithm used in the encryption process; the time sequence credential type value includes: "0x00 - sender timestamp" and "0x01 - sender CAN message sequence number"; the ECU device serial number includes the ECU device serial number length and the ECU device serial number value; the TMK key index number includes the TMK key index number length and the TMK key index number value.

[0048] The timing credential is a 4-byte CAN message field generated by the first ECU and transmitted to the second ECU. It distinguishes the order in which CAN messages are generated. The timing credential serves both to prevent replay attacks and as part of the key generation factor in the encryption process, ensuring that keys generated by different ECUs are unique. When the timing credential type value is 0x00, the sender enters its local timestamp in the timing credential field; when the timing credential type value is 0x01, the sender enters the sequence number of the corresponding CAN message in the timing credential field.

[0049] Figure 6 This is a flowchart of a CAN network address validity check method in the ECU certificate exchange process provided in one embodiment of this application, as shown below. Figure 6 As shown, it includes: Step 601: The second ECU verifies whether the digital signature in the digital certificate of the first ECU is valid. If it is invalid, the communication is terminated. Step 602: The second ECU verifies the validity period of the first ECU's digital certificate. If the certificate has expired, communication is terminated. Step 603: The second ECU decrypts the identity information of the first ECU and verifies whether the network address in the digital certificate of the first ECU is consistent with the source address in the CAN message header. If they are inconsistent, communication is terminated. Step 604: The second ECU verifies the identity information in the digital certificate verified by the first ECU. If the identity information already exists in the certificate replay attack detection list S1 and is invalid, then communication is terminated. Step 605: The second ECU verifies the identity information in the digital certificate verified by the first ECU. If the identity information already exists in the certificate replay attack detection list S1 and is in a valid state, but the network address in the certificate is different from the network address in the valid record, then communication is terminated. The CAN message header contains: CAN message priority, reserved bits, data page, message format, CAN message destination address, and source address.

[0050] The certificate replay attack detection list S1 is shown in Table 1 below: Table 1: List of Certificate Replay Attack Detections (S1)

[0051] Decrypting ECU identity information ciphertext First, extract the encrypted ECU identity information from the CN field of the received digital certificate; Second, based on the DMK key index length, extract the DMK key index number, key type, and ECU identity information ciphertext from the encrypted ECU identity information; Third, extract the corresponding DMK key value from the key set according to the key type and DMK key index number; Fourth, according to the calculation method of DSK, use the DMK key value to calculate the DSK key value; Fifth, based on the identity encryption algorithm, the DSK key value is used to decrypt the ECU identity information ciphertext; Sixth, obtain the CAN network identifier, CAN network address, ECU device serial number, ECU timing credential type, and TMK key index number from the plaintext after decrypting the ECU identity information ciphertext.

[0052] The structure of the key set is shown in Table 2 below: Table 2: Key Set Structure

[0053] Figure 7 This is a flowchart of a method for updating replay attack detection records based on ECU digital certificates, provided in one embodiment of this application. Figure 7 As shown, after the receiving ECU (also known as the second ECU) verifies the legality of the CERT digital signature of the received sending ECU (also known as the first ECU), it searches for the communication replay attack detection list S2 in the current ECU according to the CAN network address ADDR in CERT. Let the search result be S'.

[0054] If S' is empty, a valid replay attack detection record will be added to S2 according to the ECU identity information in the certificate, and the process will end. If S' is not empty, then perform the following steps: Step 1: Determine if there is a valid record in S'. If not, report an error and terminate the current communication.

[0055] Step 2: Set the currently valid replay attack detection records in S' to invalid.

[0056] Step 3: Determine if the ECU device serial number or timing certificate type in the certificate does not exist in S': If it does not exist, add a valid replay attack detection record in S2 according to the ECU identity information in the certificate; if it exists, set the status of the corresponding replay attack detection record to valid.

[0057] Figure 8 This is a flowchart of a method for ECU communication according to an embodiment of this application, as shown below. Figure 8 As shown, it specifically includes: Step 1: The first ECU (sender ECU) checks the existence and validity of the peer's digital certificate. If it is invalid, a digital certificate exchange is performed. Step 2: The first ECU constructs timing certificate X: the CAN message sequence number SBN-A in the ECU is incremented by 1, and then SBN-A is put into timing certificate X; Step 3: The first ECU calculates the first encryption process key SK1 and encrypts the service request CAN message; Step 4: The first ECU sends an encrypted service request message MSG REQ, where MSG REQ contains the timing credential X; Step 5: The second ECU (receiving ECU) performs replay attack detection on the timing certificate X. If a replay attack is detected, the current message is discarded. Step 6: The second ECU uses the serial number and timing certificate X of the first ECU to calculate the first encryption process key SK1 and decrypt the service request message MSG REQ; Step 7: The second ECU constructs timing certificate Y: the CAN message sequence number SBN-B in the ECU is incremented by 1, and then SBN-B is put into timing certificate Y; Step 8: The second ECU uses its serial number and timing certificate Y to calculate the second encryption process key SK2 and encrypt the service response message MSG RSP. Step 9: The second ECU uses the timing credential X and the CAN network address of the first ECU to update the replay attack detection record set SA; Step 10: The second ECU sends an encrypted service response message MSG RSP, wherein the MSG RSP contains the timing certificate Y; Step 11: The first ECU performs replay attack detection on the timing certificate Y. If a hit is detected, the current packet is discarded. Step 12: The first ECU uses the serial number of the second ECU and the timing certificate Y to calculate the second encryption process key SK2 and decrypt the service response message MSG RSP; Step 13: The first ECU uses the timing certificate Y and the CAN network address of the second ECU to update the replay attack detection record set SB.

[0058] This application also provides a replay attack detection method based on a replay attack detection list and a whitelist. The replay attack detection whitelist W is stored in the memory of the receiving ECU and consists of whitelist records, with only one valid record for each CAN message identifier. When a valid whitelist record exists, it indicates that no replay attack behavior is detected from the sender. Each whitelist record consists of a record number, a CAN message identifier, and a validity flag.

[0059] The whitelist W for replay attack detection is shown in Table 3 below: Table 3: Whitelist for Replay Attack Detection

[0060] The communication replay attack detection list S2 is stored in the receiver ECU's memory and consists of multiple replay attack detection records, with only one valid detection record for each CAN network address. Each replay attack detection record includes: record number, CAN network address, validity flag, current trusted ECU device serial number, key index number, ECU certificate validity period, timing credential type, most recently received timing credential, and most recently updated timing credential.

[0061] The list of targets for detecting communication replay attacks, S2, is shown in Table 4 below: Table 4: List of Detected Communication Replay Attacks (S2)

[0062] Figure 9 This is a flowchart of a replay attack detection method based on a replay attack detection list and a whitelist, provided in one embodiment of this application. Figure 9 As shown, the receiving ECU uses the received current CAN message identifier to search the whitelist W. If a valid record is found, the replay attack check phase is skipped and the message processing phase begins. The receiving ECU uses the sending end's CAN network address SA to search the communication replay attack detection list S2, and records the valid record as R. When no record is found, communication is terminated; when a valid record exists in R, the most recently received timing credential X' and the timing credential X sent by the sending ECU are retrieved from R and the request CAN message, respectively. If X is less than or equal to X' or X is earlier than X', communication is terminated.

[0063] Among them, the method for generating the communication encryption key TSK. 1) Communication encryption master key TMK: The TMK consists of 10 groups, each 256 bits long, and is stored in the key set.

[0064] When decrypting a received message: extract the TMK key index number used by the other party from the communication replay attack detection list S2, and then extract the corresponding TMK key value from the key set according to the key type and the TMK key index number.

[0065] When encrypting a message to be sent: extract the corresponding TMK key value from the key set according to the key type and the TMK key index number of the current ECU stored locally.

[0066] 2) Calculation method of TSK key in communication encryption process: When the second ECU decrypts and receives the message sent by the first ECU: TSK = GEN(TMK, "Device serial number of the first ECU"||"Time sequence credential type of the first ECU"||"Time sequence credential in the received message request message"||"CAN message header in the received message request message"||"Request message flag").

[0067] Where: GEN is the key generation algorithm, such as HMAC-SHA256 or HKDF; the request message flag value is "0xAA-Request Message"; "||" is the bit string concatenation operation.

[0068] When the second ECU sends an encrypted message to the first ECU: TSK = GEN (TMK, "Device serial number of the second ECU"||"Time credential type of the second ECU"||"Time credential stored locally by the second ECU"||"Header of the response CAN message sent by the second ECU"||"Response message flags").

[0069] Where: GEN is the key generation algorithm, such as HMAC-SHA256 or HKDF; the response message flag value is "0xBB-Response Message"; "||" is the bit string concatenation operation.

[0070] Since the first ECU and the second ECU use different key generation factors, this method can ensure that the communication encryption key TSK used by the first ECU and the second ECU will not be repeated, and it can also ensure that the key used by each ECU will not be repeated each time.

[0071] 3) Calculation method for ciphertext in the CAN message data field: CAN message data field ciphertext = ENC(TSK, "CAN message data field plaintext").

[0072] Wherein: ENC represents the encryption algorithm, and in this application specifically refers to a stream key encryption algorithm, such as CHACHA20 or Zu Chongzhi's algorithm. Block cipher algorithms such as AES can also be used.

[0073] Figure 10 This is a flowchart of a method for querying the serial number of a peer ECU device according to an embodiment of this application, as shown below. Figure 10 As shown, the receiving ECU reads the sending ECU address SA from the received CAN message header, uses SA to search for the currently valid record R in the replay attack detection list S, and finally retrieves the current device serial number of the peer ECU from R.

[0074] Figure 11 This is a schematic diagram of the structure of an ECU with address binding relationship management and replay attack prevention detection provided in one embodiment of this application, as shown below. Figure 11As shown, it has a communication management module, a binding relationship management module, a replay attack detection list module, a time-series credential management module, a list management module, and a security management module.

[0075] 1) Communication Management Module: Used to send and receive communication messages on the CAN bus; calls the Security Management Module to verify digital certificates, generate process keys TSK and DSK, decrypt received encrypted data, and encrypt data to be sent; calls the Replay Attack Detection Module to perform replay attack detection on received CAN messages, and calls the List Management Module to update the status of the whitelist and replay attack detection list.

[0076] 2) Binding Relationship Management Module: This module stores and updates the binding relationships between ECU identities and ECU addresses. When an ECU's digital certificate is updated, the binding relationships in this module need to be updated synchronously. The binding relationships include: CAN network identifier, CAN network address, ECU device serial number, ECU timing credential type, and TMK key index number.

[0077] 3) The replay attack detection module includes a certificate replay attack detection submodule, a certificate replay attack detection list, a communication replay attack detection submodule, and a communication replay attack detection list.

[0078] The certificate replay attack detection submodule first calls the whitelist module; then it calls the certificate replay attack detection list to filter key information in the target ECU to prevent identity impersonation against the ECU; if the filtering result is valid, the certificate replay attack detection list is finally updated. The certificate replay attack detection list is used to store, update, and manage the expiration of key information in digital certificates of other ECUs that have been received. The communication replay attack detection submodule first calls the whitelist module; then it calls the communication replay attack detection list to filter key information of the received CAN messages to prevent replay attacks against CAN messages; if the filtering result is valid, the communication replay attack detection list is finally updated. The communication replay attack detection list is used to store, update, and manage the failure of key information in the CAN messages received from each ECU.

[0079] 4) The time-series credential management module includes a time-series credential generation submodule and a time-series credential management submodule.

[0080] The timing credential is 4 bytes long, and the data is generated and padded by the timing credential generation submodule. During padding, it is right-aligned and padded with zeros on the left. The timing credential generation submodule maintains a message sequence number generator and a message timestamp generator. The message sequence number generator is a counter that starts counting from 0 and automatically increments by 1 for each message sent; the message timestamp refers to the number of seconds that have elapsed from 00:00:00 on January 1, 1970 to the current CAN message generation time. The Time-Sequence Credential Management submodule is used to record the type of the last time-sequence credential generated and the time-sequence credential itself.

[0081] 5) The list management module includes a whitelist management sub-module.

[0082] The whitelist management submodule is used to store, update, and manage the expiration of communication whitelists. Whitelist filtering only occurs when the whitelist function is enabled.

[0083] 6) The security management module includes a key management submodule, a digital certificate management submodule, and a security algorithm submodule.

[0084] The key management submodule is used for secure storage, updating, and expiration management of key sets.

[0085] The digital certificate management submodule is used for secure storage, updating, and expiration management of the digital certificates of this ECU. It verifies the digital certificates received from peer ECUs and calls the replay attack detection module to perform replay attack detection on the digital certificates.

[0086] The security algorithm submodule provides various encryption and decryption algorithms, signature verification algorithms, and key generation algorithms.

[0087] Figure 12 This is a schematic diagram of a CAN network security transmission system based on a trusted address binding relationship, provided in one embodiment of this application. Figure 12As shown, the system includes: a first ECU configured to create a first ECU digital certificate binding the first ECU to a CAN network address, and send a CAN message containing the first ECU digital certificate to a second ECU; verifying the second ECU digital certificate in the CAN message to obtain a first verification result; determining whether the first ECU and the second ECU can communicate based on the first verification result and a second verification result; when it is determined that the first ECU and the second ECU can communicate, obtaining a first process key generation factor from the first ECU digital certificate, generating a first process flow key using the first process key generation factor, encrypting the CAN message containing the transmission data using the first process flow key to obtain an encrypted CAN message, and sending the encrypted CAN message. The system provides the second ECU with a digital certificate configured to bind the second ECU to a CAN network address, and sends a CAN message containing the second ECU digital certificate to the first ECU. The system verifies the first ECU digital certificate in the CAN message to obtain a second verification result. Based on the first and second verification results, it determines whether the first ECU and the second ECU can communicate. When it is determined that the first ECU and the second ECU can communicate, after receiving the encrypted CAN message, the system obtains a first process key generation factor from the first ECU digital certificate, generates a first process flow key using the first process key generation factor, and decrypts the encrypted CAN message using the first process flow key to obtain the transmitted data in the CAN message.

[0088] The above is an illustrative scheme of a CAN network security transmission system based on trusted address binding relationships, as described in this embodiment. It should be noted that the technical solution of this CAN network security transmission system based on trusted address binding relationships belongs to the same concept as the technical solution of the aforementioned CAN network security transmission method based on trusted address binding relationships. Details not described in detail in the technical solution of the CAN network security transmission system based on trusted address binding relationships can be found in the description of the technical solution of the aforementioned CAN network security transmission method based on trusted address binding relationships.

[0089] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described CAN network security transmission method based on address binding relationship.

[0090] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the aforementioned CAN network security transmission method based on trusted address binding relationships. Details not described in detail in the technical solution of the storage medium can be found in the description of the aforementioned technical solution of the CAN network security transmission method based on trusted address binding relationships.

[0091] An embodiment of this application also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described CAN network security transmission method based on address binding relationship trust.

[0092] The above is an illustrative scheme of a computer program according to this embodiment. It should be noted that the technical solution of this computer program belongs to the same concept as the above-described CAN network security transmission method based on trusted address binding relationship. For details not described in detail in the technical solution of the computer program, please refer to the description of the above-described CAN network security transmission method based on trusted address binding relationship.

[0093] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0094] The computer instructions include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium may include: any entity or system capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0095] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this application.

[0096] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0097] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of the embodiments of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.

Claims

1. A secure CAN network transmission method based on trusted address binding relationships, characterized in that, include: The first ECU creates a digital certificate for binding the first ECU to the CAN network address and sends a CAN message containing the first ECU digital certificate to the second ECU. At the same time, the second ECU creates a digital certificate for binding the second ECU to the CAN network address and sends a CAN message containing the second ECU digital certificate to the first ECU. The first ECU verifies the digital certificate of the second ECU in the CAN message and obtains a first verification result. At the same time, the second ECU verifies the digital certificate of the first ECU in the CAN message and obtains a second verification result. Whenever a CAN message needs to be sent, the system determines whether the first ECU and the second ECU can communicate based on the first verification result and the second verification result. When it is determined that the first ECU and the second ECU can communicate, the first ECU generates a first process flow key, then uses the first process flow key to encrypt a CAN message containing transmission data, obtaining an encrypted CAN message, and sends the encrypted CAN message to the second ECU. Upon receiving the encrypted CAN message, the second ECU recovers the first process flow key and then uses the recovered first process flow key to decrypt the encrypted CAN message, thereby obtaining the transmission data in the CAN message. The second ECU generates a second process flow key, then uses the second process flow key to encrypt a CAN message containing transmission data, obtaining an encrypted CAN message, and sends the encrypted CAN message to the first ECU. Upon receiving the encrypted CAN message, the first ECU recovers the second process flow key and then uses the recovered second process flow key to decrypt the encrypted CAN message, thereby obtaining the transmission data in the CAN message. During the lifecycle of the digital certificate, the certificate exchange and verification between the first ECU and the second ECU is performed only once; the ECU digital certificate includes a digital signature, the ECU digital certificate validity period, ciphertext of ECU address and identity binding relationship information, and a DMK key index number; wherein, the DMK key index number includes the DMK key index length and the DMK key index number value; the ciphertext of ECU address and identity binding relationship information includes the ECU device serial number, the CAN network identifier and CAN network address of the CAN network where the ECU is located, the TMK key index length and the TMK key index number value, and the ECU timing credential type; The rules governing the ECU address and identity binding relationship information are as follows: The calculation method for the device authentication process key DSK: DSK = GEN(DMK,"Certificate Issuance Date"||"ECU Digital Certificate Serial Number"||BITWISE_NOT("ECU Digital Certificate Serial Number")||"ECU Digital Certificate Serial Number"||BITWISE_NOT("ECU Digital Certificate Serial Number")); where: GEN is the key generation algorithm; DMK is the device identity master key, stored in the key set; BITWISE_NOT is the bitwise NOT operation; The calculation method for the ciphertext of ECU address and identity binding relationship information is as follows: ECU address and identity binding relationship information ciphertext = ENC(DSK, "CAN network identifier"||"CAN network address"||"ECU device serial number"||"time credential type"||"TMK key index number"); where: "||" represents bit string concatenation operation; DSK is the device authentication process key; ENC is the encryption algorithm; the time credential type value includes: "0x00 - sender timestamp", "0x01 - sender CAN message sequence number"; the ECU device serial number includes the ECU device serial number length and the ECU device serial number value; the TMK key index number includes the TMK key index number length and the TMK key index number value; The timing certificate is a 4-byte CAN message field generated by the first ECU and transmitted to the second ECU to distinguish the order in which CAN messages are generated. The timing certificate is used to prevent replay attacks and also serves as part of the key generation factor in the encryption process to ensure that the keys generated by any ECU are not duplicated. When the timing certificate type value is 0x00, the sender fills in the sender's local timestamp in the timing certificate field; when the timing certificate type value is 0x01, the sender fills in the message sequence number corresponding to the CAN message in the timing certificate field. The process involves the first ECU generating a first process flow key, which is then used to encrypt a CAN message containing transmitted data. The encrypted CAN message comprises the following steps: the first ECU extracts a TMK key index number and key type from its digital certificate, and uses a pre-stored key set to extract a TMK key value corresponding to the TMK key index number and key type; the first ECU generates a first encryption key generation factor based on the time sequence credential and time sequence credential type in its digital certificate, and uses the first encryption key generation factor, the stream key generation algorithm, and the TMK key value to calculate a process key TSK for communication encryption, which is then used as the first process flow key for communication encryption; the first ECU uses the first process flow key for communication encryption to encrypt the CAN message containing transmitted data, resulting in the encrypted CAN message. In this process, after receiving the encrypted CAN message, the second ECU recovers the first process flow key and then uses the recovered first process flow key to decrypt the encrypted CAN message, thereby obtaining the transmission data in the CAN message. This includes: the second ECU extracting the TMK key index number and key type from the first ECU digital certificate, and using a pre-stored key set to extract the TMK key value corresponding to the TMK key index number and key type; the second ECU generating a first process flow key generation factor based on the time sequence certificate and time sequence certificate type in the first ECU digital certificate, and using the first process flow key generation factor, the flow key generation algorithm, and the TMK key value to calculate the process key TSK for communication decryption, and using the process key TSK as the first process flow key for communication decryption; and the second ECU using the first process flow key for communication decryption to decrypt the encrypted CAN message, thereby obtaining the transmission data in the CAN message.

2. The method according to claim 1, characterized in that, The first ECU verifies the digital certificate of the second ECU in the CAN message, and the first verification result includes: The first ECU performs a first valid verification on the digital signature and the validity period of the second ECU digital certificate in the CAN message, and obtains a first valid verification result. If the first valid verification result fails, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is impossible. If the first valid verification result is passed, the first ECU extracts the DMK key index number and key type from the second ECU digital certificate, and uses the pre-stored key set to extract the DMK key value corresponding to the DMK key index number and key type; The first ECU uses the calculation method of the device authentication process key DSK and the DMK key value to calculate the DSK key value, and uses the DSK key value to decrypt the encrypted ECU address and identity binding relationship information in the ECU digital certificate to obtain the plaintext ECU address and identity binding relationship information.

3. The method according to claim 2, characterized in that, The first ECU verifies the second ECU digital certificate in the CAN message, and the first verification result further includes: The first ECU obtains the ECU device serial number, the CAN network identifier and the CAN network address of the CAN network where the ECU is located from the plaintext ECU address and identity binding relationship information, and obtains the comparison result by comparing the CAN network address with the source address of the CAN message; If the comparison result is inconsistent, the first ECU generates a first verification result that the first ECU and the second ECU cannot communicate. If the comparison results are consistent, the first ECU uses a pre-stored certificate replay attack detection list to effectively verify the ECU device serial number and the CAN network address; If the valid verification of the ECU device serial number and / or the CAN network address fails, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is not possible. If the validity verification of the ECU device serial number and the CAN network address both pass, the first ECU verifies the service message sent by the second ECU based on the communication replay attack detection list and the replay attack detection whitelist, and obtains the first verification result.

4. The method according to claim 3, characterized in that, The first ECU verifies the CAN messages sent by the second ECU based on the communication replay attack detection list and the replay attack detection whitelist, and obtains the following first verification results: The first ECU effectively verifies the CAN network identifier and the CAN network address based on the replay attack detection whitelist, and obtains the verification result; If the verification result is valid, then the CAN messages sent from the CAN network identifier and the CAN network address will not be subject to replay attack detection. If the verification result is invalid, the first ECU uses the CAN network identifier and the CAN network address to verify the validity of the timing certificate corresponding to the CAN network identifier and the CAN network address in the pre-stored communication replay attack detection list, and obtains the validity verification result; If the validity verification result is invalid, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is not possible; If the validity verification result is valid, the first ECU generates a first verification result indicating that communication between the first ECU and the second ECU is possible.

5. A CAN network security transmission system based on address binding relationship, the system being used to implement the method as described in any one of claims 1-4, characterized in that, include: The first ECU is configured to create a digital certificate for binding the first ECU to the CAN network address, and send a CAN message containing the digital certificate of the first ECU to the second ECU; The digital certificate of the second ECU in the CAN message is verified to obtain a first verification result. Based on the first verification result and the second verification result, it is determined whether the first ECU and the second ECU can communicate. When it is determined that the first ECU and the second ECU can communicate, the first process key generation factor is obtained from the digital certificate of the first ECU, and the first process key generation factor is used to generate the first process flow key. The first process flow key is used to encrypt the CAN message containing the transmission data to obtain the encrypted CAN message, and the encrypted CAN message is sent to the second ECU. The second ECU is configured to create a second ECU digital certificate that binds the second ECU to the CAN network address, and sends a CAN message containing the second ECU digital certificate to the first ECU; The digital certificate of the first ECU in the CAN message is verified to obtain a second verification result; Based on the first verification result and the second verification result, determine whether the first ECU and the second ECU can communicate; When it is determined that the first ECU and the second ECU can communicate, after receiving the encrypted CAN message, the first process key generation factor is obtained from the digital certificate of the first ECU, and then the first process key generation factor is used to generate the first process flow key. The first process flow key is used to decrypt the encrypted CAN message to obtain the transmitted data in the CAN message.

6. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the CAN network security transmission method based on address binding relationship as described in any one of claims 1 to 4.

7. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the CAN network security transmission method based on address binding relationship as described in any one of claims 1 to 4.

Images