A lightweight message verification method for the in-vehicle CAN bus

Abstract

The present invention discloses a method for lightweight message verification of the in-vehicle CAN bus, which relates to the technical field of in-vehicle CAN bus security, and includes the following steps: S1. According to the CAN bus of different vehicle models, initialize the counter and the long-term valid key of the electronic control unit when the vehicle leaves the factory, and represent the electronic control unit as ECU; S2. Initialize the session key and the message authentication code when the vehicle starts; S3. When the ECU communicates, calculate the message authentication code, verify the session message, update the session key, and synchronize the counter according to the result of verifying the session message. The present invention solves the problem that the existing in-vehicle CAN bus lacks a secure and efficient authentication mechanism, and has the characteristics of resisting forgery and replay attacks.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle internal CAN bus security, and more specifically, to a method for lightweight message verification of vehicle internal CAN bus. Background Art

[0002] The CAN2.0 (Controller Area Network 2.0, hereinafter referred to as CAN) bus protocol is the most commonly used in-vehicle network communication protocol at present. It uses a serial communication method, and messages in the network are transmitted based on a broadcast mechanism. It provides a real-time and secure communication link for in-vehicle ECU nodes, and has the advantages of high cost-effectiveness, anti-electrical interference, self-diagnosis and error correction.

[0003] As Figure 1 、 Figure 2 shown, there are four types of CAN bus message frames, namely data frames, remote frames, error frames and overload frames. The data frame is the main message frame type in CAN bus communication. It consists of seven parts: frame start bit, arbitration field, control field, data field, check field, acknowledgment field and frame end. According to the length of the identifier (ID) in its arbitration field, the data frame can be further divided into a standard data frame (CAN2.0A) and an extended data frame (CAN2.0B).

[0004] As Figure 3 shown, modern cars are equipped with forty to hundreds of ECUs to provide functions such as engine control, transmission control, steering control, body control, and driving safety and assisted driving. They are distributed throughout the vehicle and communicate with each other through the CAN bus.

[0005] According to the in-vehicle CAN bus topology, the ECUs in the vehicle are often divided into different sub-network segments according to their functional attributes, and are further divided into high-speed CAN buses and low-speed CAN buses according to the communication rate of the sub-network CAN bus. The central gateway connects sub-networks with different communication rates and controls the communication between sub-networks.

[0006] The communication of each ECU on the CAN bus is mainly based on the message sending and subscription mechanism. According to the preset communication matrix of the vehicle model, the message identifiers (hereinafter referred to as IDs) that each ECU can send and receive are specified. The ECU configures its receiver and transmitter according to the communication matrix. The ECU broadcasts a message frame with ID = idx to the CAN bus through the transmitter, and the ECU subscribing to the idx message frame detects whether the message frame appears on the bus through the receiver and selects to receive it.

[0007] The existing safety mechanisms of the CAN bus protocol are mainly used to ensure reliable communication. The protocol did not consider cybersecurity mechanisms during its design, and it has the following security vulnerabilities:

[0008] 1. There is no data encryption mechanism. The message transmission on the CAN bus adopts a broadcast mechanism, and the data is transmitted in plain text. When any ECU on the bus segment sends a message, all ECUs on that segment can receive the message. Malicious nodes can eavesdrop on the messages on the bus and obtain the real data in them, and then conduct reverse engineering to analyze the data to achieve vehicle control.

[0009] 2. There is no authentication mechanism. All ECUs can send and receive message frames through the CAN bus. When an ECU receives a message frame, it determines whether to accept the message frame based on the message ID of the message frame, and does not verify the source of the message frame, so its reliability cannot be verified. In addition, the bus network lacks the authentication of ECU nodes, and malicious nodes can join the bus without restriction and send malicious information to control or damage the vehicle.

[0010] 3. There is no message freshness guarantee mechanism. An attacker controls a malicious node to record the message frame sequence during the normal operation of the vehicle so that it does not understand the meaning of the message frame content. It can also replay the previously recorded message frame to the bus at any time, and the receiving ECU cannot determine whether the message frame is the latest message from a legitimate sender or a replay message sent by a malicious ECU. It can only execute commands according to the data content of the message frame, thus enabling the attacker to achieve the purpose of controlling and damaging the vehicle.

[0011] To address this issue, there is currently an authentication code calculation method HMAC (Hash-based Message Authentication Code) implemented based on a hash function. Hash functions such as MD5, SHA-1, and SHA-256 can be selected. By inputting a message and a key into the hash function, HMAC is obtained, which can be used to verify the integrity of the bus network message frame and the legitimacy of the source. The VeCure security framework proposed by Qiyan Wang et al. from Symantec Labs implements a hash-based message verification scheme. This scheme divides the ECUs in the bus segment into a trusted group and a non-trusted group. The ECUs within the trusted group share the same key for calculating the hash. The non-trusted group does not participate in message verification and can only communicate with the ECUs within the trusted group through the forwarding ECU of the trusted group. When each ECU is initialized at the manufacturing plant, it will be assigned a unique ID (identity number), a preset group key, and the session counter will be initialized. When the vehicle starts, each ECU will initialize a message counter and an overflow counter that are only used for this startup to count the number of message frames sent by the communicating partner ECU. The message verification scheme uses two consecutive message frames: an original information data frame followed by an HMAC data frame. After receiving the previous original information data frame, the receiving node starts to calculate the HMAC and compares it with the HMAC in the subsequent data frame. If they are the same, the verification is successful; otherwise, the verification fails. This scheme is simple to implement and the communication delay caused by HMAC calculation is relatively low. However, since two consecutive data frames are required to implement information transmission and verification, it will bring twice the bus communication load, and the key for calculating the hash is fixed, which has the possibility of being brute-forced.

[0012] Therefore, how to invent a method for verifying messages on the in-vehicle CAN bus to solve the problem of the lack of a secure and efficient authentication mechanism in the current in-vehicle CAN bus is an urgent problem to be solved in this technical field. Summary of the Invention

[0013] To solve the problem of the lack of a secure and efficient authentication mechanism in the in-vehicle CAN bus of the prior art, the present invention provides a lightweight message verification method for the in-vehicle CAN bus, which has the characteristics of resisting forgery and replay attacks.

[0014] To achieve the above object of the present invention, the following technical solutions are adopted:

[0015] A lightweight message verification method for the in-vehicle CAN bus includes the following steps:

[0016] S1. According to the CAN bus of different vehicle models, initialize the counter and the long-term valid key of the electronic control unit when the vehicle leaves the factory, and represent the electronic control unit as ECU;

[0017] S2. Initialize the session key and message authentication code when the vehicle starts;

[0018] S3. When the ECU communicates, calculate the message authentication code, verify the session message, update the session key, and synchronize the counter according to the result of verifying the session message.

[0019] Preferably, step S1 is specifically:

[0020] S101. Generate a long-term valid key KH for each message according to the CAN bus message ID set {id1, id2, id3,..., idn} of different vehicle models idx : {KH id1 , KH id2 , KH id3 ,..., KH idn};

[0021] S102. According to the message frame M with ID idx sent and received by the ECU idx , allocate the corresponding key and store the key in the secure storage area of the ECU, and the M idx includes a data frame;

[0022] S103. Initialize the counter, the counter includes a session counter and a message counter, and specify the maximum value SCTR_MAX of the session counter SCTR idx and the maximum value MCTR_MAX of the message counter MCTR idx ; idx

[0023] S104. Initialize the value of SCTR idx and the minimum value MCTR idx of the message counter to 0. After the vehicle is put into use, SCTR idx starts cyclic counting. idx

[0024] Further, the specific steps for initializing the session key and message authentication code when the vehicle starts are:

[0025] S201. When starting the vehicle, the ECU that sends M idx restores the value of SCTR saved in the secure storage area after the last engine shutdown and automatically adds 1 to get k idx , and the ECU that receives M t starts a new session, initializes the value of MCTR idx to k idx , and obtains the minimum value MCTR r of the message counter during the previous vehicle startup and operation idx _MIN prev; will send M idx The ECU is denoted as TECU idx , and will receive M idx The ECU is denoted as RECU idx ;

[0026] S202. Combined with k t and MCTR idx _MIN prev , k t Substitute k and use formula 1:

[0027]

[0028] Generate TECU idx In k t Session t Precomputed message authentication code for this message in, Based on the key KH idx Generate a function for 128 bits PreMAC, where || represents concatenation;

[0029] S203. Combined with k r and MCTR idx _MIN prev , through formula 2:

[0030]

[0031] Generate RECU idx In k r Session r Pre-calculated message authentication code PreMAC r，k，j ;

[0032] S204. Randomly generate a message counter MCTR during the vehicle startup process idx Minimum count value MCTR_MIN idx , MCTR idx Counting starts from the minimum value:

[0033] S205. Through formula 3:

[0034] Seed = k t ||MCTR idx __IN

[0035] Get the bit string Seed;

[0036] S206. Through formula 4:

[0037]

[0038] Derive the initial session key, i.e., the session key SK of the data frame in the 0th session phase idx，k , where is the key derivation function for deriving a new key based on KH idx ;

[0039] S207. Through Formula 5:

[0040] E_Seed = Encrypt(KE idx , Seed)

[0041] Use the symmetric encryption algorithm Encrypt to encrypt Seed to obtain the encrypted bit string E_Seed;

[0042] S208. Through Formula 6:

[0043] MAC = TRUNC(PreMAC, E Seed )

[0044] Generate i.e., TECU idx the PreMAC after selective truncation t，k，j , where TRUNC() is the function to obtain MAC by selectively truncating 128 bits of PreMAC;

[0045] S209. Pack and E_Seed into the initialization frame M idx+3 and broadcast it to RECU idx ;

[0046] S210. Selectively truncate and generate according to the RECU idx data field content, and check whether it is the same as . If it is the same, it is considered correct and proceed to the next step. If it is different, generate again through k r +1 and perform the check. If the check is successful, synchronize SCTR to the correct value and proceed to the next step. Otherwise, it is considered under attack, an alarm message is sent, and this initialization is terminated, and continue to wait for a legal initialization frame to be received; idx S211. Obtain Seed by decrypting the E_Seed in the data field, calculate the same initial session key SK

[0047] according to Formula 4, update MCTR idx，k _MIN for this vehicle start to make it consistent with that of TECU idx , and MCTR idx starts counting from the minimum value, and ErrCTR idx idx ​Initialize to 0.

[0048] Furthermore, calculate the message authentication code. The specific steps are as follows:

[0049] A01. Place the message authentication code MAC obtained by selectively intercepting PreMAC in the extended ID field of the CAN extended data frame;

[0050] A02. Use the highest 2 bits in the 18 bits of the extended ID field as the identifier, and place the remaining part of the extended ID field with the 16 - bit MAC;

[0051] A03. Perform offline pre - calculation on MAC to obtain 128 - bit PreMAC;

[0052] A04. According to the obtained 128 - bit PreMAC, perform real - time interception calculation on MAC.

[0053] Furthermore, perform offline pre - calculation to obtain 128 - bit PreMAC. Specifically:

[0054]

[0055] where SK idx，k is the session key with session count k.

[0056] Furthermore, the real - time interception calculation. The specific steps are as follows:

[0057] K01. Divide the 128 - bit PreMAC into 16 groups by byte as candidate byte groups: PreMAC[0:15];

[0058] K02. XOR the data part Data idx of the N - byte M idx with the first N bytes of PreMAC as a whole to obtain an N - byte XOR - ed bit string;

[0059] K03. Divide each byte into a pair of candidate byte group indices by 4 bits. The high 4 bits represent index i, and the low 4 bits represent index j3;

[0060] K04. For each byte, obtain two bytes B0 = PreMAC[i] and B1 = PreMAC[j2] from the candidate byte groups, and concatenate them into a 16 - bit bit string B1||B0 as the quasi - MAC MAC′ i where i = 0,..N - 1, and a total of N MAC′s are obtained i ;

[0061] K05. For the obtained N MAC′s iExclusive OR: MAC′0 xor MAC′1 xor... xor MAC′ N-1 , to obtain the final 16 - bits MAC.

[0062] Furthermore, for real - time interception and calculation, the specific steps can also be as follows:

[0063] X01. Divide the pre - calculated 128 - bits PreMAC into 16 groups by bytes as candidate byte groups: PreMAC[0:15]; Divide Data idx into at most 16 groups from low - order bits to high - order bits by 4 bits as the byte index group Data idx [0:15];

