CN117395003B - Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system - Google Patents

Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system Download PDF

Info

Publication number
CN117395003B
CN117395003B CN202311691073.5A CN202311691073A CN117395003B CN 117395003 B CN117395003 B CN 117395003B CN 202311691073 A CN202311691073 A CN 202311691073A CN 117395003 B CN117395003 B CN 117395003B
Authority
CN
China
Prior art keywords
message
ecu
synchronous
key
ciphertext
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202311691073.5A
Other languages
Chinese (zh)
Other versions
CN117395003A (en
Inventor
李桂良
杨晶
张东
冯世杰
谭乐安
江浩良
谢艺枝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jifei Shuchi Shanghai Technology Co ltd
Zhiji Guangzhou Technology Co ltd
Original Assignee
Jifei Shuchi Shanghai Technology Co ltd
Zhiji Guangzhou Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jifei Shuchi Shanghai Technology Co ltd, Zhiji Guangzhou Technology Co ltd filed Critical Jifei Shuchi Shanghai Technology Co ltd
Priority to CN202311691073.5A priority Critical patent/CN117395003B/en
Publication of CN117395003A publication Critical patent/CN117395003A/en
Application granted granted Critical
Publication of CN117395003B publication Critical patent/CN117395003B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)

Abstract

The invention discloses a low-cost and high-reliability vehicle-mounted CAN bus safety communication method and a safety communication system, belonging to the technical field of vehicle-mounted CAN bus communication, comprising the following steps: the gateway is used for forwarding key preset instructions of the upper computer or the TSP platform and finishing initial key preset of each ECU on the CAN bus; the ECU_A is used as a CAN message transmitting end and is used for transmitting ciphertext messages after plaintext data authentication encryption to the ECU_B; the ECU_B is used as a CAN message receiving end and used for decrypting and checking the ciphertext message to obtain plaintext message data. Through the mode, the confidentiality and the integrity of message data are protected by using a lightweight AEAD (Authenticated Encryption with Associated Data) algorithm, the problem of data plaintext transmission of the vehicle-mounted CAN bus is solved, the communication safety of the vehicle-mounted CAN bus is improved, the hardware cost is not increased, and two application scenes of a CAN protocol and a CAN-FD protocol are supported.

