A dynamic stream encryption authentication communication method and system capable of detecting CAN replay attacks

Abstract

The present invention relates to the field of in-vehicle network communication technology, and discloses a dynamic stream encryption authentication communication method and system capable of detecting CAN replay attacks. The method comprises: an in-vehicle gateway assigns quantum random numbers to two ECUs that are ready to communicate; each ECU generates associated data based on context information generated by historical CAN data frames on the bus, and updates the encryption state value using the associated data and the key value; the sender ECU encrypts the CAN message plaintext using the updated encryption state value, calculates the corresponding first authentication tag, and then sends the encrypted data and the first authentication tag to the receiver ECU; the receiver ECU decrypts the encrypted data using the updated encryption state value, calculates the second authentication tag and compares it with the first authentication tag, and determines whether to accept the CAN message plaintext based on the comparison result. The present invention can effectively detect CAN replay attacks and improve the security of CAN data encryption.

Description

Technical Field

[0001] The present invention relates to the technical field of in-vehicle network communication, and in particular to a dynamic stream encryption authentication communication method and system capable of detecting CAN replay attacks. Background Art

[0002] CAN (Controller Area Network) is a multi-master bus network that allows multiple nodes in the network to send and receive messages in an uncertain order. CAN communication has the advantages of high reliability, real-time performance, strong anti-interference, flexibility and cost-effectiveness, and is suitable for automotive systems that require fast response.

[0003] The existing CAN communication protocol was designed earlier and is mainly oriented towards real-time and efficiency. Therefore, there is no built-in encryption or authentication mechanism, and all nodes can freely read the messages transmitted on the bus. Therefore, there are the following problems: (1) Data eavesdropping: Any device connected to the CAN bus can monitor the communication data, resulting in information leakage. (2) Forged messages: Since there is no authentication, malicious nodes can send forged messages, which may cause system insecurity or operational failure. (3) Difficult to detect replay attacks: Messages in CAN communication do not have timestamps or sequence numbers, so it is vulnerable to replay attacks. In a replay attack, the attacker can capture legitimate messages and resend them later, causing the system to perform incorrect operations. Due to the lack of protection mechanisms, traditional CAN systems find it difficult to detect these replay attacks, and the security of CAN data encryption needs to be improved, so it needs to be solved urgently. Summary of the invention

[0004] In order to solve the technical problem that traditional CAN communication is difficult to detect replay attacks and the security of CAN data encryption needs to be improved, the present invention provides a dynamic stream encryption authentication communication method and system that can detect CAN replay attacks.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] The present invention discloses a dynamic stream encryption authentication communication method capable of detecting CAN replay attacks, comprising:

[0007] The in-vehicle gateway distributes quantum random numbers to the two ECUs that are preparing to communicate, and the two ECUs generate a common key value and initial values ​​of the encryption state value based on the quantum random numbers.

[0008] Each ECU generates associated data according to context information generated by historical CAN data frames on the bus, and updates the encryption state value using the associated data and the key value.

[0009] The sending ECU encrypts the CAN message plaintext using the updated encryption state value, calculates the corresponding first authentication tag, and then sends the encrypted data and the first authentication tag to the receiving ECU.

[0010] The receiving ECU decrypts the encrypted data using the updated encryption state value, calculates the second authentication tag and compares it with the first authentication tag, and determines whether to accept the plain text of the CAN message based on the comparison result.

[0011] As a further improvement of the above solution, the in-vehicle gateway allocates quantum random numbers to two ECUs that are ready to communicate, and the two ECUs generate a common key value and an initial value of the encryption state value based on the quantum random number, including:

[0012] The in-vehicle gateway obtains the first quantum random number and the second quantum random number from the cloud, and sends the two quantum random numbers to the two ECUs at the same time.

[0013] Each ECU uses the first N1 bits of the first quantum random number as the initial value of the encryption state value, and uses the first N1 bits of the second random number as the key value; N1>0.

[0014] As a further improvement of the above solution, each ECU generates associated data based on the context information generated by the historical CAN data frame on the bus, including:

[0015] Each ECU obtains the CAN IDs of several CAN data frames recently transmitted on the bus, assigns the occupants of the several CANIDs obtained to a temporary associated data in sequence, and then performs hash processing on the temporary associated data to obtain the associated data; wherein the associated data has a total of N2 bits, N2=N1 / 2.

[0016] As a further improvement of the above solution, the updating of the encryption state value by using the associated data and the key value includes:

[0017] Step 2.1: Perform bitwise XOR on the encrypted state value and the first quantum random number.