[0064] X02. Take i2 as the index of the byte index group and j3 as the index of the candidate byte group. i2 enters a loop starting from 0. According to j3 = Data idx [i2], select the first byte PreMAC[j3] from the candidate byte group, and i2 = i2 + 1; Then judge whether Data idx [i2] is equal to j3. If they are equal, then i2 = i2 + 1 and enter the next judgment loop until Data idx [i2] and j3 are not equal, and j3 = Data idx [i2];

[0065] X03. If it is found that each byte index is the same after traversing Data idx [0:15], then j3=(j3 + 1) mod 16, finally select the second byte PreMAC[j3], and concatenate the two bytes to obtain MAC.

[0066] Furthermore, in step S4, to verify the session message, specifically: RECU idx receives M idx sent by TECU idx , then checks the extended ID segment identifier of M idx , executes the corresponding message authentication code algorithm according to the identifier, and conducts verification:

[0067] B01. Conduct the first verification. If the verification is successful, then receive M idx , and decrement ErrCTR idx by 1. If ErrCTR idx is 0, then keep it as 0. If the verification fails, then enter the next step;

[0068] B02. Conduct the second verification. RECU idx calculates the message authentication code corresponding to j r +1 and conducts verification. If the verification is successful, then receive Midx and synchronize ErrCTR idx , and update the counter. If the verification fails, proceed to the next step;

[0069] B03. Conduct the third verification, RECU idx Attempt to calculate j r +2 and verify the corresponding message authentication code. If the verification is successful, receive M idx and synchronize ErrCTR idx , and update the counter. If the verification fails, discard M idx , do not synchronize the counter, do not perform subsequent counter updates, send an alarm message, and increment ErrCTR idx by 2.

[0070] Furthermore, update the session key, specifically:

[0071] C01. TECU idx After each MAC calculation and RECU idx After each MAC verification, if the value of MCTR idx is not the maximum value it can represent, MCTR idx increases normally. Otherwise, it indicates the end of the current session, and TECU idx and RECU idx reset MCTR idx to MCTR_MIN idx , and increment the session count k of SCTR idx by 1;

[0072] C02. The original session key SK idx，k-1 and k are passed through the key derivation function:

[0073]

[0074] to generate a new session key SK idx，k .

[0075] Furthermore, synchronize the counter according to the result of verifying the session message, specifically:

[0076] D01. If RECU idx fails in multiple message verifications and the value of ErrCTR idx accumulates to more than 10, send a synchronization request frame M idx+1 whose format is the same as the extended data frame, and the identifier in the extended ID segment is 01;

[0077] D02. Use the value k idx of SCTR r as the high 32 bits, and the value j idx of MCTRr For the lower 32 bits, they are combined into a 64-bit bit string. After encryption, a 64-bit ciphertext is obtained and placed in the data field Data idx+1 and sent to the CAN bus;

[0078] D03.TECU idx After receiving M idx+1 , first decrypt Data idx to obtain k r and j r , and compare them with its own SCTR idx value k t and MCTR idx value j t : If k r > k t , it is regarded as being attacked by a malicious node, and an alarm message is sent. Otherwise, judge whether j r meets MCTR_MIN idx ≤ j r ≤ MCTR_MAX idx . If not, it is regarded as being attacked by a malicious node, and an alarm message is sent. If it meets the condition, TECU idx then sends a synchronous response frame M idx+2 , and the identifier in the extended ID segment is 02; k t is used as the upper 32 bits, and j t is the lower 32 bits. They are combined into a 64-bit bit string. After encryption, a 64-bit ciphertext is obtained and placed in the data field Data idx+2 ;

[0079] D04. Use KH idx and k r || j r to generate MAC trunc and send it to the bus;

[0080] D05.RECU idx After receiving the synchronous response frame M idx+2 , first decrypt Data idx+2 , and check whether it meets k t || j t ≥ k r || j r . If not, it means being attacked. If it meets the condition, use KH idx and k r || j r to verify MAC. If k r > k t then update its own SCTR idx and MCTR idx , if kr <k t Then update the session key and complete the counter synchronization.

[0081] The beneficial effects of the present invention are as follows:

[0082] By initializing the counter and the long-term valid key of the electronic control unit when the vehicle leaves the factory according to the CAN bus of different vehicle models, initializing the session key and the message authentication code when the vehicle starts, calculating the message authentication code during the communication of the ECU, verifying the session message, updating the session key, and synchronizing the counter according to the result of verifying the session message, the present invention solves the problem that the in-vehicle CAN bus in the prior art lacks a secure and efficient authentication mechanism, and has the characteristics of resisting forgery and replay attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0083] Figure 1 It is a schematic diagram of a CAN standard data frame.

[0084] Figure 2 It is a schematic diagram of a CAN extended data frame.

[0085] Figure 3 It is a schematic diagram of the in-vehicle CAN bus topology.

[0086] Figure 4 It is a schematic diagram of the process of the lightweight message verification method for the in-vehicle CAN bus of the present vehicle.

[0087] Figure 5 It is a schematic diagram of the MAC placed in the extended ID segment when calculating the message authentication code. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0088] The present invention will be described in detail below with reference to the drawings and specific embodiments.

[0089] The explanations of the professional terms that may be involved in this embodiment are as follows:

[0090] M idx : The message frame with the ID of idx;

[0091] Data idx : The data part of M idx ;

[0092] TECU idx : The ECU that sends M idx ;

[0093] RECU idx : The ECU that receives M idx ;

[0094] SCTR idx : Count M idxThe session counter at the kth session stage, length 32 bits;

[0095] MCTR idx : Counts the M sent or received during this session idx (marked as normal data) times

[0096] j's message counter, length 32 bits;

[0097] k t , k r :Represents TECU idx With RECU idx SCTR idx The value of

[0098] j t , j r :Represents TECU idx With RECU idx MCTR idx The value of

[0099] SCTR_MAX idx :SCTR idx The maximum value of count;

[0100] MCTR_MIN idx : MCTR during the vehicle startup process idx The minimum value of the count;

[0101] MCTR_MAX idx : MCTR during the vehicle startup process idx The maximum value of count;

[0102] ErrCTR idx :RECU idx Count message verification exception M idx Error counter of the number of times;

[0103] KH idx :M idx The corresponding long-term key used to derive the HMAC key;

[0104] KE idx :M idx The corresponding long-term symmetric key used to encrypt and decrypt synchronization data;

[0105] SK idx，k :M idx The session key at the kth session stage;

[0106] HKDF key (): Based on KHidx A key derivation function that derives a new key from the key;

[0107] HMAC key (): A function that generates a 128-bit PreMAC based on KH idx of the key;

[0108] TRUNC(): A function that selects and intercepts 128-bit PreMAC to obtain MAC;

[0109] PreMAC t，k，j : TECU idx at k t th session j t th message's precomputed message authentication code;

[0110] PreMAC r，k，j : RECU idx at k r th session j r th message's precomputed message authentication code;

[0111] MAC t，k，j : TECU idx PreMAC after selective interception; t，k，j .

[0112] MAC r，k，j : RECU idx PreMAC after selective interception; r，k，j .

[0113] Embodiment 1

[0114] As Figure 4 shown, a method for lightweight message verification of an in-vehicle CAN bus includes the following steps:

[0115] S1. According to the CAN bus of different vehicle models, initialize the counter and long-term valid key of the electronic control unit when the vehicle leaves the factory, and represent the electronic control unit as ECU;

[0116] S2. Initialize the session key and message authentication code when the vehicle starts;

[0117] S3. When the ECU communicates, calculate the message authentication code, verify the session message, update the session key, and synchronize the counter according to the result of verifying the session message.

[0118] Embodiment 2

[0119] As Figure 4 shown, a method for lightweight message verification of an in-vehicle CAN bus includes the following steps:

[0120] S1. Initialize the counter and the long-term valid key of the electronic control unit of the vehicle at the factory according to the CAN bus of different vehicle models, and represent the electronic control unit as ECU;

[0121] S2. Initialize the session key and the message authentication code when the vehicle starts;

[0122] S3. When the ECU communicates, calculate the message authentication code, verify the session message, update the session key, and synchronize the counter according to the result of verifying the session message.

[0123] In a specific embodiment, step S1 is specifically:

[0124] S101. In the vehicle manufacturing stage, the vehicle manufacturer generates the long-term valid key KH corresponding to each message according to the CAN bus message ID set {id1, id2, id3,..., idn} of different vehicle models idx : {KH id1 , KH id2 , KH id3 ,..., KH idn}; In this embodiment, the vehicle manufacturer also generates the long-term valid symmetric key {KE id1 , KE id2 , KE id3 ,..., KE idn} corresponding to each message for encrypting and decrypting synchronization data according to different vehicle models.

[0125] In this embodiment, the ECU maintains the session counter SCTR idx and the message counter MCTR idx for the M idx it sends or receives.

[0126] S102. According to the message frame M idx with the ID of idx sent and received by the ECU, allocate the corresponding KH idx , and store KH idx in the secure storage area of the ECU, and the M idx includes data frames, remote frames, error frames, and overload frames;

[0127] S103. Initialize the counter, where the counter includes a session counter and a message counter, and specify the maximum value SCTR_MAX idx of the session counter SCTR idx and the maximum value MCTR_MAX of the message counter MCTR idx ;

[0128] S104. Initialize the value of SCTR idx and MCTRidx Minimum Count of MCTR idx _MIN is 0. After the vehicle is put into use, SCTR idx starts cyclic counting.

[0129] In a specific embodiment, the session key and message authentication code at vehicle startup are initialized. The specific steps are as follows:

[0130] S201. When starting the vehicle, send M idx The ECU restores the value of SCTR saved in the secure storage area after the last engine shutdown and automatically adds 1 to obtain k idx , the ECU that receives M t starts a new session, initializes the value of MCTR idx k idx , and obtains the minimum value of the message counter MCTR r during the previous vehicle startup and operation process idx _MIN prev ; Denote the ECU that sends M idx as TECU idx , and denote the ECU that receives M idx as RECU idx ;

[0131] S202. Combine k t and MCTR idx _MIN prev , substitute k t into k, and through formula 1:

[0132]

[0133] Generate the pre-computed message authentication code idx of TECU t in the j t -th message of the k th session where idx is a function that generates 128 bits of PreMAC based on the key KH, and || represents concatenation;

[0134] S203. Combine k r and MCTR idx _MIN prev , and through formula 2:

[0135]

[0136] Generate the pre-computed message authentication code PreMAC idx of RECU r in the j r -th message of the kr，k，j ;

[0137] S204. Randomly generate the message counter MCTR during the vehicle startup and operation process idx The minimum value MCTR_MIN of the count idx , MCTR idx Start counting from the minimum value:

[0138] S205. Through formula 3:

[0139] Seed = k t ||MCTR idx _MIN

[0140] Obtain the bit string Seed;

[0141] S206. Through formula 4:

[0142]

[0143] Derive the initial session key, that is, the session key SK of the data frame in the 0th session stage idx，k , where is the key derivation function for deriving a new key based on KH idx ;

[0144] S207. Through formula 5:

[0145] E_Seed = Encrypt(KE idx , Seed)

[0146] Encrypt Seed with the symmetric encryption algorithm Encrypt to obtain the encrypted bit string E_Seed;

[0147] S208. Through formula 6:

[0148] MAC = TRUNC(PreMAC, E Seed )

[0149] Generate that is, the PreMAC after being selectively intercepted by TECU idx , where TRUNC() is a function to obtain MAC by selectively intercepting 128 bits of PreMAC; t，k，j ;

[0150] S209. Package and E_Seed into the initialization frame Midx + 3 and broadcast it to RECU idx ;

[0151] S210. Selectively intercept and generate according to the RECU idx data field content Verify whether it is the same as If they are the same, it is considered that is correct and proceed to the next step. If they are different, regenerate through k r +1 and then perform verification. If the verification is successful, synchronize SCTR idx to the correct value and proceed to the next step. Otherwise, it is considered an attack, send an alarm message, terminate this initialization, and continue to wait for a legal initialization frame;

[0152] S211. Obtain Seed by decrypting the E_Seed in the data field, and calculate the same initial session key SK according to Formula 4 idx，k , update MCTR idx _MIN for this vehicle startup to make it consistent with that of TECU idx . MCTR idx starts counting from the minimum value, and ErrCTR idx is initialized to 0.

[0153] As Figure 5 shown, in a specific embodiment, to ensure that the message frame is sent by the legitimate ECU, the owner of the session key, a message authentication code mechanism needs to be introduced; to resist replay attacks, the calculation of PreMAC needs to combine the session counter and the message counter to ensure that the MAC can only be successfully verified once. The specific steps for calculating the message authentication code are as follows:

[0154] A01. To avoid adding additional communication load, place the message authentication code MAC obtained by selectively intercepting PreMAC in the extended ID segment of the CAN extended data frame;

[0155] A02. The highest 2 bits in the 18 bits of the extended ID segment are used as identifiers, and the remaining part of the extended ID segment is placed with the 16-bit MAC; in this embodiment, the highest 2 bits also participate in the CAN bus arbitration, where 00 represents a normal data frame, 01 represents a synchronization request frame, 10 represents a synchronization response frame, and 11 represents an initialization frame, which are equivalent to idx, idx + 1, idx + 2, idx + 3 respectively;

[0156] A03. Considering the limited computing power of the ECU and the requirement of low message transmission latency for critical security ECUs, the calculation of the MAC is divided into two steps. First, perform offline pre-calculation with heavy computing power burden on the MAC to obtain 128-bit PreMAC;

[0157] A04. According to the obtained 128-bit PreMAC, perform real-time interception calculation on the MAC.

[0158] Furthermore, perform offline pre - calculation to obtain 128 - bit PreMAC, specifically as follows:

[0159]

[0160] Among them, SK idx，k is the session key with session count k. In this embodiment, M idx 's data part Data idx does not participate in the offline pre - calculation. This step of calculation is only performed by SCTR idx , MCTR idx and SK idx，k to generate 128 - bit MAC through . Because the SCTR idx and MCTR idx corresponding to each ECU related to M idx are the same and can correctly maintain the count value, the offline pre - calculation method proposed by the present invention can ensure the reliability of message verification. Moreover, the ECU can pre - calculate the MAC for 4 counting cycles in advance.

[0161] In a specific embodiment, perform real - time intercept calculation, and the specific steps are as follows:

[0162] K01. Divide the 128 - bit PreMAC into 16 groups by byte as candidate byte groups: PreMAC[0:15];

[0163] K02. XOR the entire data part Data idx of N - byte M idx with the first N bytes of PreMAC to obtain an N - byte XOR - ed bit string;

[0164] K03. Divide each byte into a pair of candidate byte group indices by 4 bits. The high 4 bits represent index i, and the low 4 bits represent index j3;

[0165] K04. Obtain two bytes B0 = PreMAC[i] and B1 = PreMAC[j2] from the candidate byte groups for each byte, and splice them into a 16 - bit bit string B1||B0 as the quasi - MAC MAC′ i , where i = 0,..N - 1, and a total of N MAC′ i are obtained;

[0166] K05. XOR the obtained N MAC′ i with each other: MAC′0 xor MAC′1 xor... xor MAC′ N-1 to obtain the final 16 - bit MAC.

[0167] In this embodiment, for real-time intercept calculation, the specific steps may also be as follows:

[0168] X01. Divide the pre-calculated 128-bit PreMAC into 16 groups by byte as candidate byte groups: PreMAC[0:15]; Divide Data idx into at most 16 groups from low bit to high bit by 4 bits as byte index groups Data idx [0:15];

[0169] X02. Use i2 as the index of the byte index group and j3 as the index of the candidate byte group. i2 enters a loop starting from 0. According to j3 = Data idx [i2], select the first byte PreMAC[j3] from the candidate byte group, and i2 = i2 + 1; Then judge whether Data idx [i2] is equal to j3. If they are equal, then i2 = i2 + 1 and enter the next judgment loop until Data idx [i2] is not equal to j3, and j3 = Data idx [i2];

[0170] X03. If it is found that each byte index is the same after traversing Data idx [0:15], then j3 = (j3 + 1) mod 16, and finally select the second byte PreMAC[j3], and concatenate the two bytes to obtain MAC.

[0171] In this embodiment, the algorithm is specifically as follows:

[0172] TRUNC():

[0173] Input: (1) Candidate byte groups PreMAC[0:15] obtained by dividing 128-bit PreMAC into 16 groups by byte

[0174] (2) 〖Data〗_idx is divided into 2N groups from low bit to high bit by 4 bits according to its length of N bytes as byte index groups 〖Data〗_idx[0:2N]

[0175] Output: MAC

[0176] Local variables: Index i2 of the byte index group, index j3 of the candidate byte group, first byte B1, second byte B2

[0177] XP01: i2 = 0

[0178] XP02: j3 = 〖Data〗_idx[i2]

[0179] XP03: B1 = PreMAC[j3]

[0180] XP04: i2 = i2 + 1

[0181] XP05: while i2 <= Max then

[0182] XP06: if〖Data〗_idx[i] != j3 then

[0183] XP07: break

[0184] XP08: else

[0185] XP09: i2 = i2 + 1

[0186] XP10: end if

[0187] XP11: end while

[0188] XP12: if i2 > Max then

[0189] XP13: j3 = (j3 + 1) mod 16

[0190] 14: else

[0191] 15: j3 =〖Data〗_idx[i2]

[0192] 16: end if

[0193] 17: B2 = PreMAC[j3]

[0194] 18: MAC = B2 || B1.

[0195] Example 3

[0196] As Figure 4 shown, a method for lightweight message verification of the in-vehicle CAN bus includes the following steps:

[0197] S1. According to the CAN bus of different vehicle models, initialize the counter and the long-term valid key of the electronic control unit when the vehicle leaves the factory, and represent the electronic control unit as ECU;

[0198] S2. Initialize the session key and the message authentication code when the vehicle starts;

[0199] S3. When the ECU communicates, calculate the message authentication code, verify the session message, update the session key, and synchronize the counter according to the result of verifying the session message.

[0200] In a specific embodiment, step S1 is specifically:

[0201] S101. Generate a long-term valid key KH for each message according to the CAN bus message ID set {id1, id2, id3,..., idn} of different vehicle models idx : {KH id1 , KH id2 , KH id3 ,..., KH idn};

[0202] S102. According to the message frame M with ID idx sent and received by the ECU idx , allocate the corresponding KH idx , and store KH idx in the secure storage area of the ECU. The M idx includes data frames, remote frames, error frames, and overload frames;

[0203] S103. Initialize the counter. The counter includes a session counter and a message counter, and specify the maximum value SCTR_MAX idx of the session counter SCTR idx and the maximum value MCTR_MAX idx of the message counter MCTR;

[0204] S104. Initialize the value of SCTR idx and the minimum value MCTR idx of the message counter to 0. After the vehicle is put into use, SCTR idx _MIN is 0, and SCTR idx starts cyclic counting.

[0205] In a specific embodiment, initialize the session key and message authentication code when the vehicle starts. The specific steps are as follows:

[0206] S201. When starting the vehicle, the ECU that sends M idx restores the value of SCTR idx saved in the secure storage area after the last engine shutdown and automatically adds 1 to get k t . The ECU that receives M idx starts a new session, initializes the value of MCTR idx to k r , and obtains the minimum value MCTR idx _MIN prev of the message counter during the previous vehicle startup and operation; Denote the ECU that sends M idx as TECU idx , and denote the ECU that receives M idx as RECU idx ;

[0207] S202. Combine k t and MCTR idx _MIN prev to substitute k t into k, and generate TECU through Formula 1:

[0208]

[0209] Generate TECU idx For the pre - computed message authentication code of the t k - th session j t and the k - th message where is a function that generates 128 - bit PreMAC based on the key KHidx, and || represents concatenation;

[0210] S203. Combine k r and MCTR idx _MIN prev to generate RECU through Formula 2:

[0211]

[0212] Generate RECU idx For the pre - computed message authentication code PreMAC of the r k - th session j r and the k - th message r，k，j ;

[0213] S204. Randomly generate the minimum value MCTR_MIN of the message counter MCTR idx during the current vehicle startup and operation process, and MCTR idx starts counting from the minimum value: idx

[0214] S205. Through Formula 3:

[0215] Seed = k t ||MCTR idx _MIN

[0216] Obtain the bit string Seed;

[0217] S206. Through Formula 4:

[0218]

[0219] Derive the initial session key, that is, the session key SK of the data frame in the 0 - th session stage idx，k where is the key derivation function for deriving a new key based on KH idx ;

[0220] S207. Through Formula 5:

[0221] E_Seed = Encrypt(KE idx , Seed)

[0222] Use the symmetric encryption algorithm Encrypt to encrypt Seed to obtain the encrypted bit string E_Seed;

[0223] S208. Through Formula 6:

[0224] MAC = TRUNC(PreMAC, E Seed )

[0225] Generate That is, TECU idx PreMAC after selective truncation t，k，j , where TRUNC() is a function to select and truncate 128 bits of PreMAC to obtain MAC;

[0226] S209. Pack and E_Seed into the initialization frame Midx+3 and broadcast it to RECU idx ;

[0227] S210. Selectively truncate and generate according to the content of the data field of RECU idx , check whether it is the same as , if it is the same, it is considered correct, and proceed to the next step. If it is different, regenerate through k r +1 and perform the check. If the check is successful, synchronize SCTR to the correct value and proceed to the next step. Otherwise, it is regarded as under attack, an alarm message is sent, and this initialization is terminated, and continue to wait for a legal initialization frame; idx idx，k

[0228] S211. Obtain Seed by decrypting the E_Seed in the data field, calculate the same initial session key SK according to Formula 4 idx，k , update MCTR idx _MIN for this vehicle startup to make it consistent with TECU idx . MCTR idx starts counting from the minimum value, and ErrCTR idx is initialized to 0.

[0229] As Figure 5 shown, in a specific embodiment, calculating the message authentication code, the specific steps are:

[0230] A01. Place the message authentication code MAC obtained by selectively intercepting PreMAC in the extended ID field of the CAN extended data frame;

[0231] A02. Use the highest 2 bits in the 18 bits of the extended ID field as identifiers, and place the remaining part of the extended ID field with the 16-bit MAC;

[0232] A03. Perform offline pre-computation on the MAC to obtain 128-bit PreMAC;

[0233] A04. Perform real-time interception calculation on the MAC based on the obtained 128-bit PreMAC.

[0234] Furthermore, perform offline pre-computation to obtain 128-bit PreMAC, specifically:

[0235]

[0236] Where SK idx，k is the session key with session count k.

[0237] In a specific embodiment, the steps of real-time interception calculation are as follows:

[0238] K01. Divide the 128-bit PreMAC into 16 groups by byte as candidate byte groups: PreMAC[0:15];

[0239] K02. XOR the entire data part Data idx of N bytes of M idx with the first N bytes of PreMAC to obtain an N-byte XORed bit string;

[0240] K03. Divide each byte into a pair of candidate byte group indices by 4 bits, where the high 4 bits represent index i and the low 4 bits represent index j3;

[0241] K04. Obtain two bytes B0 = PreMAC[i] and B1 = PreMAC[j2] from the candidate byte groups for each byte, and concatenate them into a 16-bit bit string B1||B0 as the quasi-MAC MAC′ i , i = 0,..N-1, and a total of N MAC′s are obtained i ;

[0242] K05. XOR the obtained N MAC′s i with each other: MAC′0 xor MAC′1 xor... xor MAC′ N-1 , to obtain the final 16-bit MAC.

[0243] In a specific embodiment, for real-time intercept calculation, the specific steps may further be:

[0244] X01. Divide the pre-computed 128-bit PreMAC into 16 groups by byte as candidate byte groups: PreMAC[0:15]; Divide Data idx into at most 16 groups from low to high by 4 bits as byte index groups Data idx [0:15];

[0245] X02. Use i2 as the index of the byte index group and j3 as the index of the candidate byte group. i2 enters a loop starting from 0. According to j3 = Data idx [i2], select the first byte PreMAC[j3] from the candidate byte group, and i2 = i2 + 1; Then judge whether Data idx [i2] is equal to j3. If they are equal, then i2 = i2 + 1 and enter the next judgment loop until Data idx [i2] is not equal to j3, and j3 = Data idx [i2];

[0246] X03. If it is found that each byte index is the same after traversing Data idx [0:15], then j3 = (j3 + 1) mod 16. Finally, select the second byte PreMAC[j3] and concatenate the two bytes to obtain the MAC.

[0247] In a specific embodiment, in step S4, to verify the session message, specifically: RECU idx After receiving M idx sent by TECU idx , check the extended ID segment identifier of M idx , execute the corresponding message authentication code algorithm according to the identifier and perform verification:

[0248] B01. Conduct the first verification. If the verification is successful, then receive M idx , and subtract 1 from ErrCTR idx . If ErrCTR idx is 0, then keep it as 0. If the verification fails, then proceed to the next step;

[0249] B02. Conduct the second verification. RECU idx Calculate the message authentication code corresponding to j r +1 and verify it. If the verification is successful, then receive M idx and synchronize ErrCTR idx , and update the counter. If the verification fails, then proceed to the next step;

[0250] Perform the third verification, RECU idx Attempt to calculate j r Calculate the message authentication code corresponding to +2 and verify it. If the verification is successful, receive M idx and synchronize the correct value of the counter ErrCTR idx and update the counter. If the verification fails, discard M idx , do not synchronize the counter, do not perform subsequent counter updates, send an alarm message, and set ErrCTR idx plus 2.

[0251] In a specific embodiment, update the session key, specifically:

[0252] C01.TECU idx After each MAC calculation and RECU idx After each MAC verification, it is necessary to update MCTR idx , if MCTR idx value is not the maximum value it can represent, MCTR idx value increases normally, otherwise it indicates the end of the current session, TECU idx and RECU idx reset MCTR idx to MCTR_MIN idx , and increment the session count k of SCTR idx by 1;

[0253] C02.Original session key SK idx，k-1 and k through the key derivation function:

[0254]

[0255] Generate a new session key SK idx，k .

[0256] In a specific embodiment, generate a new session key through the key derivation function. The specific algorithm logic is:

[0257] Input: Long-term valid key KH idx , message counter MCTR idx value j, session counter SCTR idx value k, counter original session key SK idx，k-1

[0258] Output: New session key SK idx，k

[0259] P1.if j == MCTR_MAX idx then

[0260] P2. If k == SCTR_MAX idx then

[0261] P3. k = 0

[0262] P4. Else

[0263] P5. k = k + 1

[0264] P6. end if

[0265] P7. j = MCTR_MIN idx

[0266] P8.

[0267] P9. Else

[0268] P10. j = j + 1

[0269] P11. end if。

[0270] In a specific embodiment, due to situations such as the ECU going into sleep mode or the CAN bus losing data frames due to interference, the error counter values of TECU idx and RECU idx are out of sync, resulting in message verification failure. Therefore, the present invention introduces an error counter synchronization mechanism; synchronize the counters according to the result of verifying the session message, specifically:

[0271] D01. If RECU idx fails to verify multiple messages and the value of ErrCTR idx accumulates to more than 10, then send a synchronization request frame M idx+1 , whose format is the same as the extended data frame, and the identifier in the extended ID segment is 01;

[0272] D02. Use the value k idx of SCTR r as the high 32 bits, and the value j idx of MCTR r as the low 32 bits, combine them into a 64-bit bit string, encrypt it to obtain a 64-bit ciphertext, and place it in the data field Data idx+1 and send it to the CAN bus;

[0273] D03. After TECU idx receives M idx+1 , first decrypt Data idx to obtain k r and j r , and compare with the value k of its own SCTR idx ​t and MCTR idx value j t Compare: If k r > k t , it is regarded as encountering a malicious node attack and an alarm message is sent. Otherwise, judge whether j r satisfies MCTR_MIN idx ≤ j r ≤ MCTR_MAX idx . If not satisfied, it is regarded as encountering a malicious node attack and an alarm message is sent. If satisfied, TECU idx then sends a synchronization response frame M idx+2 , and the identifier in the extended ID segment is 02; k t is used as the high 32 bits, and j t is the low 32 bits, combined into a 64-bit bit string, encrypted to obtain a 64-bit ciphertext and placed in the data field Data idx+2 ;

[0274] D04. Use KH idx and k r || j r to generate MAC trunc and send it to the bus;

[0275] D05. RECU idx After receiving the synchronization response frame M idx+2 , first decrypt Data idx+2 , check whether it satisfies k t || j t ≥ k r || j r . If not satisfied, it means an attack has occurred. If satisfied, use KH idx and k r || j r to verify the MAC. If k r > k t then update its own SCTR idx and MCTR idx . If k r < k t then update the session key and complete the counter synchronization.

[0276] The present invention initializes the counter and the long-term valid key of the electronic control unit of the vehicle at the time of factory production according to the CAN bus of different vehicle models, initializes the session key and the message authentication code at the time of vehicle startup, calculates the message authentication code when the ECU communicates, verifies the session message, updates the session key, and synchronizes the counter according to the result of verifying the session message, solves the problem that the in-vehicle CAN bus in the prior art lacks a secure and efficient authentication mechanism, and has the characteristics of low calculation latency, low communication load, high compatibility, and resistance to forgery and replay attacks.

[0277] Obviously, the above embodiments of the present invention are merely examples for clearly explaining the present invention, and are not limitations on the implementation manners of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the claims of the present invention.

Claims

1. A method for lightweight message verification of the in-vehicle CAN bus, characterized in that: Including the following steps: S1. Initialize the counter and the long-term valid key of the electronic control unit (ECU) when the vehicle leaves the factory according to the CAN bus of different vehicle models, and represent the electronic control unit as ECU; S2. When the vehicle starts, initialize the session key and the message authentication code; The specific steps for initializing the session key and the message authentication code when the vehicle starts are as follows: S201. When starting the vehicle, send a message frame with ID idx The ECU restores the session counter saved in the secure storage area after the last engine shutdown Add 1 to the value obtained to get The ECU that receives starts a new session and initializes the message counter with the value and obtains the minimum value of the message counter during the last vehicle startup and operation ; Denote the ECU that sends as and denote the ECU that receives as S202. And , substitute into , through Formula 1: Generate In The Pre - calculated message authentication code for the th session th message, where Is a function that generates 128 bits based on the key And Denotes concatenation; S203. And , substitute into , through Formula 2: Generate ; S204. Randomly generate a message counter during the current vehicle startup and operation process The minimum value of counting Start counting from the minimum value: S205. Through formula 3: Obtain the bit string ; S206. Through formula 4: Derive the initial session key, i.e., the session key of the data frame in the 0th session phase , where is a key derivation function for deriving a new key based on ​ S207. Through formula 5: Using a symmetric encryption algorithm to perform encryption to obtain an encrypted bit string ; S208. Through formula 6: Generate After selective truncation , where Is to selectively truncate 128 bits Obtained Function; S209. Pack and into an initialization frame and broadcast it to ; S210. According to formula 6 Data field content selection, interception and generation , check whether it is consistent with If the same, then it is considered If it is correct, proceed to the next step. If it is different, pass Regenerate And verify, if the verification is successful, If the value is synchronized to the correct value, proceed to the next step. Otherwise, it is considered to be an attack, an alarm message is issued, and the initialization is terminated. The system continues to wait for receiving a legal initialization frame. S211. By decrypting the data field to obtain , calculate the same initial session key according to Formula 4 , update the for this vehicle start, to make it consistent with Start counting from the minimum value, Initialize it to 0; S3. When the ECU communicates, calculate the message authentication code, verify the session message, update the session key, and synchronize the counter according to the result of verifying the session message.

2. The vehicle internal CAN bus lightweight message verification method according to claim 1, characterized in that: Step S1 is specifically: S101. Generate a long-term valid key for each message according to the CAN bus message ID set of different vehicle models , ; S102. According to the message frame with ID idx sent and received by the ECU , allocate the corresponding , and store in the secure storage area of the ECU. The includes a data frame; S103. Initialize the counters, where the counters include a session counter and a message counter, and specify the maximum value of the session counter and the maximum value of the message counter ; ; ; S104. Initialize The value of and the minimum value of the count are set to 0. After the vehicle is put into use, start the loop counting.

3. The vehicle internal CAN bus lightweight message verification method according to claim 2, characterized in that: The specific steps for calculating the message authentication code are: A01. Place the message authentication code obtained after selective truncation in the extended ID field of the CAN extended data frame; Use the highest 2 bits in the 18 bits of the extended ID segment as the identifier, and place the remaining part of the extended ID segment in 16 bits of ; A03. Perform offline pre-computation on the MAC to obtain 128 bits ; A04. According to the obtained 128 bits , perform real-time interception calculation on the MAC.

4. The method for verifying lightweight messages of the in-vehicle CAN bus according to claim 3, wherein: Offline pre-computation to obtain 128 bits , specifically as follows: where is the session key for which the session count is k.

5. The vehicle internal CAN bus lightweight message verification method according to claim 3, wherein: The specific steps for real-time intercept calculation are: K01. Divide 128 bits into 16 groups by byte as candidate byte groups: ; K02. XOR the N-byte data part as a whole with the first N bytes of to obtain an N-byte bit string after XOR; K03. Divide each byte of it into a pair of candidate byte group indices by 4 bits. The high 4 bits represent index i, and the low 4 bits represent the index ; K04. Each byte obtains two bytes from the candidate byte group , , and splices them into a 16-bit bit string B1||B0 as the quasi , , and a total of N are obtained ; K05. The obtained N are mutually exclusive ORed: , obtain the final 16 bits .

6. The method for verifying lightweight messages of the in-vehicle CAN bus according to claim 3, wherein: The specific steps for real-time intercept calculation can also be: X01. Divide the pre-computed 128 bits into 16 groups by bytes as candidate byte groups: ; Divide into at most 16 groups from the low bit to the high bit by 4 bits as byte index groups [0:15]; X02. Use as the index of the byte index group, is the index of the candidate byte group, Start a loop from 0. According to = , select the first byte from the candidate byte group , = + 1; Then judge whether is equal to . If they are equal, then = + 1, enter the next judgment loop until and are not equal, = ;​​​​ X03. If, after traversing [0:15] it is found that each byte index is the same, then j3 = (j3 + 1) mod 16, and finally the second byte is selected , and the two bytes are concatenated to obtain .

7. The method for verifying lightweight messages of the in-vehicle CAN bus according to claim 2, wherein: In step S3, verify the session message, specifically: Received Sent After that, check The extended ID segment identifier, execute the corresponding message authentication code algorithm according to the identifier, and perform verification: Perform the first verification. If the verification is successful, receive , and subtract 1 from . If is 0, keep it as 0. If the verification fails, proceed to the next step; Perform the second verification, Calculate the corresponding message authentication code and verify it. If the verification is successful, receive and synchronize , and update the counter. If the verification fails, proceed to the next step; Perform the third verification, Attempt to calculate the corresponding message authentication code and verify it. If the verification is successful, receive and synchronize the correct value of the counter and update the counter. If the verification fails, discard , do not synchronize the counter, do not perform subsequent counter updates, issue an alarm message, and increment by 2.

8. The vehicle internal CAN bus lightweight message verification method according to claim 3, characterized in that: The specific steps for updating the session key are: C01. After each calculation and after each verification if the value is not the maximum value it can represent, the value is incremented normally, otherwise it indicates the end of the current session, and reset to and increment the session count k of by 1; C02. Original session key and k through a key derivation function: Generate a new session key .

9. The method for validating lightweight messages of the in-vehicle CAN bus according to claim 7, wherein: Synchronize the counter according to the result of verifying the session message, specifically: If the multiple message verification fails and the value accumulates to more than 10, a synchronization request frame will be sent, whose format is the same as that of the extended data frame, and the identifier in the extended ID segment is 01; D02. Take the value of as the high 32 bits, the value of as the low 32 bits, combine them into a 64-bit bit string, and after encryption, obtain a 64-bit ciphertext and place it in the data field and send it to the CAN bus; D03. After receiving , first decrypt to obtain and , and compare them with the values and of its own value : If > , it is regarded as being attacked by a malicious node, and an alarm message is sent. Otherwise, judge whether meets . If it does not meet, it is regarded as being attacked by a malicious node, and an alarm message is sent. If it meets, then send a synchronization response frame , and the identifier in the extended ID segment is 02; is used as the high 32 bits, is the low 32 bits, combined into a 64-bit bit string, encrypted to obtain a 64-bit ciphertext and placed in the data field ; D04. Usage and || generate Send to the bus; D05. After receiving the synchronization response frame , first decrypt it , and check whether it meets . If it does not meet, it means an attack has occurred. If it meets, use and to verify . If , then update its own and . If , then update the session key and complete the counter synchronization.

Images