In-vehicle CAN bus safety communication method and device based on symmetric key negotiation

Abstract

The invention relates to the technical field of Internet of Vehicles network security communication, in particular to an in-vehicle CAN bus security communication method and device based on symmetric key negotiation, and the method comprises the steps: enabling a CAN bus to be connected with each controller and a T-BOX end, so as to fill the same symmetric group key ciphertext and a protection key index number; taking a corresponding first protection key in the T-BOX end through the protection key index number, and decrypting the symmetric group key ciphertext by using the first protection key; symmetrically encrypting the vehicle data by using the obtained first symmetric group key plaintext, and broadcasting the protected vehicle data to each controller; taking a corresponding second protection key in each controller through the protection key index number, and decrypting the symmetric group key ciphertext by using the second protection key; and decrypting the protected vehicle data by using the obtained second symmetric group key plaintext to obtain a vehicle data plaintext. Therefore, the problem that an existing CAN bus connection method is poor in safety and the like is solved.

Description

Technical Field

[0001] This application relates to the field of vehicle network security communication technology, and in particular to a secure communication method and device for in-vehicle CAN bus based on symmetric key negotiation using a key management system. Background Technology

[0002] The in-vehicle CAN bus is used for communication and data exchange between different electronic control units within a vehicle. It connects various control systems within the vehicle, employing a broadcast mechanism for communication. Each connected component can send and receive control messages, resulting in high communication efficiency. Currently, most cars on the market have at least one CAN network, serving as the backbone network for interconnecting embedded systems and facilitating the exchange and sharing of in-vehicle information.

[0003] CAN bus: Controller Area Network (CAN) bus is a serial communication protocol bus used for communication between various components in a vehicle. It consists of multiple components working together, including the CAN controller, CAN transceiver, data transmission lines, and data transmission terminals.

[0004] MCU: Vehicle MCU, or microcontroller. The T-BOX vehicle terminal MCU module establishes communication with the vehicle through CAN bus technology, collects CAN messages from the vehicle controller to the MCU, and then the MCU parses, assembles, and distributes the collected messages to the MPU module.

[0005] MPU: It can integrate an in-vehicle communication module. The MPU module mainly performs functions such as GPS positioning and wireless communication. After the collected GPS information and the vehicle information sent by the MCU are packaged according to the protocol, the data is sent to the TSP vehicle networking platform through wireless communication using technologies such as data encoding, data encryption, and data compression. The TSP platform decrypts and processes the collected vehicle information.

[0006] Automotive controllers: These integrate relevant functions, including an MPU / MCU, to meet the domain's functional computing power and functional safety requirements. Currently, networked vehicle controllers mainly include: Vehicle Controller Unit (VCU), Engine Controller Unit (ECU), and Motor Controller Unit (MCU).

[0007] T-Box: A vehicle T-Box is an in-vehicle communication module used to connect a vehicle to an external network. It typically includes components such as a GPS positioning system, a wireless communication interface, and a microcontroller, enabling real-time monitoring of the vehicle's operating status and data exchange with other devices. The T-Box collects and parses messages from the vehicle controller via the CAN bus, extracting important vehicle signals and parameter information.

[0008] Hardware security chips are mainly used in various controllers in vehicles to provide security functions such as secure startup, security algorithms, encrypted read / write, and authentication.

[0009] The current mainstream solution used by automakers involves embedding the same key into the security module of the main controller connected to the CAN bus for consistency verification, without involving data encryption and decryption. This authentication key is reused across vehicles on the same production line, resulting in poor security. Common risks associated with CAN buses include the lack of encryption and access control mechanisms in in-vehicle communication, allowing attackers to reverse engineer the bus communication protocol, analyze vehicle control commands, and use them for command forgery, thus threatening driving safety. Furthermore, the lack of authentication and message verification mechanisms in in-vehicle communication allows attackers to carry out attacks such as message forgery, denial-of-service attacks, and replay attacks through physical or remote intrusion. Summary of the Invention

[0010] This application provides a secure communication method and device for in-vehicle CAN bus based on symmetric key negotiation, to solve the problem of poor security in existing CAN bus methods that directly use pre-built shared session key libraries.