[0018] Step 2.2: Use the key value to perform x1 rounds of permutation operations on the content of the encrypted state value; where x1>1.

[0019] Step 2.3, perform an XOR operation on the first N2 / 2 bits of the associated data and the last N2 / 2 bits of the encryption state value, then repeat steps 2.1 and 2.2 once, perform an XOR operation on the last N2 / 2 bits of the associated data and the last N2 / 2 bits of the encryption state value, thereby updating the encryption state value.

[0020] As a further improvement of the above scheme, step 2.2 includes the following specific processes:

[0021] Step 2.21, divide the N1-bit encryption state value into N3 first basic units, and divide the N1-bit key value into N3 second basic units; wherein, N1=N3×4; N3>4.

[0022] Step 2.22: Extract four first basic units and one second basic unit according to the preset sequence number, perform XOR calculation, and obtain a temporary variable Temp; wherein the calculation formula of Temp is:

[0023] ;

[0024] In the formula, SB a , SB b , SB c , SB d are the four first basic units extracted respectively, and KB is the second basic unit extracted;

[0025] Indicates negation. Represents bitwise AND; Indicates the scope of the status update; Is the XOR symbol.

[0026] Step 2.23, arrange the N3 first basic units in ascending order according to the serial numbers, and starting from the second first basic unit, assign each first basic unit to the adjacent previous first basic unit in turn, and assign the temporary variable Temp to the last first basic unit, thereby completing a round of permutation operation.

[0027] Step 2.24: Execute steps 2.22 to 2.23 in a loop, and continuously process the encryption status value after each round of permutation operation until the set round is reached.

[0028] As a further improvement of the above solution, the sending ECU encrypts the CAN message plaintext using the updated encryption state value, calculates the corresponding first authentication tag, and then sends the encrypted data and the first authentication tag to the receiving ECU, including:

[0029] Step 3.1, the sending ECU repeats steps 2.1 and 2.2, divides its own encryption status value into four equal segments, and XORs the last segment of the four segments with the first N2 / 2 bits of the CAN message plaintext to update the encryption status value; wherein, the CAN message plaintext has a total of N2 bits.

[0030] Step 3.2: The sending ECU performs XOR operation on the second to last segment of the four segments of the encrypted status value and the first N2 / 2 bits of the CAN message plaintext, and obtains the first half of the CAN message ciphertext based on the XOR result.

[0031] Step 3.3: The sending ECU repeats steps 2.1 and 2.2, and XORs the last segment of the four segments of the encryption status value with the last N2 / 2 bits of the CAN message plaintext to update the encryption status value.

[0032] Step 3.4, perform XOR operation on the second to last segment of the four segments of the encryption status value and the last N2 / 2 bits of the CAN message plaintext, and obtain the second half of the CAN message ciphertext according to the XOR result, so as to use the complete CAN message ciphertext as the encrypted data.

[0033] Step 3.5: The sending ECU generates a first authentication tag of N2 bits, and transmits the first authentication tag together with the encrypted data in the form of a plain text message to the receiving ECU through the bus.

[0034] As a further improvement of the above solution, in step 3.5, the generation process of the first authentication tag is as follows:

[0035] Step 3.51, repeat step 2.1 once, and then perform x2 rounds of permutation operations on the content of the encrypted state value in the manner of step 2.2; wherein 1<x2<x1.

[0036] Step 3.52: Assign the second to last segment of the four segments of the encrypted state value to the first half of the first authentication tag.

[0037] Step 3.53: Generate the second half of the first authentication label by referring to the method of steps 3.51 to 3.52, so as to form a complete first authentication label.

[0038] As a further improvement of the above solution, the receiving ECU decrypts the encrypted data using the updated encryption state value, recalculates the authentication tag and compares it with the received authentication tag, and determines whether to accept the CAN message plaintext according to the comparison result, including:

[0039] Step 4.1, the receiving ECU repeats step 2.1 and step 2.2, then divides its own encrypted state value into four equal segments, XORs the second-to-last segment of the four encrypted state value segments with the first half of the CAN message ciphertext, and obtains the first half of the CAN message plaintext based on the XOR result.

[0040] Step 4.2: The receiving ECU performs XOR operation on the last segment of the four segments of the encrypted status value and the first half of the plaintext of the CAN message to update the encrypted status value.

[0041] Step 4.3, the receiving ECU repeats step 2.1 and step 2.2 once, and the receiving ECU performs XOR operation on the second-to-last segment of the four segments of the encrypted state value and the second half of the CAN message ciphertext, and obtains the second half of the CAN message plaintext based on the XOR result, thereby obtaining the complete CAN message plaintext.

[0042] Step 4.4: The receiving ECU performs XOR operation on the last segment of the four segments of the encrypted status value and the second half of the plaintext of the CAN message to update the encrypted status value.

[0043] Step 4.5: The receiving ECU generates a second authentication tag by referring to steps 3.51 to 3.53. If the first authentication tag and the second authentication tag are the same, the CAN message plain text is accepted.

[0044] The present invention also discloses a dynamic stream encryption authentication communication system capable of detecting CAN replay attacks, comprising an in-vehicle gateway, a bus and multiple ECUs. The communication system applies the dynamic stream encryption authentication communication method capable of detecting CAN replay attacks as described above.

[0045] Compared with the prior art, the present invention has the following beneficial effects:

[0046] 1. The dynamic stream encryption authentication communication method capable of detecting CAN replay attacks disclosed in the present invention has a lightweight CAN replay attack detection function. The encryption state value of the CAN message is updated through the context information generated by the CAN frame on the bus, and an authentication tag is generated at the same time to authenticate whether the encrypted data can be correctly received, which can effectively detect CAN replay attacks. In addition, the present invention also uses quantum random numbers as the initial values ​​of the key and the encryption state value, which provides stronger randomness and unpredictability for the security of CAN data encryption.

[0047] 2. The dynamic stream encryption authentication communication method of the present invention also has high performance and security. Despite its simple design, it can still provide efficient encryption and decryption speeds, thereby performing efficient authentication of CAN replay attacks. The method uses a design method that has been verified for security and can resist a variety of known attacks to ensure the confidentiality and integrity of the data.

[0048] 3. The present invention has a lightweight design mechanism. It occupies a small area in hardware implementation and has high energy efficiency, which is very suitable for embedded devices. It can use a state register of N1 bits (such as 128 bits) to achieve high efficiency and low power consumption of state updates through simple shift and XOR operations, reducing the need for complex computing resources. In addition, by reducing the number of update rounds of the encrypted state value when calculating the authentication tag, lower power consumption and computing overhead are achieved while providing sufficient security.

[0049] 4. The present invention further reduces the computational complexity and hardware implementation complexity by omitting complex nonlinear transformations (such as encryption state value update modules, etc.) and by designing hardware-friendly pipeline operations and parallel structures, thereby optimizing the performance in embedded devices. In addition, by eliminating complex key scheduling steps, the fast startup effect of the initialization and encryption phases is achieved, reducing startup delays. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 The present invention is a flowchart of a dynamic stream encryption authentication communication capable of detecting CAN replay attacks in an embodiment of the present invention.

[0051] Figure 2 This is a schematic diagram of updating the State value using associated data in an embodiment of the present invention.

[0052] Figure 3 Schematic diagram of the working process of the State value updating module in an embodiment of the present invention.

[0053] Figure 4 This is a schematic diagram of encryption and decryption transmission between a sending ECU and a receiving ECU in an embodiment of the present invention (the sequence numbers in the figure correspond to the sequence numbers of the steps). DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0055] This embodiment provides a dynamic stream encryption authentication communication system capable of detecting CAN replay attacks, including an in-vehicle gateway, a bus, and multiple ECUs. The communication system applies a dynamic stream encryption authentication communication method capable of detecting CAN replay attacks.

[0056] Among them, CAN is a multi-master bus network that allows multiple nodes in the network to send and receive messages in an uncertain order. The CAN bus has the following characteristics: ① Two-wire design: The CAN bus uses two signal lines for communication, called CAN_H (high level) and CAN_L (low level). These two lines transmit data in the form of differential signals, thereby improving anti-interference capabilities. ② Message priority: Each message contains a unique identifier (ID) to determine the priority of the message. In the event of bus competition, messages with high priority will be transmitted first. ③ Non-destructive bus arbitration: The CAN protocol solves the bus competition problem through a bit arbitration mechanism to ensure that no data is lost. ④ Error detection and processing: The CAN protocol has powerful error detection capabilities, including cyclic redundancy check (CRC), frame check, response error detection, and bit level detection. Error nodes will be actively isolated from the network to ensure the overall reliability of the network. ⑤ Real-time: Due to the low latency characteristics in the CAN bus design, it is very suitable for real-time applications, especially in automotive systems that require fast response. The basic unit of CAN communication is the data frame, which is used to transmit information between nodes. In the standard frame format, the identifier (ID) occupies 11 bits, the data field is up to 8 bytes, the data length code (DLC) occupies 4 bits, indicating the number of bytes in the data field, the CRC field has a 15-bit cyclic redundancy check code for error detection, and the control field occupies 3 bits. The frame types include data frames, remote frames, error frames, and overload frames, which are used to carry actual data, request other nodes to send data frames, send when a node detects an error, and provide additional delay to handle high-priority tasks.

[0057] ECU (Electronic Control Unit) is a microcomputer inside the car, which is used to control and manage various electronic systems of the vehicle, such as the engine, transmission, braking system, airbag, infotainment system, etc. ECU exchanges data and coordinates control with other ECUs through the CAN communication protocol to form a networked vehicle control system. CAN communication is a decentralized communication protocol that allows each ECU to send and receive key information in real time, such as sensor data, status instructions, diagnostic messages, etc., to achieve system interconnection and collaborative work. This communication method has high reliability and anti-interference ability, ensuring the stability and efficient operation of the electronic system of the vehicle during driving. For example, the engine ECU communicates with the transmission ECU through the CAN bus to optimize the shifting timing and improve fuel efficiency; at the same time, the ABS ECU (anti-lock braking system) can exchange information with the ESPECU (electronic stability program) in real time to enhance the active safety performance of the vehicle. Through CAN communication, each ECU of the car can be controlled in a distributed manner, making the vehicle function more complex and intelligent.

[0058] See also Figure 1The above-mentioned dynamic stream encryption authentication communication method includes steps 1 to 4.

[0059] Step 1: The in-vehicle gateway assigns quantum random numbers to the two ECUs that are ready to communicate. The two ECUs generate a common key value and an initial value of the encryption state value (State value) based on the quantum random numbers.

[0060] Step 1 includes the following specific processes:

[0061] The in-vehicle gateway obtains the first quantum random number and the second quantum random number from the cloud, and sends the two quantum random numbers to the two ECUs at the same time;

[0062] Each ECU uses the first N1 bits of the first quantum random number as the initial value of the encryption state value, and uses the first N1 bits of the second random number as the key value; N1>0.

[0063] In this embodiment, the in-vehicle gateway obtains two quantum random numbers (QRNG1, QRNG2) from the cloud. The gateway distributes the two quantum random numbers obtained to two ECUs that are about to communicate with each other. The ECU uses the first 128 bits of QRNG1 as the initial value of State in the dynamic stream encryption authentication algorithm, and uses the first 128 bits of QRNG2 as the key K (K0~K127) in the dynamic stream encryption authentication algorithm.

[0064] In the process of in-vehicle communication, encryption keys also have a very important impact on information encryption. The generation of keys is often based on random numbers and passwords, and the randomness of random numbers will affect the security of the generated keys. In front of computers with powerful computing power, pseudo-random numbers generated by elements such as seed information, preset functions and constants will become extremely unsafe. True random numbers are often generated through some unpredictable physical phenomena. For example, quantum random number generators generate random numbers through the physical phenomenon of photons. Generating quantum keys using true random numbers will have higher security. The most commonly used quantum key distribution is in 1984, when Bennett and Brassard proposed a key distribution protocol, namely the BB84 protocol. Quantum encryption communication has unconditional security, which is determined by the non-cloning principle and uncertainty principle of quantum physics. On the one hand, quantum keys generated based on quantum random numbers are more difficult to crack and have higher security. On the other hand, the quantum key distribution process has been proven to be absolutely safe, and any third-party eavesdropping will be discovered in a timely manner.

[0065] Step 2: Each ECU generates associated data based on the context information generated by the historical CAN data frame on the bus, and updates the encryption state value using the associated data and the key value.

[0066] In step 2, the process of generating associated data is as follows:

[0067] Each ECU obtains the CAN IDs of several CAN data frames recently transmitted on the bus, assigns the occupants of the several CANIDs obtained to a temporary associated data in sequence, and then performs hash processing on the temporary associated data to obtain the associated data; wherein the associated data has a total of N2 bits, N2=N1 / 2.

[0068] In this embodiment, N1=128, N2=64, and N3=32. The ECU calculates a 64-bit associated data string for each CAN data frame sent over the bus. In order to link the current CAN data frame with the previously transmitted CAN message, the CAN IDs of the six most recently transmitted CAN data frames can be used to calculate this 64-bit associated data string. The calculated associated data string is used during the State value update to support data encryption and message authentication of the currently transmitted CAN data frame.

[0069] Specifically, the ECU represents the CAN IDs of the six CAN data frames most recently transmitted on the bus as IDi-1, IDi-2, IDi-3, IDi-4, IDi-5, and IDi-6, respectively. The ID occupies 11 bits. The 0-10 bits of IDi-1 are assigned to the 0-10 bits of the temporary associated data Adtemp