Description

Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system
Technical Field
The invention relates to the technical field of vehicle-mounted CAN bus communication, in particular to a low-cost high-reliability vehicle-mounted CAN bus safety communication method and a safety communication system.
Background
The vehicle CAN bus is a serial communication protocol widely applied to vehicle internal communication and is applied to communication among different Electronic Control Units (ECUs) of an automobile. The application scene of the vehicle-mounted CAN bus comprises a power control system, a braking system, an air conditioning system, an entertainment system, an instrument panel, a safety system and the like. Frequent exchanges of information between these ECUs are required to ensure proper operation of the vehicle. The CAN bus has the advantages of relatively simple hardware and protocol, low cost, instantaneity, reliability, expandability and the like, but the CAN bus also has some information safety hidden trouble. Data on CAN buses is typically transmitted in the clear and is easily eavesdropped, resulting in information leakage. The lack of an effective identity authentication mechanism between ECUs may result in injection attacks by illegal ECUs, disrupting normal operation of the vehicle. Due to the lack of data verification and encryption, an attacker CAN replay previous CAN messages, causing unexpected operations.
To solve these problems, AUTOSAR introduced SecOC (Secure Onboard Communication), which is a safety mechanism for vehicle interior communication. SecOC uses encryption and authentication techniques to protect the integrity of CAN messages and to prevent tampering with the information. The SecOC can ensure authentication between the ECUs and prevent injection attacks of illegal ECUs. By adding fresh value management to the message, the SecOC can detect and resist replay attacks, ensuring that only legitimate messages are accepted and executed.
However, secOC also suffers from some drawbacks. For example, secOC only supports CAN-FD protocol but not CAN protocol, requiring more costly hardware and more complex software support, increasing cost and development difficulty; the message data is still sent in the clear, and confidentiality of the message cannot be protected.
Still other techniques, while encrypting message data and generating message authentication codes, use two different sets of algorithms and keys, adding complexity.
Based on the above, the invention designs a vehicle-mounted CAN bus safety communication method and a safety communication system with low cost and high reliability so as to solve the problems.
Disclosure of Invention
Aiming at the defects existing in the prior art, the invention provides a vehicle-mounted CAN bus safety communication method and a safety communication system with low cost and high reliability.
In order to achieve the above purpose, the invention is realized by the following technical scheme:
a low cost, high reliability vehicle CAN bus secure communications system comprising:
the gateway is used for forwarding a key preset instruction and finishing the initial key preset of each ECU on the CAN bus;
the ECU_A is used as a CAN message transmitting end and is used for transmitting ciphertext messages after plaintext data authentication encryption to the ECU_B;
Specifically, the ECU_A encrypts and synchronizes plaintext data by using a communication key, a real synchronization ID and a CAN message ID through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code, then combines the ciphertext data, the message authentication code generated by the native authentication code and the explicit synchronization ID into ciphertext messages, and sends the ciphertext messages to the ECU_B;
the ECU_B is used as a CAN message receiving end and is used for decrypting and verifying the ciphertext message to obtain plaintext message data;
specifically, the ECU_B calculates whether the explicit synchronization ID of the received ciphertext message is consistent with the implicit synchronization ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronization ID is added with 1 in 255 or 65535, and the real synchronization ID is added with 1; if the difference value is inconsistent, continuing to judge whether the difference value between the explicit synchronous ID and the implicit synchronous ID is within an allowable range; if the difference IDDiff is within the allowable range, adding the sum of (1+IDDiff) to the implicit synchronous ID in 255 or 65535, adding the sum of (1+IDDiff) to the real synchronous ID, otherwise reporting an exception; the ecu_b returns the plain data to the service process.
A safe communication method of a vehicle-mounted CAN bus safe communication system with low cost and high reliability comprises the following steps:
A. the gateway transmits key preset instructions of the upper computer or the TSP platform to finish the initial key preset of each ECU on the CAN bus including the gateway;
B. The ECU_A sends the ciphertext message after the plaintext data authentication encryption to the ECU_B;
specifically, the ECU_A encrypts and synchronizes plaintext data by using a communication key, a real synchronization ID and a CAN message ID through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code, then combines the ciphertext data, the message authentication code generated by the native authentication code and the explicit synchronization ID into ciphertext messages, and sends the ciphertext messages to the ECU_B;
C. the ECU_B decrypts the ciphertext message and verifies the ciphertext message to obtain plaintext message data;
specifically, the ECU_B calculates whether the explicit synchronization ID of the received ciphertext message is consistent with the implicit synchronization ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronization ID is added with 1 in 255 or 65535, and the real synchronization ID is added with 1; if the difference value is inconsistent, continuing to judge whether the difference value between the explicit synchronous ID and the implicit synchronous ID is within an allowable range; if the difference IDDiff is within the allowable range, adding the sum of (1+IDDiff) to the implicit synchronous ID in 255 or 65535, adding the sum of (1+IDDiff) to the real synchronous ID, otherwise reporting an exception; the ecu_b returns the plain data to the service process.
Further, the generation flow of the communication key is as follows:
step 1-1, judging whether the following conditions are met: the ECU_A discovers that the communication key of the current CAN message ID is empty, or the ECU_B distributes the communication key of any new CAN message ID; step 1-2 is carried out when the conditions are met;
Step 1-2, the ECU_A acquires a string of random numbers from a hardware random number generator or a pseudo-random number generator;
step 1-3, hash operation is carried out on the random number, and the highest 3 bytes and the lowest 3 bytes of the hash value are sequentially combined into a data sequence of 6 bytes to be used as a communication key of the CAN message ID.
Further, the distribution flow of the communication key is as follows:
step 2-1, after the ECU_A recovers from the abnormality such as start-up, fault, etc., the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID of the CAN message ID are recovered to the initial value zero;
step 2-2, the ECU_A encrypts and synchronizes the communication key by using the communication key of the CAN message ID, the real synchronization ID and the CAN message ID through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code; the ciphertext data is also 6 bytes in length;
step 2-3, judging whether the CAN protocol scene exists or not;
if the explicit synchronization ID occupies 1 byte in the CAN protocol scene, the value is 255, which indicates that the message is a distribution message of the communication key; the highest 4 bits and the lowest 4 bits of the original authentication code are sequentially spliced to form the message authentication code;
if the explicit synchronization ID occupies 2 bytes and takes 65535 in other scenes including CAN-FD protocol instead of CAN protocol, the message is also indicated to be the distribution message of the communication key; the highest 1 byte and the lowest 1 byte of the original authentication code are spliced in sequence to form a message authentication code;
Step 2-4, the ECU_A sequentially splices and combines the ciphertext data, the message authentication code and the explicit synchronous ID into a communication key distribution message, and sends the communication key distribution message to the CAN bus;
the ECU_B is used as a CAN message receiving end and is used for decrypting and verifying the ciphertext message to obtain plaintext message data;
in step 2-5, the ecu_b determines whether the explicit synchronization ID of the received CAN message is 255 or 65535, and if so, enters a communication key distribution message processing flow.
Further, the communication key distribution message processing flow is as follows:
step S1, an ECU_B decrypts and verifies the signature of the received ciphertext message by using the communication key of the CAN message ID, the real synchronous ID and the CAN message ID;
step S2, judging whether the signature verification is successful or not;
if the signature verification is successful, the message is really a communication key distribution message;
if the signature verification fails, the tampered or simulated communication key distribution message is considered to be received, the tampered or simulated communication key distribution message belongs to an attacked state, and the communication key distribution message processing flow is exited after the exception is reported;
step S3, after the signature verification is successful, continuously judging whether the received communication key is consistent with the communication key which is used once, if so, indicating that replay attack exists, and exiting the communication key distribution message processing flow after reporting abnormality; if the communication keys are inconsistent, the received communication keys are true;
Step S4, the ECU_B restores the real synchronous ID and the implicit synchronous ID of the CAN message ID to the initial value of zero, modifies the communication key of the CAN message ID into the communication key obtained by decrypting the ciphertext message, and records the new communication key into a communication key list which is used once;
step S5, the communication key distribution message processing flow is normally ended.
Further, the ECU_A encryption flow and the ECU_B decryption flow together form a service data encryption, decryption and transmission flow;
the ECU_A encryption flow is as follows:
step 3-1, the ECU_A retrieves the corresponding communication key according to the CAN message ID;
step 3-2, the ECU_A uses the communication key of the CAN message ID, the real synchronous ID and the CAN message ID to encrypt and synchronize plaintext data through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code; ciphertext data and plaintext data are equal in length;
step 3-3, the real synchronous ID of the CAN message ID is added with 1, and the implicit synchronous ID is added with 1;
step 3-4, judging whether the CAN protocol scene exists or not;
if the implicit synchronous ID and the explicit synchronous ID are unsigned integers of one byte in the CAN protocol scene, the range is 0 to 254 cycles; if the implicit synchronization ID is 255, setting the value of the implicit synchronization ID to be 0, otherwise, keeping the value unchanged; under the CAN protocol scene, the message authentication code occupies one byte length, and the highest 4 bits and the lowest 4 bits of the original authentication code are sequentially spliced;
If the implicit synchronous ID and the explicit synchronous ID are unsigned integers of two bytes in the CAN-FD protocol scene instead of the CAN protocol scene, the range is 0 to 65534 cycles; if the implicit synchronization ID is 65535, setting the value of the implicit synchronization ID to 0, otherwise, the value is unchanged; under the CAN protocol scene, the message authentication code occupies two bytes in length, and the highest 1 byte and the lowest 1 byte of the original authentication code are sequentially spliced to form the message authentication code;
and 3-5, the ECU_A sequentially splices the ciphertext data, the message authentication code and the explicit synchronous ID to form a combined message, and sends the combined message to the CAN bus after the value of the implicit synchronous ID is assigned to the explicit synchronous ID.
Further, in the CAN protocol scene, the plaintext data length is not more than 6 bytes, and the ciphertext length generated by the lightweight AEAD algorithm is equal to the plaintext length; in the CAN-FD protocol scene, the length of plaintext data is not more than 60 bytes, and the length of ciphertext generated by a lightweight AEAD algorithm is equal to the length of plaintext.
Further, the ecu_b decryption flow is:
step 3-6, the ECU_B calculates whether the explicit synchronous ID of the received ciphertext message is consistent with the implicit synchronous ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronous ID is added with 1 in 255 or 65535, and the real synchronous ID is added with 1; if the difference IDDiff is inconsistent, indicating that the CAN message loss phenomenon occurs, and continuously judging whether the difference IDDiff of the explicit synchronous ID and the implicit synchronous ID is within an allowable range; the calculation steps of IDDiff are as follows:
Judging whether the CAN protocol scene exists or not;
if in CAN protocol scenario iddiff= (explicit synchronization id+255-self maintained implicit synchronization ID)% 255;
iddiff= (explicit synchronization id+65535-self-maintained implicit synchronization ID)% 65535, if not in CAN protocol scenario but in CAN-FD protocol scenario;
step 3-7, judging whether the value of IDDiff is in an allowable range;
if IDDiff is not in the allowable range, reporting an exception and then exiting the processing;
if IDDiff is within the allowable range, the true synchronization ID is added with the value of IDDiff;
step 3-8, decrypting and checking the ciphertext message by using the communication key of the CAN message ID, the real synchronous ID and the CAN message ID;
step 3-9, judging whether the signature verification is successful;
if the signature verification fails, reporting an abnormality and then exiting the processing;
if the signature verification is successful, the true synchronous ID is added with 1 again;
step 3-10, judging whether the CAN protocol scene exists or not;
if in the CAN protocol scene, the implicit synchronous ID is set to 255, and the sum of (1+IDDiff) is added in the mode;
if not in the CAN protocol scenario, the implicit synchronization ID is set to 65535 in-mold plus (1+IDDiff);
and 3-11, the ECU_B returns the plaintext data to the service processing, and normally ends the service data encryption and decryption transmission flow.
Further, the initial key presetting flow is as follows:
step 4-1, the upper computer initiates a communication key presetting process in a safe production environment;
step 4-2, the upper computer encrypts the initial key of the communication matrix by using the root key of the ECU through a lightweight AEAD algorithm to generate ciphertext data and MAC, and sends the ciphertext data and the MAC to the target ECU through a communication key preset message;
step 4-3, judging whether the ECU has a root key;
if the ECU has the root key, the ECU uses the own root key to decrypt and verify the ciphertext message through a lightweight AEAD algorithm; if the signature verification is successful, using an initial key of a communication matrix in the message as an initial key of the communication matrix of the ECU, and sending a success message, otherwise, directly exiting the key presetting flow;
if the ECU does not have the root key, the ECU applies the root key to the upper computer; the upper computer encrypts the root key by using a hard-coded temporary key in the ECU through a lightweight AEAD algorithm to generate ciphertext data and MAC, and sends the ciphertext data and the MAC to the target ECU through a root key preset message; the ECU uses the self temporary key to decrypt and check the ciphertext message through a lightweight AEAD algorithm; if the signature verification is successful, the ECU uses the root key in the message as the root key of the ECU, then returns a root key preset success message, otherwise, directly exits the key preset flow; and after receiving the root key presetting success message, the upper computer initiates a communication key presetting flow to the target ECU again.
Advantageous effects
The invention synchronously generates the ciphertext data and the message authentication code by using a lightweight AEAD encryption algorithm, thereby effectively protecting the confidentiality and the integrity of the message data, having low requirements on hardware performance, and being simpler and safer;
the invention uses the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID, and simultaneously records the communication key used once, thereby effectively detecting and preventing replay attack;
the invention supports two application scenes of the CAN protocol and the CAN-FD protocol at the same time, does not modify the bottom CAN communication protocol, and does not need to increase hardware cost;
the invention adopts the special synchronous ID value to complete the distribution of the communication key, does not need additional negotiation information and flow, and has high reliability in response to abnormal states including restarting, faults and the like.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below. It is evident that the drawings in the following description are only some embodiments of the present invention and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.
FIG. 1 is a block diagram of a low cost high reliability vehicle CAN bus secure communication system of the invention;
FIG. 2 is a flow chart of the communication key generation and distribution of the present invention;
FIG. 3 is a flow chart of the transmission of the encryption and decryption of the service data according to the present invention;
fig. 4 is a flow chart of initial key presettings of the communication matrix of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The invention is further described below with reference to examples.
Example 1
Referring to fig. 1 of the specification, a low-cost and high-reliability vehicle-mounted CAN bus secure communication system includes:
and the gateway is used for forwarding key preset instructions of the upper computer or the TSP platform and finishing initial key preset of each ECU (electronic control unit) on the CAN bus comprising the gateway.
The ECU_A is used as a CAN message transmitting end and is used for transmitting ciphertext messages after plaintext data authentication encryption to the ECU_B;
the ECU_B is used as a CAN message receiving end and is used for decrypting and verifying the ciphertext message to obtain plaintext message data;
specifically, the ecu_a generates ciphertext data (CryptoData) and a native authentication code (GenMAC) by encrypting and synchronizing plaintext data by a lightweight AEAD algorithm using a communication key (CommKey), a real synchronization ID (RealSynID), and a CAN message ID, then combines the ciphertext data, a message authentication code (MsgMAC) generated by the native authentication code, and an explicit synchronization ID (ExplicitSynID) into a ciphertext message, and transmits the ciphertext message to the ecu_b;
the generation flow of the communication key (CommKey) is as follows: each CAN message ID has an independent communication key. The communication key is regenerated and notified to the ECU_B after the ECU recovers from the abnormality such as startup, failure and the like; the ecu_a acquires a series of random numbers from a hardware random number generator (TRNG) or a Pseudo Random Number Generator (PRNG), hashes the random numbers, and takes the hash value as a communication key for the CAN message ID.
The distribution flow of the communication key (CommKey) is as follows: after the ECU_A recovers from the abnormality such as starting, failure and the like, the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID of the CAN message ID are recovered to be zero; the ECU_A encrypts and synchronizes the communication key through a lightweight AEAD algorithm (gain-128-AEAD) by using the communication key of the CAN message ID, the real synchronization ID and the CAN message ID to generate ciphertext data (CryptoData) and a native authentication code (GenMAC); then combining the ciphertext data, a message authentication code (MsgMAC) generated by the native authentication code and the explicit synchronous ID into a ciphertext message, and sending the ciphertext message to a CAN message receiving end ECU_B;
An explicit synchronization ID value of 255 or 65535 indicates that this message is a distributed message for the communication key; when the ECU_B judges that the explicit synchronous ID of the received CAN message is 255 or 65535, decrypting and checking the signature by using the initial key of the CAN message ID; after the signature verification is passed, judging whether the communication key in the message is consistent with the communication key used (including the current) or not, if so, indicating that the CAN bus has replay attack behavior, and reporting abnormality; if the real synchronous ID and the implicit synchronous ID of the CAN message ID are inconsistent, restoring the real synchronous ID and the implicit synchronous ID of the CAN message ID to the initial value of zero, and modifying the communication key of the CAN message ID received by the ECU_B into plaintext data obtained by decryption; all used communication keys are stored and recorded;
further, if the ecu_b receives the communication key distribution message, it means that the ecu_a of the message has just recovered from an abnormal state such as start-up, failure, etc., and the ecu_a of the message will not be able to decrypt the ciphertext sent from the other ECU. At this time, ecu_b needs to update and distribute the communication keys of all message IDs addressed to ecu_a. If an ECU which only receives no message is recovered from an abnormal state such as start-up, failure, etc., the ECU needs to newly add a message ID to inform other ECUs of synchronously updating the relevant communication keys in a manner of distributing the communication keys.
Further, each CAN message ID has independent real synchronous ID, implicit synchronous ID and explicit synchronous ID, and the initial values of the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID are all 0; the real synchronous ID is an unsigned integer of four bytes, the value range is 0 to 4294967295 cycle, and 1 is added to the value of each message received or sent; under the CAN protocol scene, the implicit synchronous ID and the explicit synchronous ID are unsigned integers of one byte, the range is 0 to 254 cycles, and each time a message is received or sent, the value is added with 1 again; under the CAN-FD protocol scene, the implicit synchronous ID and the explicit synchronous ID are unsigned integers of two bytes, the range is 0 to 65534 cycles, and each time a message is received or sent, the value is added with 1 again;
the ECU_B calculates whether the explicit synchronous ID of the received ciphertext message is consistent with the implicit synchronous ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronous ID is added with 1 in a module of 255 (CAN protocol) or 65535 (CAN-FD), and the real synchronous ID is added with 1; if the difference value is inconsistent, indicating that the CAN message is lost, and continuously judging whether the difference value between the explicit synchronous ID and the implicit synchronous ID is within an allowable range; if the difference IDDiff is in the allowable range, adding the sum of (1+IDDiff) to the implicit synchronous ID in 255 (CAN protocol) or 65535 (CAN-FD), adding the sum of (1+IDDiff) to the real synchronous ID, otherwise reporting an exception; the calculation method of the difference value comprises the following steps:
Iddiff= (explicit synchronization id+255 (CAN protocol) or 65535 (CAN-FD) -self-maintained implicit synchronization ID)% 255 (CAN protocol) or 65535 (CAN-FD); (% is the remainder operator);
further, the initial key of each ECU initiates presetting through a gateway by an upper computer or a TSP platform in a safe production environment; each message ID uses a different initial key according to the communication matrix. In the case of insufficient memory, all message IDs may also share the same initial key. In addition to presetting the initial key for each message ID in the communication matrix, a root key is also preset. After the root key is successful, the original key can be modified through key authentication. In addition, the ECU has a temporary key built in. This temporary key is used only in the first key presetting process.
Example two
Based on embodiment 1, please refer to fig. 2-4 of the specification, a low-cost and high-reliability vehicle-mounted CAN bus secure communication method includes:
A. the gateway transmits a key preset instruction of an upper computer or a TSP platform to finish the initial key preset of each ECU (electronic control unit) on a CAN bus comprising the gateway;
each CAN message ID has an independent initial key. In the case of insufficient memory, all CAN message IDs may also share the same initial key. After the initial key is successful, the initial key can be modified through key authentication.
B. The ECU_A sends the ciphertext message after the plaintext data authentication encryption to the ECU_B;
specifically, the ecu_a generates ciphertext data (CryptoData) and a native authentication code (GenMAC) by encrypting and synchronizing plaintext data by a lightweight AEAD algorithm using a communication key (CommKey), a real synchronization ID (RealSynID), and a CAN message ID, then combines the ciphertext data, a message authentication code (MsgMAC) generated by the native authentication code, and an explicit synchronization ID (ExplicitSynID) into a ciphertext message, and transmits the ciphertext message to the ecu_b;
C. the ECU_B decrypts the ciphertext message and verifies the ciphertext message to obtain plaintext message data;
as shown in fig. 2, which shows a communication key (CommKey) generation and distribution flow, if ecu_a finds that the communication key of the current CAN message ID is null, or ecu_b distributes the communication key of any new CAN message ID, ecu_a generates and distributes a new communication key to ecu_b for this CAN message ID. Meanwhile, it should be noted that, in practical application, the number of receiving ends of the CAN message may be one or more.
Specifically, the generation flow of the communication key (CommKey) is as follows:
step 1-1, judging whether the following conditions are met: the ECU_A discovers that the communication key of the current CAN message ID is empty, or the ECU_B distributes the communication key of any new CAN message ID; step 1-2 is carried out when the conditions are met;
In step 1-2, the ecu_a obtains a string of random numbers from a hardware random number generator (TRNG) or a Pseudo Random Number Generator (PRNG).
Step 1-3, hash operation is carried out on the random number, and the highest 3 bytes and the lowest 3 bytes of the hash value are sequentially combined into a data sequence of 6 bytes to be used as a communication key of the CAN message ID.
As shown in fig. 2, a specific flow of distributing a communication key (CommKey) is:
and 2-1, after the ECU_A recovers from the abnormality such as starting, failure and the like, recovering the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID of the CAN message ID to be zero.
Step 2-2, the ECU_A encrypts and synchronizes the communication key by using the communication key of the CAN message ID, the real synchronization ID and the CAN message ID through a lightweight AEAD algorithm (gain-128-AEAD) to generate ciphertext data (CryptoData) and a native authentication code (GenMAC); the ciphertext data is also 6 bytes in length;
step 2-3, judging whether the CAN protocol scene exists or not;
if the explicit synchronization ID (Explicit Syn ID) occupies 1 byte under the CAN protocol scene, the value is 255, which indicates that the message is a distributing message of the communication key; then the highest 4 bits and the lowest 4 bits of the original authentication code (GenMAC) are sequentially spliced to form a message authentication code (MsgMAC);
If the explicit sync ID (Explicit Syn ID) occupies 2 bytes and takes 65535 in other scenes including the CAN-FD protocol instead of the CAN protocol scene, the message is also indicated to be a distributing message of the communication key; then the highest 1 byte and the lowest 1 byte of the original authentication code (GenMAC) are spliced in sequence to form a message authentication code (MsgMAC);
step 2-4, the ECU_A sequentially splices and combines ciphertext data (CryptoData), a message authentication code (MsgMAC) and an explicit synchronization ID (Explicit Syn ID) into a communication key distribution message, and sends the communication key distribution message to the CAN bus;
the ECU_B is used as a CAN message receiving end and used for decrypting and checking the ciphertext message to obtain plaintext message data.
Step 2-5, the ECU_B judges whether the explicit synchronous ID of the received CAN message is 255 or 65535, if not, the ECU_B processes the received CAN message according to the common service message; if yes, entering a communication key distribution message processing flow, wherein the specific steps are as follows:
step S1, an ECU_B decrypts and verifies the signature of the received ciphertext message by using a communication key of the CAN message ID, a real synchronous ID (0 value, a real synchronous ID variable value maintained by the ECU_B is unchanged) and the CAN message ID;
Step S2, judging whether the signature verification is successful or not;
if the signature verification is successful, the message is really a communication key distribution message;
if the signature verification fails, the tampered or simulated communication key distribution message is considered to be received, the tampered or simulated communication key distribution message belongs to an attacked state, and the communication key distribution message processing flow is exited after the exception is reported;
step S3, after the signature verification is successful, continuously judging whether the received communication key is consistent with the communication key which is used (including the current) or not, if so, indicating that replay attack exists, and exiting the communication key distribution message processing flow after reporting abnormality; if the communication keys are inconsistent, the received communication keys are true;
step S4, the ECU_B restores the real synchronous ID and the implicit synchronous ID of the CAN message ID to the initial value of zero, modifies the communication key of the CAN message ID into the communication key obtained by decrypting the ciphertext message, and records the new communication key into a communication key list which is used once;
step S5, normally ending the communication key distribution message processing flow;
further, if the ecu_b receives the communication key distribution message, it means that the ecu_a of the message has just recovered from an abnormal state such as start-up, failure, etc., and the ecu_a of the message will not be able to decrypt the ciphertext sent from the other ECU. At this time, ecu_b needs to update and distribute the communication keys of all message IDs addressed to ecu_a. If an ECU which only receives no message is recovered from an abnormal state such as start-up, failure, etc., the ECU needs to newly add a message ID to inform other ECUs of synchronously updating the relevant communication keys in a manner of distributing the communication keys.
As shown in fig. 3, the ecu_a encryption flow and the ecu_b decryption flow together form a service data encryption/decryption transmission flow; the business data encryption and decryption transmission flow is as follows:
ecu_a encryption flow:
step 3-1, the ECU_A retrieves the corresponding communication key according to the CAN message ID;
step 3-2, the ECU_A uses the communication key of the CAN message ID, the real synchronous ID and the CAN message ID to encrypt and synchronously generate ciphertext data (CryptoData) and a native authentication code (GenMAC) through a lightweight AEAD algorithm; ciphertext data and plaintext data are equal in length;
step 3-3, the real synchronous ID of the CAN message ID is added with 1, and the implicit synchronous ID is added with 1;
step 3-4, judging whether the CAN protocol scene exists or not;
if the implicit synchronous ID and the explicit synchronous ID are unsigned integers of one byte in the CAN protocol scene, the range is 0 to 254 cycles; if the implicit synchronization ID is 255, setting the value of the implicit synchronization ID to be 0, otherwise, keeping the value unchanged; under the CAN protocol scene, the message authentication code (MsgMAC) occupies one byte length, and the highest 4 bits and the lowest 4 bits of the original authentication code (GenMAC) are sequentially spliced;
if the implicit synchronous ID and the explicit synchronous ID are unsigned integers of two bytes in the CAN-FD protocol scene instead of the CAN protocol scene, the range is 0 to 65534 cycles; if the implicit synchronization ID is 65535, setting the value of the implicit synchronization ID to 0, otherwise, the value is unchanged; under the CAN protocol scene, the message authentication code (MsgMAC) occupies two bytes in length, and the highest 1 byte and the lowest 1 byte of the original authentication code (GenMAC) are sequentially spliced to form the message authentication code (MsgMAC);
Preferably, in the CAN protocol scenario, the plaintext data length is no more than 6 bytes, and the ciphertext generated by the lightweight AEAD algorithm is equal to the plaintext length. In a CAN-FD protocol scene, the length of plaintext data is not more than 60 bytes, and the length of ciphertext generated by a lightweight AEAD algorithm is equal to the length of plaintext;
step 3-5, the ECU_A sequentially splices the ciphertext data (CryptoData), the message authentication code (MsgMAC) and the explicit synchronization ID (Explicit Syn ID) to combine the messages, and sends the combined messages to the CAN bus after the value of the implicit synchronization ID (ImplicitSynID) is given to the explicit synchronization ID (ExplicitSynID);
ecu_b decryption flow:
step 3-6, the ECU_B calculates whether the explicit synchronous ID of the received ciphertext message is consistent with the implicit synchronous ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronous ID is added with 1 in a module of 255 (CAN protocol) or 65535 (CAN-FD), and the real synchronous ID is added with 1; if the difference IDDiff is inconsistent, indicating that the CAN message loss phenomenon occurs, and continuously judging whether the difference IDDiff of the explicit synchronous ID and the implicit synchronous ID is within an allowable range; the calculation steps of IDDiff are as follows:
judging whether the CAN protocol scene exists or not;
If in CAN protocol scenario iddiff= (explicit synchronization id+255-self maintained implicit synchronization ID)% 255;
iddiff= (explicit synchronization id+65535-self-maintained implicit synchronization ID)% 65535, if not in CAN protocol scenario but in CAN-FD protocol scenario;
step 3-7, judging whether the value of IDDiff is in an allowable range;
if IDDiff is not in the allowable range, reporting an exception and then exiting the processing;
if IDDiff is within the allowable range, the true synchronization ID is added with the value of IDDiff;
step 3-8, decrypting and checking the ciphertext message by using the communication key of the CAN message ID, the real synchronous ID and the CAN message ID;
step 3-9, judging whether the signature verification is successful;
if the signature verification fails, reporting an abnormality and then exiting the processing;
if the signature verification is successful, the true synchronous ID is added with 1 again;
step 3-10, judging whether the CAN protocol scene exists or not;
if in the CAN protocol scene, the implicit synchronous ID is set to 255 (CAN protocol) in-mold plus (1+IDDiff);
if not in the CAN protocol scenario, the implicit synchronization ID is set to 65535 (CAN-FD) in-mold plus (1+IDDiff);
and 3-11, the ECU_B returns the plaintext data to the service processing, and normally ends the service data encryption and decryption transmission flow.
As shown in fig. 4, the initial key preset flow is:
step 4-1, the upper computer initiates a communication key presetting process in a safe production environment;
step 4-2, the upper computer encrypts the initial key of the communication matrix by using the root key of the ECU through a lightweight AEAD algorithm to generate ciphertext data and MAC, and sends the ciphertext data and the MAC to the target ECU through a communication key preset message;
step 4-3, judging whether the ECU has a root key;
if the ECU has the root key, the ECU uses the own root key to decrypt and verify the ciphertext message through a lightweight AEAD algorithm; if the signature verification is successful, using an initial key of a communication matrix in the message as an initial key of the communication matrix of the ECU, and sending a success message, otherwise, directly exiting the key presetting flow;
if the ECU does not have the root key, the ECU applies the root key to the upper computer; the upper computer encrypts the root key by using a hard-coded temporary key in the ECU through a lightweight AEAD algorithm to generate ciphertext data and MAC, and sends the ciphertext data and the MAC to the target ECU through a root key preset message; the ECU uses the self temporary key to decrypt and check the ciphertext message through a lightweight AEAD algorithm; if the signature verification is successful, the ECU uses the root key in the message as the root key of the ECU, then returns a root key preset success message, otherwise, directly exits the key preset flow; and after receiving the root key presetting success message, the upper computer initiates a communication key presetting flow to the target ECU again.
The invention synchronously generates the ciphertext data and the message authentication code by using a lightweight AEAD encryption algorithm, thereby effectively protecting the confidentiality and the integrity of the message data, having low requirements on hardware performance, and being simpler and safer;
the invention uses the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID, and simultaneously records the communication key used once, thereby effectively detecting and preventing replay attack;
the invention supports two application scenes of the CAN protocol and the CAN-FD protocol at the same time, does not modify the bottom CAN communication protocol, and does not need to increase hardware cost;
the invention adopts the special synchronous ID value to complete the distribution of the communication key, does not need additional negotiation information and flow, and has high reliability in response to abnormal states including restarting, faults and the like.
The above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (9)