[0011] The first aspect of this application provides a secure communication method for an in-vehicle CAN bus based on symmetric key negotiation, comprising the following steps: The CAN bus connects each controller and the T-BOX terminal, and a hardware security chip is integrated in each controller and the T-BOX terminal. The same symmetric group key ciphertext and protection key index number are loaded into the hardware security chip of the T-BOX terminal and each controller; The corresponding first protection key is retrieved from the hardware security chip at the T-BOX terminal using the protection key index number, and the first protection key is used to decrypt the symmetric group key ciphertext to obtain the first symmetric group key plaintext. The target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain the protected T-BOX vehicle data, and the protected T-BOX vehicle data is broadcast to each controller. The corresponding second protection key is retrieved from the hardware security chip of each controller using the protection key index number, and the second protection key is used to decrypt the symmetric group key ciphertext to obtain the second symmetric group key plaintext. The protected vehicle data on the T-BOX terminal is decrypted using the plaintext of the second symmetric key to obtain the plaintext vehicle data.

[0012] Optionally, prior to integrating a hardware security chip in each controller and at the T-BOX end, the following steps are included: Each hardware security chip is pre-loaded with a true random number key derived from the target key management system.

[0013] Optionally, the step of loading the same symmetric group key ciphertext and protection key index number into the hardware security chip of the T-BOX terminal and each controller includes: Connect the T-BOX terminal to the target key management system; A new key is generated using the true random number generator of the target key management system; The new key is combined with a preset key update timer task to generate a symmetric group key ciphertext and a protection key index number, and the symmetric group key ciphertext and protection key index number are periodically distributed to the hardware security chip of the T-BOX terminal and each controller.

[0014] Optionally, the step of symmetrically encrypting the target vehicle data using the plaintext of the first symmetric group key to obtain protected T-BOX vehicle data, and broadcasting the protected T-BOX vehicle data to each controller, includes: Acquire target vehicle data at the T-BOX terminal; Based on the SM4 national cryptographic algorithm, the target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain the protected T-BOX terminal vehicle data. The protected T-BOX vehicle data is broadcast to each controller via a CAN transceiver.

[0015] A second aspect of this application provides an in-vehicle CAN bus secure communication device based on symmetric key negotiation, comprising: The building module is used to connect the CAN bus to each controller and the T-BOX terminal, and integrates a hardware security chip in each controller and the T-BOX terminal. A filling module is used to fill the T-BOX terminal with the same symmetric group key ciphertext and protection key index number as the hardware security chip of each controller; The first decryption module is used to retrieve the corresponding first protection key from the hardware security chip at the T-BOX terminal through the protection key index number, and use the first protection key to decrypt the symmetric group key ciphertext to obtain the first symmetric group key plaintext. The data encryption module is used to symmetrically encrypt the target vehicle data using the plaintext of the first symmetric group key to obtain the protected T-BOX vehicle data, and broadcast the protected T-BOX vehicle data to each controller. The second decryption module is used to retrieve the corresponding second protection key from the hardware security chip of each controller through the protection key index number, and use the second protection key to decrypt the symmetric group key ciphertext to obtain the second symmetric group key plaintext. The data decryption module is used to decrypt the protected T-BOX vehicle data using the plaintext of the second symmetric key to obtain the plaintext vehicle data.

[0016] Optionally, it also includes: A pre-filling module is used to pre-fill each hardware security chip with a true random number key derived from the target key management system.

[0017] Optionally, the filling module includes: A connection unit is used to connect the T-BOX terminal to the target key management system; A generation unit is used to generate a new key through a true random number generator in the target key management system; The distribution unit is used to combine the new key with a preset key update timer task to generate a symmetric group key ciphertext and a protection key index number, and to periodically distribute the symmetric group key ciphertext and the protection key index number to the hardware security chip of the T-BOX terminal and each controller.

[0018] Optionally, the data encryption module includes: The acquisition unit is used to acquire target vehicle data at the T-BOX terminal; A symmetric encryption unit is used to symmetrically encrypt the target vehicle data using the plaintext of the first symmetric group key based on the SM4 national cryptographic algorithm, so as to obtain the protected T-BOX terminal vehicle data. The broadcast unit is used to broadcast the protected T-BOX vehicle data to each controller via a CAN transceiver.

[0019] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the in-vehicle CAN bus secure communication method based on symmetric key negotiation as described in the above embodiments.

[0020] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described in-vehicle CAN bus secure communication method based on symmetric key negotiation.