[66] , the 0-10 bits of IDi-2 are assigned to the 11-21 bits of the temporary associated data Adtemp

[66] , the 0-10 bits of IDi-3 are assigned to the 22-32 bits of the temporary associated data Adtemp

[66] , the 0-10 bits of IDi-4 are assigned to the 33-43 bits of the temporary associated data Adtemp

[66] , the 0-10 bits of IDi-5 are assigned to the 44-54 bits of the temporary associated data Adtemp

[66] , and the 0-10 bits of IDi-6 are assigned to the 55-65 bits of the temporary associated data Adtemp

[66] . Then, the Hash64 function is used to perform hash processing on the 66-bit characters of Adtemp

[66] . The result of the processing is the 64-bit associated data Ad

[64] . The next step is to use the associated data Ad

[64] to update the State value, which may include the following specific processes, namely steps 2.1 to 2.3.

[0070] Step 2.1: Perform bitwise XOR on the encrypted state value and the first quantum random number.

[0071] Step 2.2, use the key value to perform x1 rounds of permutation operations on the content of the encrypted state value; wherein x1>1; Step 2.2 includes the following specific process, namely, step 2.21 to step 2.24.

[0072] Step 2.21, divide the N1-bit encryption state value into N3 first basic units, and divide the N1-bit key value into N3 second basic units; wherein, N1=N3×4; N3>4.

[0073] Step 2.22: Extract four first basic units and one second basic unit according to the preset sequence number, perform XOR calculation, and obtain a temporary variable Temp; wherein the calculation formula of Temp is:

[0074] ;

[0075] In the formula, SB a , SB b , SB c , SB d are the four first basic units extracted respectively, and KB is the second basic unit extracted; Indicates negation. Represents bitwise AND; Indicates the scope of the status update; Is the XOR symbol.

[0076] Step 2.23, arrange the N3 first basic units in ascending order according to the serial numbers, and starting from the second first basic unit, assign each first basic unit to the adjacent previous first basic unit in turn, and assign the temporary variable Temp to the last first basic unit, thereby completing a round of permutation operation.

[0077] Step 2.24: Execute steps 2.22 to 2.23 in a loop, and continuously process the encryption status value after each round of permutation operation until the set round is reached.

[0078] Step 2.3, perform an XOR operation on the first N2 / 2 bits of the associated data and the last N2 / 2 bits of the encryption state value, then repeat steps 2.1 and 2.2 once, perform an XOR operation on the last N2 / 2 bits of the associated data and the last N2 / 2 bits of the encryption state value, thereby updating the encryption state value.

[0079] In this embodiment, Figure 2As shown, after completing the initialization phase and generating associated data, the first step is to perform bitwise XOR operation on the State value and QRNG1 to update the State value. The second step is to perform 1024 rounds of permutation operation on the State value through the State value update module to permute the content of State. The third step is to permute the bits of the State value, perform XOR operation on the Ad[0-31] bits of the associated data and the State[96-127] bits to update the State value; then repeat the first and second steps to permute the content of State, and perform XOR operation on the Ad[32-63] bits of the associated data and the State[96-127] bits to update the State value.

[0080] like Figure 3 As shown, the working process of the above-mentioned State value update module is: the 128-bit State value and the key K value are updated with 4 bits as the basic unit, the State value is divided into 32 blocks (SB0~SB31), and the key K value is divided into 32 blocks (KB0~KB31). For the i-th round of update, the value calculated by KBi⊕SB6⊕(~(SB13&SB19))⊕SB26 mod 128 is temporarily stored in the variable Temp, and the State value is shifted to the right with the block as the basic unit, SB1→SB0, SB2→SB1, SB3→SB2...SB31→SB30, and finally Temp is assigned to SB31, completing a round of update for the State value.

[0081] It should be noted that, for example, if there are 100 rounds of updates, the KB of the first round takes K0, K1, K2, and K3 to update the State value, and the K4, K5, K6, and K7 of K are taken as KB1 to update the State value in the second round, and so on, until the 32nd round, K124, K125, K126, and K127 of K are taken as KB31 to update the State value. The KB value used in the 33rd round is the same as that in the first round, similar to the operation of loop processing, until the update of the State value of all rounds is completed. This module will be used repeatedly in the subsequent stages to perform the replacement operation on the State value.

[0082] See also Figure 4 .

[0083] Step 3: The sending ECU encrypts the 64-bit CAN message plaintext using the updated encryption state value, calculates the corresponding first authentication tag, and then sends the encrypted data and the first authentication tag to the receiving ECU.

[0084] Step 3 includes the following specific processes, namely steps 3.1 to 3.5.

[0085] Step 3.1, the sending ECU repeats steps 2.1 and 2.2, divides its own encryption status value into four equal segments (segment and basic unit have the same meaning), and XORs the last segment of the four segments of the encryption status value with the first N2 / 2 bits of the CAN message plaintext to update the encryption status value; among which, the CAN message plaintext has a total of N2 bits.

[0086] Step 3.2: The sending ECU performs XOR operation on the second to last segment of the four segments of the encrypted status value and the first N2 / 2 bits of the CAN message plaintext, and obtains the first half of the CAN message ciphertext based on the XOR result.

[0087] Step 3.3: The sending ECU repeats steps 2.1 and 2.2, and XORs the last segment of the four segments of the encryption status value with the last N2 / 2 bits of the CAN message plaintext to update the encryption status value.

[0088] Step 3.4, perform XOR operation on the second to last segment of the four segments of the encryption status value and the last N2 / 2 bits of the CAN message plaintext, and obtain the second half of the CAN message ciphertext according to the XOR result, so as to use the complete CAN message ciphertext as the encrypted data.

[0089] In this embodiment, in the data encryption step, the State value is bitwise XORed with QRNG1 to update the State value, and the permutation operation is performed through 1024 rounds of the State value update module, and then the State bit {S96,…, S127} is updated by XORing the current State bit {S96,…, S127} with the CAN message plaintext bit {M32i,…, M32i+31}. The value of the ciphertext bit {C32i,…, C32i+31} is calculated by XORing the State value bit {S64,…, S95} with the CAN message plaintext bit {M32i,…, M32i+31}. The above steps are performed twice, that is, i takes 0 and 1, and the encryption of M is completed to obtain the ciphertext C{C0,…, C63}. It should be noted that the subsequent encryption operation of other CAN data is based on the State value after the previous CAN data encryption.

[0090] Step 3.5: The sending ECU generates a first authentication tag of N2 bits, and transmits the first authentication tag together with the encrypted data in the form of a plain text message to the receiving ECU through the bus.

[0091] In this embodiment, the sending ECU supports authentication encryption of the CAN message plaintext M by generating a 64-bit authentication tag TagM. The authentication tag is transmitted together with the CAN message ciphertext C. In order for the ECU to recognize that the CAN frame is an authentication tag rather than a payload, the calculated authentication tag can be transmitted on the CAN bus using a single CAN frame with a predefined ID (2047). The authentication tags are not encrypted, they are transmitted over the CAN bus as plaintext messages.

[0092] In step 3.5, the generation process of the first authentication tag is as follows, namely step 3.51 to step 3.53.

[0093] Step 3.51: Repeat step 2.1 once, and then perform x2 rounds of permutation operations on the content of the encrypted state value in the manner of step 2.2. In this embodiment, x1=1024, x2=640.

[0094] Step 3.52: Assign the second to last segment of the four segments of the encrypted state value to the first half of the first authentication tag.

[0095] Step 3.53: Generate the second half of the first authentication label by referring to the method of steps 3.51 to 3.52, so as to form a complete first authentication label.

[0096] In this embodiment, the encrypted State value is bitwise XORed with QRNG1 to update the State value, and the State bit is permuted through 640 rounds of the State value update module, and the [S64, S65, ..., S95] bits of the State value are assigned to the [0-31] bits of the TM. Then the State value is bitwise XORed with QRNG1 to update the State value, and the State bit is permuted through 640 rounds of the State value update module, and the [S64, S65, ..., S95] bits of the State value are assigned to the [32-63] bits of the TM. The generation of the first authentication tag is completed. The sending ECU sends the encrypted data C and the authentication tag TM to the receiving ECU.

[0097] Step 4: The receiving ECU decrypts the encrypted data using the updated encryption status value, calculates the second authentication tag and compares it with the first authentication tag, and determines whether to accept the plaintext CAN message based on the comparison result.

[0098] Step 4 includes the following specific processes, namely step 4.1 to step 4.5.

[0099] Step 4.1, the receiving ECU repeats step 2.1 and step 2.2, then divides its own encrypted state value into four equal segments, XORs the second-to-last segment of the four encrypted state value segments with the first half of the CAN message ciphertext, and obtains the first half of the CAN message plaintext based on the XOR result.

[0100] Step 4.2: The receiving ECU performs XOR operation on the last segment of the four segments of the encrypted status value and the first half of the plaintext of the CAN message to update the encrypted status value.

[0101] Step 4.3, the receiving ECU repeats step 2.1 and step 2.2 once, and the receiving ECU performs XOR operation on the second-to-last segment of the four segments of the encrypted state value and the second half of the CAN message ciphertext, and obtains the second half of the CAN message plaintext based on the XOR result, thereby obtaining the complete CAN message plaintext.

[0102] Step 4.4: The receiving ECU performs XOR operation on the last segment of the four segments of the encrypted status value and the second half of the plaintext of the CAN message to update the encrypted status value.

[0103] In this embodiment, the receiving ECU has the same initialization State value and key, and the same associated data processing stage as the sending ECU. Similar to data encryption, the State value is bitwise XORed with QRNG1 to update the State value, and the content of State is then updated according to the result of the XOR operation. The State bit is permuted by 1024 rounds of the State value update module. In the first iteration of the data decryption mode, the {M0,…,M31} bits of the plaintext are calculated by XORing the {C0,…,C31} bits of the ciphertext with the {S64,…,S95} bits of the State value. The {S96,…,S127} bits of the State value are updated by XORing the {S96,…,S127} bits of the current State value with the {M0,…,M31} bits of the calculated plaintext. Similarly, {M32,…,M63} bits of the plaintext are computed by XORing {C32,…,C63} bits of the ciphertext with {S64,…,S95} bits of the State value, and then using the resulting plaintext bits to modify the contents of {S96,…,S127} bits of the current State value.

[0104] Step 4.5: The receiving ECU generates a second authentication tag by referring to steps 3.51 to 3.53. If the first authentication tag and the second authentication tag are the same, the CAN message plain text is accepted.

[0105] In the verification step, the receiving ECU authenticates the CAN message plaintext M by calculating the 64-bit second authentication tag T'M and compares it with the received first authentication tag TM. If T'M = TM, the message is authenticated and accepted, otherwise the received message will be rejected.

[0106] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A dynamic stream encryption authentication communication method capable of detecting CAN replay attacks, characterized in that: include: The in-vehicle gateway distributes quantum random numbers to the two ECUs that are ready to communicate. The two ECUs generate a common key value and an initial value of the encryption state value based on the quantum random numbers. Each ECU generates associated data based on context information generated by historical CAN data frames on the bus, and updates the encryption state value using the associated data and the key value; The sending ECU encrypts the CAN message plaintext using the updated encryption state value, calculates the corresponding first authentication tag, and then sends the encrypted data and the first authentication tag to the receiving ECU; The receiving ECU decrypts the encrypted data using the updated encryption state value, calculates the second authentication tag and compares it with the first authentication tag, and determines whether to accept the plain text of the CAN message according to the comparison result; The in-vehicle gateway allocates quantum random numbers to two ECUs that are ready to communicate, and the two ECUs generate a common key value and an initial value of an encryption state value based on the quantum random number, including: The in-vehicle gateway obtains the first quantum random number and the second quantum random number from the cloud, and sends the two quantum random numbers to the two ECUs at the same time; Each ECU uses the first N1 bits of the first quantum random number as the initial value of the encryption state value, and uses the first N1 bits of the second random number as the key value; N1>0; Each ECU generates associated data based on the context information generated by the historical CAN data frame on the bus, including: Each ECU obtains the CAN IDs of several CAN data frames recently transmitted on the bus, assigns the occupants of the several CAN IDs to a temporary associated data in sequence, and then performs hash processing on the temporary associated data to obtain the associated data; wherein the associated data has a total of N2 bits, N2=N1 / 2; The updating of the encryption state value by using the association data and the key value comprises: Step 2.1, perform bitwise XOR on the encrypted state value and the first quantum random number; Step 2.2, using the key value to perform x1 rounds of permutation operations on the content of the encrypted state value; wherein x1>1; Step 2.3, perform an XOR operation on the first N2 / 2 bits of the associated data and the last N2 / 2 bits of the encryption state value, then repeat steps 2.1 and 2.2 once, perform an XOR operation on the last N2 / 2 bits of the associated data and the last N2 / 2 bits of the encryption state value, thereby updating the encryption state value.

2. A dynamic stream encryption authentication communication method capable of detecting CAN replay attacks according to claim 1, characterized in that: Step 2.2 includes the following specific processes: Step 2.21, divide the N1-bit encryption state value into N3 first basic units, and divide the N1-bit key value into N3 second basic units; wherein N1=N3×4; N3>4; Step 2.22: Extract four first basic units and one second basic unit according to the preset sequence number, perform XOR calculation, and obtain a temporary variable Temp; wherein the calculation formula of Temp is: ； In the formula, SB a , SB b , SB c , SB d are the four first basic units extracted respectively, and KB is the second basic unit extracted; Indicates negation. Represents bitwise AND; Indicates the scope of the status update; is the XOR symbol; Step 2.23, arrange the N3 first basic units in ascending order according to the serial numbers, and starting from the second first basic unit, assign each first basic unit to the adjacent previous first basic unit in turn, and assign the temporary variable Temp to the last first basic unit, thereby completing a round of replacement operation; Step 2.24: Execute steps 2.22 to 2.23 in a loop, and continuously process the encryption status value after each round of permutation operation until the set round is reached.

3. A dynamic stream encryption authentication communication method capable of detecting CAN replay attacks according to claim 2, characterized in that: The sending ECU encrypts the CAN message plaintext using the updated encryption state value, calculates the corresponding first authentication tag, and then sends the encrypted data and the first authentication tag to the receiving ECU, including: Step 3.1, the sending ECU repeats steps 2.1 and 2.2, divides its own encryption status value into four equal segments, and XORs the last segment of the four segments of the encryption status value with the first N2 / 2 bits of the CAN message plaintext to update the encryption status value; wherein the CAN message plaintext has a total of N2 bits; Step 3.2, the sending ECU performs XOR operation on the second to last segment of the four segments of the encrypted status value and the first N2 / 2 bits of the CAN message plaintext, and obtains the first half of the CAN message ciphertext according to the XOR result; Step 3.3, the sending ECU repeats steps 2.1 and 2.2, and XORs the last segment of the four segments of the encryption status value with the last N2 / 2 bits of the CAN message plaintext to update the encryption status value; Step 3.4, XOR the penultimate segment of the four segments of the encryption state value with the last N2 / 2 bits of the CAN message plaintext, and obtain the second half of the CAN message ciphertext according to the XOR result, so as to use the complete CAN message ciphertext as the encrypted data; Step 3.5: The sending ECU generates a first authentication tag of N2 bits, and transmits the first authentication tag together with the encrypted data in the form of a plain text message to the receiving ECU through the bus.

4. A dynamic stream encryption authentication communication method capable of detecting CAN replay attacks according to claim 3, characterized in that: In step 3.5, the generation process of the first authentication tag is as follows: Step 3.51, repeat step 2.1 once, and then perform x2 rounds of permutation operations on the content of the encrypted state value in the manner of step 2.2; wherein 1<x2<x1; Step 3.52, assigning the second to last segment of the four segments of the encrypted state value to the first half of the first authentication tag; Step 3.53: Generate the second half of the first authentication label by referring to the method of steps 3.51 to 3.52, so as to form a complete first authentication label.

5. A dynamic stream encryption authentication communication method capable of detecting CAN replay attacks according to claim 4, characterized in that: The receiving ECU decrypts the encrypted data using the updated encryption state value, recalculates the authentication tag and compares it with the received authentication tag, and determines whether to accept the CAN message plaintext according to the comparison result: Step 4.1, the receiving ECU repeats step 2.1 and step 2.2, then divides its own encrypted state value into four equal segments, performs XOR on the second to last segment of the four encrypted state value segments and the first half of the CAN message ciphertext, and obtains the first half of the CAN message plaintext according to the XOR result; Step 4.2, the receiving ECU performs XOR operation on the last segment of the four segments of the encrypted status value and the first half of the plain text of the CAN message to update the encrypted status value; Step 4.3, the receiving ECU repeats step 2.1 and step 2.2 once, and the receiving ECU performs XOR on the second-to-last segment of the four segments of the encrypted state value and the second half of the CAN message ciphertext, and obtains the second half of the CAN message plaintext according to the XOR result, thereby obtaining the complete CAN message plaintext; Step 4.4, the receiving ECU performs XOR operation on the last segment of the four segments of the encrypted status value and the second half of the plain text of the CAN message to update the encrypted status value; Step 4.5: The receiving ECU generates a second authentication tag by referring to steps 3.51 to 3.

53. If the first authentication tag and the second authentication tag are the same, the CAN message plain text is accepted.

6. A dynamic stream encryption authentication communication system capable of detecting CAN replay attacks, comprising an in-vehicle gateway, a bus, and multiple ECUs, characterized in that: The communication system applies a dynamic stream encryption authentication communication method capable of detecting CAN replay attacks as described in any one of claims 1 to 5.

Images