1. A low cost, high reliability vehicle CAN bus secure communications system comprising:
the gateway is used for forwarding a key preset instruction and finishing the initial key preset of each ECU on the CAN bus;
the ECU_A is used as a CAN message transmitting end and is used for transmitting ciphertext messages after plaintext data authentication encryption to the ECU_B;
specifically, the ECU_A encrypts and synchronizes plaintext data by using a communication key, a real synchronization ID and a CAN message ID through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code, then combines the ciphertext data, the message authentication code generated by the native authentication code and the explicit synchronization ID into ciphertext messages, and sends the ciphertext messages to the ECU_B;
the ECU_B is used as a CAN message receiving end and is used for decrypting and verifying the ciphertext message to obtain plaintext message data;
specifically, the ECU_B calculates whether the explicit synchronization ID of the received ciphertext message is consistent with the implicit synchronization ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronization ID is added with 1 in 255 or 65535, and the real synchronization ID is added with 1; if the difference value is inconsistent, continuing to judge whether the difference value between the explicit synchronous ID and the implicit synchronous ID is within an allowable range; if the difference IDDiff is within the allowable range, adding the sum of (1+IDDiff) to the implicit synchronous ID in 255 or 65535, adding the sum of (1+IDDiff) to the real synchronous ID, otherwise reporting an exception; the ecu_b returns the plain data to the service process.
2. A secure communication method of a low cost, high reliability vehicle CAN bus secure communication system according to claim 1, comprising:
A. the gateway transmits key preset instructions of the upper computer or the TSP platform to finish the initial key preset of each ECU on the CAN bus including the gateway;
B. the ECU_A sends the ciphertext message after the plaintext data authentication encryption to the ECU_B;
specifically, the ECU_A encrypts and synchronizes plaintext data by using a communication key, a real synchronization ID and a CAN message ID through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code, then combines the ciphertext data, the message authentication code generated by the native authentication code and the explicit synchronization ID into ciphertext messages, and sends the ciphertext messages to the ECU_B;
C. the ECU_B decrypts the ciphertext message and verifies the ciphertext message to obtain plaintext message data;
specifically, the ECU_B calculates whether the explicit synchronization ID of the received ciphertext message is consistent with the implicit synchronization ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronization ID is added with 1 in 255 or 65535, and the real synchronization ID is added with 1; if the difference value is inconsistent, continuing to judge whether the difference value between the explicit synchronous ID and the implicit synchronous ID is within an allowable range; if the difference IDDiff is within the allowable range, adding the sum of (1+IDDiff) to the implicit synchronous ID in 255 or 65535, adding the sum of (1+IDDiff) to the real synchronous ID, otherwise reporting an exception; the ecu_b returns the plain data to the service process.
3. The low-cost and high-reliability vehicle-mounted CAN bus safety communication method according to claim 2, wherein the generation flow of the communication key is as follows:
step 1-1, judging whether the following conditions are met: the ECU_A discovers that the communication key of the current CAN message ID is empty, or the ECU_B distributes the communication key of any new CAN message ID; step 1-2 is carried out when the conditions are met;
step 1-2, the ECU_A acquires a string of random numbers from a hardware random number generator or a pseudo-random number generator;
step 1-3, hash operation is carried out on the random number, and the highest 3 bytes and the lowest 3 bytes of the hash value are sequentially combined into a data sequence of 6 bytes to be used as a communication key of the CAN message ID.
4. The low-cost and high-reliability vehicle-mounted CAN bus safety communication method according to claim 3, wherein the distribution flow of the communication key is:
step 2-1, after the ECU_A recovers from the abnormality, recovering the real synchronous ID, the implicit synchronous ID and the explicit synchronous ID of the CAN message ID to be zero;
step 2-2, the ECU_A encrypts and synchronizes the communication key by using the communication key of the CAN message ID, the real synchronization ID and the CAN message ID through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code; the ciphertext data is also 6 bytes in length;
Step 2-3, judging whether the CAN protocol scene exists or not;
if the explicit synchronization ID occupies 1 byte in the CAN protocol scene, the value is 255, which indicates that the message is a distribution message of the communication key; the highest 4 bits and the lowest 4 bits of the original authentication code are sequentially spliced to form the message authentication code;
if the explicit synchronization ID occupies 2 bytes and takes 65535 in other scenes including CAN-FD protocol instead of CAN protocol, the message is also indicated to be the distribution message of the communication key; the highest 1 byte and the lowest 1 byte of the original authentication code are spliced in sequence to form a message authentication code;
step 2-4, the ECU_A sequentially splices and combines the ciphertext data, the message authentication code and the explicit synchronous ID into a communication key distribution message, and sends the communication key distribution message to the CAN bus;
the ECU_B is used as a CAN message receiving end and is used for decrypting and verifying the ciphertext message to obtain plaintext message data;
in step 2-5, the ecu_b determines whether the explicit synchronization ID of the received CAN message is 255 or 65535, and if so, enters a communication key distribution message processing flow.
5. The low-cost and high-reliability vehicle-mounted CAN bus secure communication method of claim 4, wherein the communication key distribution message processing flow is:
Step S1, an ECU_B decrypts and verifies the signature of the received ciphertext message by using a communication key of the CAN message ID, a real synchronous ID and the CAN message ID;
step S2, judging whether the signature verification is successful or not;
if the signature verification is successful, the message is really a communication key distribution message;
if the signature verification fails, the tampered or simulated communication key distribution message is considered to be received, the tampered or simulated communication key distribution message belongs to an attacked state, and the communication key distribution message processing flow is exited after the exception is reported;
step S3, after the signature verification is successful, continuously judging whether the received communication key is consistent with the communication key which is used once, if so, indicating that replay attack exists, and exiting the communication key distribution message processing flow after reporting abnormality; if the communication keys are inconsistent, the received communication keys are true;
step S4, the ECU_B restores the real synchronous ID and the implicit synchronous ID of the CAN message ID to the initial value of zero, modifies the communication key of the CAN message ID into the communication key obtained by decrypting the ciphertext message, and records the new communication key into a communication key list which is used once;
step S5, the communication key distribution message processing flow is normally ended.
6. The low-cost and high-reliability vehicle-mounted CAN bus safety communication method according to claim 5, wherein the ECU_A encryption process and the ECU_B decryption process together form a service data encryption and decryption transmission process;
The ECU_A encryption flow is as follows:
step 3-1, the ECU_A retrieves the corresponding communication key according to the CAN message ID;
step 3-2, the ECU_A uses the communication key of the CAN message ID, the real synchronous ID and the CAN message ID to encrypt and synchronize plaintext data through a lightweight AEAD algorithm to generate ciphertext data and a native authentication code; ciphertext data and plaintext data are equal in length;
step 3-3, the real synchronous ID of the CAN message ID is added with 1, and the implicit synchronous ID is added with 1;
step 3-4, judging whether the CAN protocol scene exists or not;
if the implicit synchronous ID and the explicit synchronous ID are unsigned integers of one byte in the CAN protocol scene, the range is 0 to 254 cycles; if the implicit synchronization ID is 255, setting the value of the implicit synchronization ID to be 0, otherwise, keeping the value unchanged; under the CAN protocol scene, the message authentication code occupies one byte length, and the highest 4 bits and the lowest 4 bits of the original authentication code are sequentially spliced;
if the implicit synchronous ID and the explicit synchronous ID are unsigned integers of two bytes in the CAN-FD protocol scene instead of the CAN protocol scene, the range is 0 to 65534 cycles; if the implicit synchronization ID is 65535, setting the value of the implicit synchronization ID to 0, otherwise, the value is unchanged; under the CAN protocol scene, the message authentication code occupies two bytes in length, and the highest 1 byte and the lowest 1 byte of the original authentication code are sequentially spliced to form the message authentication code;
And 3-5, the ECU_A sequentially splices the ciphertext data, the message authentication code and the explicit synchronous ID to form a combined message, and sends the combined message to the CAN bus after the value of the implicit synchronous ID is assigned to the explicit synchronous ID.
7. The low-cost high-reliability vehicle-mounted CAN bus secure communication method according to claim 6, wherein in CAN protocol scene, the plaintext data length is not more than 6 bytes, and the ciphertext length generated by lightweight AEAD algorithm is equal to plaintext length; in the CAN-FD protocol scene, the length of plaintext data is not more than 60 bytes, and the length of ciphertext generated by a lightweight AEAD algorithm is equal to the length of plaintext.
8. The low-cost and high-reliability vehicle-mounted CAN bus secure communication method of claim 7, wherein the ecu_b decryption flow is:
step 3-6, the ECU_B calculates whether the explicit synchronous ID of the received ciphertext message is consistent with the implicit synchronous ID maintained by the ECU_B, if so, after decryption and signature verification pass, the implicit synchronous ID is added with 1 in 255 or 65535, and the real synchronous ID is added with 1; if the difference IDDiff is inconsistent, indicating that the CAN message loss phenomenon occurs, and continuously judging whether the difference IDDiff of the explicit synchronous ID and the implicit synchronous ID is within an allowable range; the calculation steps of IDDiff are as follows:
Judging whether the CAN protocol scene exists or not;
if in CAN protocol scenario iddiff= (explicit synchronization id+255-self maintained implicit synchronization ID)% 255;
iddiff= (explicit synchronization id+65535-self-maintained implicit synchronization ID)% 65535, if not in CAN protocol scenario but in CAN-FD protocol scenario;
step 3-7, judging whether the value of IDDiff is in an allowable range;
if IDDiff is not in the allowable range, reporting an exception and then exiting the processing;
if IDDiff is within the allowable range, the true synchronization ID is added with the value of IDDiff;
step 3-8, decrypting and checking the ciphertext message by using the communication key of the CAN message ID, the real synchronous ID and the CAN message ID;
step 3-9, judging whether the signature verification is successful;
if the signature verification fails, reporting an abnormality and then exiting the processing;
if the signature verification is successful, the true synchronous ID is added with 1 again;
step 3-10, judging whether the CAN protocol scene exists or not;
if in the CAN protocol scene, the implicit synchronous ID is set to 255, and the sum of (1+IDDiff) is added in the mode;
if not in the CAN protocol scenario, the implicit synchronization ID is set to 65535 in-mold plus (1+IDDiff);
and 3-11, the ECU_B returns the plaintext data to the service processing, and normally ends the service data encryption and decryption transmission flow.
9. The low-cost and high-reliability vehicle-mounted CAN bus secure communication method of claim 7, wherein the initial key initialization procedure is:
step 4-1, the upper computer initiates a communication key presetting process in a safe production environment;
step 4-2, the upper computer encrypts the initial key of the communication matrix by using the root key of the ECU through a lightweight AEAD algorithm to generate ciphertext data and MAC, and sends the ciphertext data and the MAC to the target ECU through a communication key preset message;
step 4-3, judging whether the ECU has a root key;
if the ECU has the root key, the ECU uses the own root key to decrypt and verify the ciphertext message through a lightweight AEAD algorithm; if the signature verification is successful, using an initial key of a communication matrix in the message as an initial key of the communication matrix of the ECU, and sending a success message, otherwise, directly exiting the key presetting flow;
if the ECU does not have the root key, the ECU applies the root key to the upper computer; the upper computer encrypts the root key by using a hard-coded temporary key in the ECU through a lightweight AEAD algorithm to generate ciphertext data and MAC, and sends the ciphertext data and the MAC to the target ECU through a root key preset message; the ECU uses the self temporary key to decrypt and check the ciphertext message through a lightweight AEAD algorithm; if the signature verification is successful, the ECU uses the root key in the message as the root key of the ECU, then returns a root key preset success message, otherwise, directly exits the key preset flow; and after receiving the root key presetting success message, the upper computer initiates a communication key presetting flow to the target ECU again.
CN202311691073.5A 2023-12-11 2023-12-11 Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system Active CN117395003B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311691073.5A CN117395003B (en) 2023-12-11 2023-12-11 Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311691073.5A CN117395003B (en) 2023-12-11 2023-12-11 Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system