[0021] The in-vehicle CAN bus secure communication method and apparatus based on symmetric key negotiation proposed in this application combines symmetric key distribution, identity authentication and related technologies based on the SM4 symmetric encryption algorithm to provide security protection for in-vehicle network communication. This enables secure communication between various controllers connected to the in-vehicle CAN bus, improves security, solves the problem of key reuse among various nodes of the CAN bus, and achieves the function of one key per message and one key negotiation consuming one key. It is applicable to the field of automotive CAN bus security.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a secure communication method for an in-vehicle CAN bus based on symmetric key negotiation, according to an embodiment of this application. Figure 2 This is a schematic diagram illustrating the specific implementation of a secure communication method for an in-vehicle CAN bus based on symmetric key negotiation, according to an embodiment of this application. Figure 3 This is a block diagram of an in-vehicle CAN bus secure communication device based on symmetric key negotiation according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a vehicle according to an embodiment of this application.

[0024] Explanation of reference numerals in the attached figures: 30-In-vehicle CAN bus secure communication device based on symmetric key negotiation; 301-Construction module; 302-Filling module; 303-First decryption module; 304-Data encryption module; 305-Second decryption module; 306-Data decryption module; 401-Memory; 402-Processor; 403-Communication interface. Detailed Implementation

[0025] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0026] The following describes, with reference to the accompanying drawings, a secure communication method and apparatus for in-vehicle CAN bus based on symmetric key negotiation, according to embodiments of this application.

[0027] Figure 1 This is a flowchart illustrating a secure communication method for an in-vehicle CAN bus based on symmetric key negotiation, provided in an embodiment of this application.

[0028] like Figure 1 As shown, the in-vehicle CAN bus secure communication method based on symmetric key negotiation includes the following steps: In step S101, the CAN bus is connected to each controller and the T-BOX terminal, and a hardware security chip is integrated in each controller and the T-BOX terminal.

[0029] In some embodiments, prior to integrating a hardware security chip within each controller and at the T-BOX end, the following is included: Each hardware security chip is pre-loaded with a true random number key derived from the target key management system.

[0030] In step S102, the same symmetric group key ciphertext and protection key index number are loaded into the hardware security chip of the T-BOX terminal and each controller.

[0031] In some embodiments, the same symmetric group key ciphertext and protection key index number are programmed into the hardware security chip of the T-BOX terminal and each controller, including: Connect the T-BOX terminal to the target key management system; A new key is generated using the true random number generator of the target key management system; The new key is combined with a preset key update timer task to generate a symmetric group key ciphertext and a protection key index number. The symmetric group key ciphertext and protection key index number are then periodically distributed to the hardware security chip of the T-BOX terminal and each controller.

[0032] In actual implementation, the in-vehicle CAN bus is connected to each controller and the T-BOX terminal, and a hardware security chip is integrated in each controller and the T-BOX terminal.

[0033] Furthermore, the T-BOX is connected to the target key management system. The key management system, combined with a true random number generator, is responsible for generating new keys. The key management system also needs to integrate a key update scheduler, combining the new key with a preset key update scheduler to generate a symmetric key ciphertext and a protection key index. This symmetric key ciphertext and protection key index are then periodically distributed to the security chips of the T-BOX and other controller nodes on the vehicle's CAN bus. This ensures that the T-BOX and each controller's hardware security chip are equipped with the same set of symmetric keys obtained from the key management system on the production line. The keys installed by each controller node on the CAN bus are mutually symmetric keys, forming a symmetric group session key within a vehicle. The protection key installed by the hardware security chip is a key file protected by an algorithm. This key file is exported from the key management system and imported into the hardware security chips of each node on the CAN bus using the vehicle manufacturer's production line installation method. This installed key is primarily used as the protection key for the symmetric group key discussed below. Key transmission between the T-BOX and the key management system is achieved through a key transmission SDK integrated into the MCU.

[0034] Furthermore, this application embodiment also includes: verifying the account lifecycle and current account status in the key management system of the T-BOX terminal and the hardware security chip; if the verification is successful, sending a key negotiation request to the key management system; if the verification fails, returning the verification result to the T-BOX terminal.

[0035] Among them, after identity authentication is completed, the T-BOX terminal can obtain the updated symmetric key by periodically updating the key with the key management system. At the same time, it can also send a key negotiation request to the key management system, so that the key management system can generate a real-time symmetric key based on the key negotiation request, and use the symmetric key corresponding to a filling key stored in the T-BOX terminal security chip stored on the platform as the protection key to encrypt the symmetric key to obtain the symmetric key ciphertext.