Publications (2)

Publication Number Publication Date
CN117395003A CN117395003A (en) 2024-01-12
CN117395003B true CN117395003B (en) 2024-03-08

Family

ID=89467066

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311691073.5A Active CN117395003B (en) 2023-12-11 2023-12-11 Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system

Country Status (1)

Country Link
CN (1) CN117395003B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020258060A2 (en) * 2019-06-25 2020-12-30 南京邮电大学 Blockchain-based privacy protection trust model for internet of vehicles
CN113794734A (en) * 2021-09-26 2021-12-14 上汽通用五菱汽车股份有限公司 Vehicle-mounted CAN bus encryption communication method, control device and readable storage medium
CN116074000A (en) * 2023-02-20 2023-05-05 东风汽车集团股份有限公司 Conversation key distribution method and system based on CAN bus
CN116405302A (en) * 2023-04-19 2023-07-07 合肥工业大学 System and method for in-vehicle safety communication

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100031057A1 (en) * 2008-02-01 2010-02-04 Seagate Technology Llc Traffic analysis resistant storage encryption using implicit and explicit data
US11522696B2 (en) * 2020-03-13 2022-12-06 Dearborn Group, Inc. Intrusion defense system for a vehicle

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020258060A2 (en) * 2019-06-25 2020-12-30 南京邮电大学 Blockchain-based privacy protection trust model for internet of vehicles
CN113794734A (en) * 2021-09-26 2021-12-14 上汽通用五菱汽车股份有限公司 Vehicle-mounted CAN bus encryption communication method, control device and readable storage medium
CN116074000A (en) * 2023-02-20 2023-05-05 东风汽车集团股份有限公司 Conversation key distribution method and system based on CAN bus
CN116405302A (en) * 2023-04-19 2023-07-07 合肥工业大学 System and method for in-vehicle safety communication