[0036] It should be noted that the CAN bus refers to the Controller Area Network bus used within a vehicle for communication and data transmission between different electronic control units. The T-BOX includes an onboard communication module, possessing networking capabilities, integrated network and wireless communication functions, and exchanges data with external vehicle networking systems by connecting to the onboard CAN bus. The key management system receives requests for symmetric key pairs from the T-BOX and supports providing periodically updated symmetric key pairs to the T-BOX. The key management system needs to maintain a one-to-one binding relationship between the T-BOX and its corresponding hardware security chip, and the validity period of the T-BOX's identity authentication, providing identity authentication functionality. It also provides key management and cryptographic computation services for vehicle business applications, offering full key lifecycle management, as well as key management functions such as key distribution, public / private key management, and signature verification. A true random number generator is a hardware-based random number generator that generates random numbers through a physical process rather than a computer program. It produces a secure symmetric key that is physically resistant to theft, ensuring that the keys obtained by both communicating parties are identical and that no third party can obtain any information about the key. The true random number generator connects to a key management system, providing it with a true random key source. The hardware security chip has an independent processor and storage unit to store keys and feature data. Each CAN bus controller node's hardware security chip is pre-loaded with a true random number key derived from the key management system. For each vehicle, the protection keys provided by the key management system for each chip's serial number are symmetric keys. Furthermore, this hardware security chip needs key storage space and supports Chinese cryptographic algorithms such as SM2, SM3, and SM4.

[0037] In step S103, the corresponding first protection key is retrieved from the hardware security chip at the T-BOX end using the protection key index number, and the first protection key is used to decrypt the symmetric group key ciphertext to obtain the first symmetric group key plaintext.

[0038] In actual execution, after receiving the symmetric group key ciphertext (encrypted with a protection key to avoid plaintext transmission) and the corresponding protection key index number from the key management system at the T-BOX end, the protection key is a symmetric key provided by the key management system and the same symmetric key loaded into each node of the CAN bus. Therefore, the corresponding first protection key is retrieved from the hardware security chip at the T-BOX end through the protection key index number, and the symmetric group key ciphertext is decrypted using the first protection key to obtain the first symmetric group key plaintext.

[0039] In step S104, the target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain the protected T-BOX vehicle data, and the protected T-BOX vehicle data is broadcast to each controller.

[0040] In some embodiments, the target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain protected T-BOX vehicle data, and the protected T-BOX vehicle data is broadcast to each controller, including: Acquire target vehicle data on the T-BOX terminal; Based on the SM4 national cryptographic algorithm, the target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain the protected vehicle data of the T-BOX terminal. The protected vehicle data from the T-BOX is broadcast to each controller via a CAN transceiver.

[0041] In actual execution, after obtaining the plaintext of the first symmetric key, the vehicle-related data obtained by the T-BOX terminal is symmetrically encrypted using the SM4 national cryptographic algorithm combined with the symmetric key to obtain the protected vehicle data of the T-BOX terminal; the protected vehicle data of the T-BOX terminal is then broadcast to other controller nodes connected to the CAN bus via the CAN transceiver.

[0042] In step S105, the corresponding second protection key is retrieved from the hardware security chip of each controller using the protection key index number, and the second protection key is used to decrypt the symmetric group key ciphertext to obtain the second symmetric group key plaintext.

[0043] In step S106, the protected vehicle data at the T-BOX terminal is decrypted using the plaintext of the second symmetric key to obtain the plaintext of the vehicle data.

[0044] In actual execution, the symmetric group key ciphertext and corresponding protection key index number issued by the key management system to the T-BOX end are broadcast in real time to each controller node on the CAN bus via the CAN transceiver. After receiving the data, each controller's MCU becomes a security SDK to authenticate with the key management system. It calls the SDK's authentication interface to authenticate with the key management system. The key management system checks the MCU's login token and validity period. After verification, it processes the symmetric group key request. Specifically, each controller's MCU uses the protection key index number to retrieve the corresponding second protection key from the hardware security chip, and uses the second protection key to decrypt the symmetric group key plaintext. The security SDK provides authentication and key negotiation interface capabilities for authentication and key negotiation between the T-BOX end and the security chip in the key management system, and also for other controller nodes on the CAN bus to decrypt the symmetric group key ciphertext.

[0045] For example, suppose the symmetric group key ciphertext is (MA, MB, MC), and the corresponding protection key index numbers loaded into the hardware security chips of each controller node of the CAN bus are (ZA, ZB, ZC). The security chips of each node of the CAN bus decrypt the symmetric group key ciphertext, including: The MCU of CAN bus example controller node 1 obtains the specified protection key A' from the filling key of its security chip according to the key index number ZA, and decrypts the symmetric group key ciphertext MA based on the specified protection key A' to obtain the symmetric group key plaintext M. The symmetric group key M is generated by the key management system.

[0046] In the CAN bus example node 2, the MCU obtains the specified protection key B' from the filling key of its security chip according to the key index number ZB, and decrypts the symmetric group key ciphertext MB based on the specified protection key B' to obtain the symmetric group key plaintext M. The symmetric group key M is generated by the key management system.

[0047] In the CAN bus example node 3, the MCU obtains the specified protection key C' from the filling key of its security chip according to the key index number ZC, and decrypts the symmetric group key ciphertext MC based on the specified protection key C' to obtain the symmetric group key plaintext M. The symmetric group key M is generated by the key management system.

[0048] Finally, the encrypted data obtained from the T-BOX and other CAN bus nodes is decrypted using the second symmetric key to obtain the plaintext data.

[0049] It should be noted that any of the controller nodes connected by the CAN bus can actively send data. They can use the key management system to periodically update and distribute the symmetric group key, encrypt the data and broadcast it, and obtain encrypted data broadcast by other CAN nodes for decryption and use.

[0050] In addition, this embodiment of the application can also receive the symmetric group key ciphertext and the corresponding protection key index number returned by the key management system at the T-BOX end. The T-BOX end can encrypt the data and then upload it to the vehicle network cloud platform side using the symmetric group key through the communication module. The vehicle network cloud platform side can combine the platform-side authentication key and the key negotiation SDK to assemble authentication information and negotiate a session key with the key management system. Then, it can use the session key to decrypt the vehicle-side encrypted data obtained from the T-BOX end. The vehicle network cloud platform side can also send encrypted cloud data to the vehicle T-BOX end, and the T-BOX end can negotiate and obtain the session key before decrypting it.

[0051] Furthermore, the key management system in this application can issue scheduled tasks for updating symmetric group keys, which can be combined with vehicle business data protection requirements to implement a scheduled task update mechanism. For example, it can update one symmetric group key per day for the vehicle or customize the update of N keys within a day, updating after the vehicle is started and powered on. It also supports real-time negotiation of symmetric group keys between the T-BOX and the key management system for flexible business data security protection.

[0052] The following detailed description of the in-vehicle CAN bus secure communication method based on symmetric key negotiation proposed in this invention will be provided through a specific embodiment.

[0053] like Figure 2 As shown, the method includes various controller nodes of the CAN bus, MCU, hardware security chip, security SDK, and key management system.

[0054] Before secure communication can be established between the T-BOX and each controller node of the CAN bus, the T-BOX and each controller node of the CAN bus need to be connected to a CAN circuit within the vehicle. The CAN bus supports a serial data communication protocol, and its communication interface integrates the physical layer and data link layer functions of the CAN protocol.

[0055] When encrypted communication is required between nodes of the CAN bus, the in-vehicle CAN bus secure communication method based on symmetric key negotiation includes the following steps: Step one: Inside a smart connected vehicle, the T-BOX terminal already has network capabilities. It connects to other controller nodes on the CAN bus via a CAN bus. Each controller node requiring encrypted communication on the CAN bus needs to integrate a hardware security chip. The same set of protection keys is programmed into each hardware security chip within the vehicle, and the programmed keys for each controller node on the CAN bus are symmetric keys. This programmed key is provided by a key management system, and a key file is generated by the corresponding random number generator and cryptographic machine within the key management system. Under algorithm protection, the key file is programmed into the hardware security chip on the vehicle manufacturing line.

[0056] In the key management system, the relationship between the protection key and the installed protection key is maintained through the serial number of the hardware security chip provided on the vehicle side, including protection key information, key index number, etc.

[0057] The key management system needs to maintain the vehicle frame serial number (SN), the IMEI serial number of the TBOX inside the vehicle, and the serial number of the hardware security chip of each controller for different vehicles, forming a group key management and distribution mechanism within a vehicle.

[0058] Step two: When the vehicle starts and powers on, the T-BOX requests communication from the vehicle's corresponding vehicle-to-everything (V2X) platform to perform a business-side identity authentication process. Before leaving the factory, the vehicle's T-BOX provides identity information (such as the vehicle identification number (VIN) or hardware IMEI serial number) to the V2X platform and requests the generation of a private key. The V2X platform, in conjunction with the key management system, generates the user's private key and sends it to the T-BOX for storage. When the T-BOX requests communication from the V2X platform, it uses its own private key to sign the requested data. The V2X platform verifies the signature based on the T-BOX's public key and the system's public parameters. If the verification is successful, it indicates that the T-BOX's identity is legitimate, and an encryption identifier is issued.

[0059] Step 3: The T-BOX terminal randomly selects a key from the hardware security chip using the security SDK. It then uses the key identifier and key management system to perform initial authentication and device authentication, completing the encryption-side identity authentication process. After successful authentication, the T-BOX terminal sends a key negotiation request to the key management system. This request enables the key management system to generate a symmetric key and encrypts the symmetric key using a randomly stored symmetric key from the T-BOX terminal as a protection key, resulting in the ciphertext of the symmetric key. Step four: The key management system returns the symmetric group key ciphertext and the protection key index number used to the T-BOX terminal. The security chip at the T-BOX terminal retrieves the same protection key from the chip using the protection key index number and decrypts the obtained symmetric group key ciphertext. After obtaining the symmetric group key plaintext, the T-BOX terminal encrypts the data collected from this node using the SM4 national cryptographic algorithm combined with the symmetric group key to obtain the encrypted T-BOX terminal data. The encrypted T-BOX terminal data is then broadcast to other nodes on the CAN bus via the CAN transceiver.

[0060] Step 5: The T-BOX terminal broadcasts the received symmetric group key ciphertext and corresponding protection key index number to all nodes on the CAN bus in real time via the CAN transceiver. Upon receiving the data, each node on the CAN bus uses the MCU controller to retrieve the corresponding protection key from the hardware security chip using the protection key index number, decrypts it to obtain the symmetric group key plaintext, and uses the symmetric group key plaintext to decrypt the encrypted data obtained from the T-BOX terminal and other CAN bus nodes to obtain the plaintext data.

[0061] Each node on the CAN bus can use the obtained symmetric group key plaintext to encrypt the data collected by its MCU. After encryption, the data is broadcast to other nodes on the CAN bus via the CAN transceiver. Other nodes can then use the obtained symmetric group key to decrypt the data and obtain the plaintext data.

[0062] In summary, the in-vehicle CAN bus secure communication method based on symmetric key negotiation proposed in the embodiments of this application has the following beneficial effects: (1) Combining national cryptographic algorithms, devices and entities are allowed to use their identity information to generate public and private key pairs, and use their private keys for digital signatures and identity verification, without the need to issue and manage digital certificates, thus saving management costs; (2) Security measures using hardware security chips and symmetric encryption algorithms based on symmetric keys are used for data security protection of the CAN bus in the Internet of Vehicles, which has high security. (3) Improved security, solved the problem of key reuse in each controller node of the CAN bus, and realized the function of key negotiation once per session and key timed update function; (4) It can solve the problem of car manufacturers sharing a key library for a long time and the key not being updated; the updated key is directly destroyed by the hardware security chip to avoid reuse in the future; (5) To address the impact of increasingly severe network attacks on vehicle-to-everything (V2X) security, the CAN bus nodes that require data security protection are encrypted to prevent data from being stolen or tampered with.

[0063] Next, referring to the accompanying drawings, a vehicle-mounted CAN bus secure communication device based on symmetric key negotiation is described according to an embodiment of this application.

[0064] Figure 3 This is a block diagram illustrating an in-vehicle CAN bus secure communication device based on symmetric key negotiation, as provided in an embodiment of this application.

[0065] like Figure 3 As shown, the in-vehicle CAN bus secure communication device 30 based on symmetric key negotiation includes: a construction module 301, a filling module 302, a first decryption module 303, a data encryption module 304, a second decryption module 305, and a data decryption module 306.

[0066] The system comprises the following modules: Module 301 connects the CAN bus to each controller and the T-BOX terminal, integrating a hardware security chip in each controller and the T-BOX terminal; Module 302 fills the T-BOX terminal and each controller's hardware security chip with the same symmetric key ciphertext and protection key index number; Module 303 retrieves the corresponding first protection key from the T-BOX terminal's hardware security chip using the protection key index number, and decrypts the symmetric key ciphertext using the first protection key to obtain the first symmetric key plaintext; Module 304 performs symmetric encryption on the target vehicle data using the first symmetric key plaintext to obtain protected T-BOX terminal vehicle data, and broadcasts the protected T-BOX terminal vehicle data to each controller; and Module 305 retrieves the corresponding second protection key from the hardware security chip in each controller using the protection key index number, and decrypts the symmetric key ciphertext using the second protection key to obtain the second symmetric key plaintext. The data decryption module 306 is used to decrypt the protected vehicle data on the T-BOX terminal using the plaintext of the second symmetric key to obtain the plaintext of the vehicle data.

[0067] In some embodiments, it also includes: A pre-filling module is used to pre-fill each hardware security chip with a true random number key derived from the target key management system.

[0068] In some embodiments, the filling module includes: A connection unit is used to connect the T-BOX terminal to the target key management system; The generation unit is used to generate new keys through the true random number generator of the target key management system; The distribution unit is used to combine the new key with the preset key update timer task to generate the symmetric group key ciphertext and the protection key index number, and to periodically distribute the symmetric group key ciphertext and the protection key index number to the hardware security chip of the T-BOX terminal and each controller.

[0069] In some embodiments, the data encryption module includes: The acquisition unit is used to acquire target vehicle data at the T-BOX terminal; The symmetric encryption unit is used to symmetrically encrypt the target vehicle data using the plaintext of the first symmetric key based on the SM4 national cryptographic algorithm, so as to obtain the protected vehicle data of the T-BOX terminal. The broadcast unit is used to broadcast the protected T-BOX vehicle data to each controller via a CAN transceiver.

[0070] It should be noted that the foregoing explanation of the embodiment of the in-vehicle CAN bus secure communication method based on symmetric key negotiation also applies to the in-vehicle CAN bus secure communication device based on symmetric key negotiation in this embodiment, and will not be repeated here.

[0071] The in-vehicle CAN bus secure communication device based on symmetric key negotiation proposed in the embodiments of this application has the following beneficial effects: (1) Combining national cryptographic algorithms, devices and entities are allowed to use their identity information to generate public and private key pairs, and use their private keys for digital signatures and identity verification, without the need to issue and manage digital certificates, thus saving management costs; (2) Security measures using hardware security chips and symmetric encryption algorithms based on symmetric keys are used for data security protection of the CAN bus in the Internet of Vehicles, which has high security. (3) Improved security, solved the problem of key reuse in each controller node of the CAN bus, and realized the function of key negotiation once per session and key timed update function; (4) It can solve the problem of car manufacturers sharing a key library for a long time and the key not being updated; the updated key is directly destroyed by the hardware security chip to avoid reuse in the future; (5) To address the impact of increasingly severe network attacks on vehicle-to-everything (V2X) security, the CAN bus nodes that require data security protection are encrypted to prevent data from being stolen or tampered with.

[0072] Figure 4 This is a structural schematic diagram of a vehicle provided in an embodiment of this application.

[0073] The vehicle may include: a memory 401, a processor 402, and a computer program stored on the memory 401 and capable of running on the processor 402.

[0074] When the processor 402 executes the program, it implements the in-vehicle CAN bus secure communication method based on symmetric key negotiation provided in the above embodiments.

[0075] Furthermore, the vehicle also includes: Communication interface 403 is used for communication between memory 401 and processor 402.

[0076] The memory 401 is used to store computer programs that can run on the processor 402.

[0077] Memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0078] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0079] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0080] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0081] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described in-vehicle CAN bus secure communication method based on symmetric key negotiation.

[0082] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

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

[0084] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0085] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0086] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0087] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0088] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0089] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A secure communication method for in-vehicle CAN bus based on symmetric key negotiation, characterized in that, Includes the following steps: The CAN bus connects each controller and the T-BOX terminal, and a hardware security chip is integrated in each controller and the T-BOX terminal. The same symmetric group key ciphertext and protection key index number are loaded into the hardware security chip of the T-BOX terminal and each controller; The corresponding first protection key is retrieved from the hardware security chip at the T-BOX terminal using the protection key index number, and the first protection key is used to decrypt the symmetric group key ciphertext to obtain the first symmetric group key plaintext. The target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain the protected T-BOX vehicle data, and the protected T-BOX vehicle data is broadcast to each controller. The corresponding second protection key is retrieved from the hardware security chip of each controller using the protection key index number, and the second protection key is used to decrypt the symmetric group key ciphertext to obtain the second symmetric group key plaintext. The protected vehicle data on the T-BOX terminal is decrypted using the plaintext of the second symmetric key to obtain the plaintext vehicle data.

2. The in-vehicle CAN bus secure communication method based on symmetric key negotiation according to claim 1, characterized in that, Prior to integrating a hardware security chip in each controller and at the T-BOX end, the following is included: Each hardware security chip is pre-loaded with a true random number key derived from the target key management system.

3. The in-vehicle CAN bus secure communication method based on symmetric key negotiation according to claim 1, characterized in that, The process of loading the same symmetric group key ciphertext and protection key index number into the hardware security chip of the T-BOX terminal and each controller includes: Connect the T-BOX terminal to the target key management system; A new key is generated using the true random number generator of the target key management system; The new key is combined with a preset key update timer task to generate a symmetric group key ciphertext and a protection key index number, and the symmetric group key ciphertext and protection key index number are periodically distributed to the hardware security chip of the T-BOX terminal and each controller.

4. The in-vehicle CAN bus secure communication method based on symmetric key negotiation according to claim 1, characterized in that, The step of symmetrically encrypting the target vehicle data using the plaintext of the first symmetric group key to obtain protected T-BOX vehicle data, and broadcasting the protected T-BOX vehicle data to each controller, includes: Acquire target vehicle data at the T-BOX terminal; Based on the SM4 national cryptographic algorithm, the target vehicle data is symmetrically encrypted using the plaintext of the first symmetric group key to obtain the protected T-BOX terminal vehicle data. The protected T-BOX vehicle data is broadcast to each controller via a CAN transceiver.

5. A secure communication device for an in-vehicle CAN bus based on symmetric key negotiation, characterized in that, include: The building module is used to connect the CAN bus to each controller and the T-BOX terminal, and integrates a hardware security chip in each controller and the T-BOX terminal. A filling module is used to fill the T-BOX terminal with the same symmetric group key ciphertext and protection key index number as the hardware security chip of each controller; The first decryption module is used to retrieve the corresponding first protection key from the hardware security chip at the T-BOX terminal through the protection key index number, and use the first protection key to decrypt the symmetric group key ciphertext to obtain the first symmetric group key plaintext. The data encryption module is used to symmetrically encrypt the target vehicle data using the plaintext of the first symmetric group key to obtain the protected T-BOX vehicle data, and broadcast the protected T-BOX vehicle data to each controller. The second decryption module is used to retrieve the corresponding second protection key from the hardware security chip of each controller through the protection key index number, and use the second protection key to decrypt the symmetric group key ciphertext to obtain the second symmetric group key plaintext. The data decryption module is used to decrypt the protected T-BOX vehicle data using the plaintext of the second symmetric key to obtain the plaintext vehicle data.

6. The in-vehicle CAN bus secure communication device based on symmetric key negotiation according to claim 5, characterized in that, Also includes: A pre-filling module is used to pre-fill each hardware security chip with a true random number key derived from the target key management system.

7. The in-vehicle CAN bus secure communication device based on symmetric key negotiation according to claim 5, characterized in that, The filling module includes: A connection unit is used to connect the T-BOX terminal to the target key management system; A generation unit is used to generate a new key through a true random number generator in the target key management system; The distribution unit is used to combine the new key with a preset key update timer task to generate a symmetric group key ciphertext and a protection key index number, and to periodically distribute the symmetric group key ciphertext and the protection key index number to the hardware security chip of the T-BOX terminal and each controller.

8. The in-vehicle CAN bus secure communication device based on symmetric key negotiation according to claim 5, characterized in that, The data encryption module includes: The acquisition unit is used to acquire target vehicle data at the T-BOX terminal; A symmetric encryption unit is used to symmetrically encrypt the target vehicle data using the plaintext of the first symmetric group key based on the SM4 national cryptographic algorithm, so as to obtain the protected T-BOX terminal vehicle data. The broadcast unit is used to broadcast the protected T-BOX vehicle data to each controller via a CAN transceiver.

9. A vehicle, characterized in that, include: The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the in-vehicle CAN bus secure communication method based on symmetric key negotiation as described in any one of claims 1-4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the in-vehicle CAN bus secure communication method based on symmetric key negotiation as described in any one of claims 1-4.

Images