Also Published As

Publication number Publication date
CN117395003A (en) 2024-01-12

Similar Documents

Publication Publication Date Title
CN103595530A (en) Software secret key updating method and device
Oguma et al. New attestation based security architecture for in-vehicle communication
JP2008507203A (en) Method for transmitting a direct proof private key in a signed group to a device using a distribution CD
CN110896387B (en) Data transmission method, battery management system and storage medium
CN111865922B (en) Communication method, device, equipment and storage medium
CN114640462B (en) Block chain privacy protection method and device, electronic equipment and storage medium
CN110635904B (en) Remote attestation method and system for software-defined Internet of things node
CN110096894A (en) A kind of data anonymous shared system and method based on block chain
CN113613214A (en) In-vehicle message authentication key management method and readable storage medium
CN106850232B (en) The authorization management method and system that state is kept
CN109921908B (en) CAN bus identity authentication method and identity authentication system
WO2015178597A1 (en) System and method for updating secret key using puf
CN117395003B (en) Low-cost high-reliability vehicle-mounted CAN bus safety communication method and safety communication system
Keleman et al. Secure firmware update in embedded systems
US11303444B2 (en) Method for synchronized signature with additive RSA key splitting using early floating exponent negotiation
CN115767539A (en) 5G authentication method based on terminal identifier update
CN113014391B (en) Authentication method of embedded system, terminal equipment and computer readable storage medium
CN115396190A (en) Data encryption method, decryption method and device
CN111736868B (en) Automobile remote updating method based on identity identification and bidirectional verification
CN115702424A (en) Method and vehicle bus system for forwarding ASIL-related information from a data source to a data sink
CN104052756B (en) A kind of method and system of business network element secure accessing service controller
US20170222810A1 (en) User permission check system
US11930117B2 (en) Method and apparatus for reversible tokenization with support for embeddable role-based access control
US11570008B2 (en) Pseudonym credential configuration method and apparatus
CN112822196B (en) Communication method and system for central domain control

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant