Method, vehicle, terminal and system for establishing vehicle safety communication

Abstract

Embodiments of the present application provide a method, vehicle, terminal and system for establishing vehicle safety communication. The vehicle can generate an encryption parameter according to a parameter contained in a first interaction parameter set sent by the terminal. Then, the vehicle encrypts a shared secret key using the encryption parameter to obtain a first vehicle secret key. Finally, the vehicle sends a second interaction parameter set containing the first vehicle secret key to the terminal, so that the terminal can decrypt the first vehicle secret key to obtain the shared secret key, and then the terminal and the vehicle can use the shared secret key to encrypt and / or integrity protect the data sent.

Description

Technical Field

[0001] This application relates to the field of vehicle networking, and in particular to a method, vehicle, terminal and system for establishing secure vehicle communication. Background Technology

[0002] The scenarios for communication between intelligent vehicles and external applications are diverse. For example, Figure 1 As shown, vehicle 110 is a connected car that communicates with several external entities such as other vehicles 111, cloud server 120, terminal 130, traffic infrastructure 140, diagnostic instrument 150, smart car key 160 or charging pile 170 to form V2X (vehicle-to-everything) communication.

[0003] The specific processes of different V2X communications vary. Specifically, the communication process between vehicle 110 and terminal 130 is as follows: When the distance between terminal 130 and vehicle 110 is less than or equal to the short-range communication distance, they can communicate bidirectionally via short-range communication media, such as Bluetooth, RFID (Radio Frequency Identification), or NFC (Near Field Communication). When the distance between terminal 130 and vehicle 110 is greater than the short-range communication distance, terminal 130 can use a long-range communication media, such as GPS (Global Positioning System) or GSM (Global System for Mobile Communications), to communicate bidirectionally with vehicle 110.

[0004] In a scenario where terminal 130 communicates with vehicle 110 via cloud server 120, both terminal 130 and vehicle 110 require cloud server 120 to complete data transmission. In an application scenario where a user uses terminal 130 to obtain the vehicle ID from vehicle 110, vehicle 110 needs to upload the vehicle ID to cloud server 120. Cloud server 120 encrypts the vehicle ID and sends the encrypted vehicle ID to terminal 130. If the communication process between cloud server 120 and vehicle 110 or terminal 130 is maliciously attacked during this process, the vehicle ID will be leaked. Summary of the Invention

[0005] To address the problems existing in the prior art, embodiments of this application provide a method, vehicle, terminal, and system for establishing vehicle secure communication.

[0006] In a first aspect, embodiments of this application provide a method for establishing vehicle secure communication, the method being applicable to vehicles, including:

[0007] Receive a first set of interaction parameters, which is a set of parameters sent by the terminal to the vehicle when the terminal requests to interact with the vehicle for data.

[0008] An encrypted parameter set is generated based on the parameters contained in the first interactive parameter set, wherein the encrypted parameter set includes at least one encrypted parameter;

[0009] The shared key is encrypted using the encryption parameters to obtain the first vehicle key, wherein the shared key is a randomly generated string;

[0010] Send a second set of interaction parameters to the terminal, wherein the second set of interaction parameters includes at least the first vehicle key.

[0011] In this implementation, the vehicle can generate encrypted parameters based on the parameters contained in the first set of interactive parameters sent by the terminal; then, it uses the encrypted parameters to encrypt the shared key to obtain the first vehicle key; finally, it sends a second set of interactive parameters containing the first vehicle key to the terminal, so that the terminal can decrypt the first vehicle key to obtain the shared key, thereby enabling the terminal and the vehicle to use the shared key to encrypt and / or protect the integrity of the transmitted data, resulting in a high level of security for communication between the terminal and the vehicle.

[0012] In conjunction with the first aspect and the first implementation method, the first set of interactive parameters includes: curve parameters, base point and first transmission parameters;

[0013] The curve parameters are parameters used to uniquely determine the elliptic curve;

[0014] The first transmission parameter is the parameter obtained by hashing the user password onto the elliptic curve and then performing a point addition calculation with the first elliptic parameter, where the first elliptic parameter is the coordinate value of any point on the elliptic curve.

[0015] In this implementation, the terminal and the vehicle can use the calculated shared key to encrypt and / or protect the integrity of the transmitted data, resulting in a high level of security for communication between the terminal and the vehicle.

[0016] In conjunction with the first aspect, the second implementation method further includes: a first subset, which includes at least one identifier parameter, the identifier parameter including: user ID and / or component ID.

[0017] In this implementation, the terminal and the vehicle can use the calculated shared key to encrypt and / or protect the integrity of the transmitted data, resulting in a high level of security for communication between the terminal and the vehicle.

[0018] In conjunction with the first aspect and the third implementation method, the second set of interaction parameters further includes: a second subset, which includes at least one interaction parameter, wherein the interaction parameter is a parameter that participates in the calculation of the encryption parameter and is not recorded in the terminal.

[0019] In this implementation, the terminal and the vehicle can use the calculated shared key to encrypt and / or protect the integrity of the transmitted data, resulting in a high level of security for communication between the terminal and the vehicle.

[0020] In conjunction with the first aspect and the fourth implementation method, the step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set includes:

[0021] The first ellipse parameter is obtained by subtracting the first transfer parameter from the second ellipse parameter.

[0022] The master key is obtained by connecting the first elliptic parameter and the second elliptic parameter. The second elliptic parameter is obtained by hashing the user password onto an elliptic curve. The user password is pre-stored in the vehicle. The elliptic curve is a curve selected according to the curve parameter.

[0023] In this implementation, a first elliptic parameter and a second elliptic parameter are introduced during the master key calculation process. The second elliptic parameter is obtained by hashing the user password onto an elliptic curve, thus ensuring the master key is correlated with the user password. The first elliptic parameter is calculated based on the first transmission parameter. Since the first transmission parameter is random and unpredictable, the first elliptic parameter is also random and unpredictable. Introducing the first elliptic parameter during master key calculation increases the randomness and unpredictability of the master key. The first vehicle key calculated using this master key is random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0024] In conjunction with the first aspect and the fifth implementation method, the step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set includes:

[0025] The first ellipse parameter is obtained by subtracting the first transmission parameter from the second ellipse parameter. The second ellipse parameter is obtained by hashing the user password onto an ellipse curve. The user password is stored in the vehicle in advance. The ellipse curve is a curve selected according to the curve parameter.

[0026] The first ellipse parameter is multiplied by the random parameter to obtain the third ellipse parameter, wherein the random parameter is a randomly generated parameter;

[0027] By connecting the third elliptic parameter and the second elliptic parameter, the master key is obtained.

[0028] In this implementation, a first elliptic parameter, a second elliptic parameter, and a random parameter are introduced during the master key calculation process. The second elliptic parameter is obtained by hashing the user password onto an elliptic curve, thus ensuring the master key is related to the user password. The first elliptic parameter is calculated based on the first transmission parameter; since the first transmission parameter is random and unpredictable, the first elliptic parameter is also random and unpredictable. The random parameter is also random and unpredictable. Introducing the first elliptic parameter and the random parameter during master key calculation increases the randomness and unpredictability of the master key. The first vehicle key calculated using this master key is random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0029] In conjunction with the first aspect, the sixth implementation method further includes the step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set:

[0030] An intermediate parameter is calculated based on the identification parameter and / or the vehicle ID and / or the first transmission parameter and / or the second transmission parameter, wherein the vehicle ID is pre-stored in the vehicle and the second transmission parameter is a parameter calculated based on the parameters in the first set of interaction parameters.

[0031] In this implementation, parameters that participate in the intermediate parameter calculation can be flexibly selected according to needs, thus achieving a flexible encryption process.

[0032] Combining the first aspect and the seventh implementation method, the calculation process of the second transmission parameter is as follows:

[0033] Select an elliptic curve based on the curve parameters;

[0034] The user password is hashed onto the elliptic curve to obtain the second ellipse parameter;

[0035] The second ellipse parameter and the fourth ellipse parameter are added together to obtain the second transfer parameter, where the fourth ellipse parameter is the coordinate value of any point on the elliptic curve.

[0036] In this implementation, a fourth elliptic parameter is introduced during the calculation of the second transfer parameter. The fourth elliptic parameter is the coordinate value corresponding to any point on the elliptic curve. Therefore, the fourth elliptic parameter has randomness. Introducing the fourth elliptic parameter during the calculation of the second transfer parameter can make the second transfer parameter random and unpredictable.

[0037] In conjunction with the first aspect, the eighth implementation method further includes the step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set:

[0038] The master key is encrypted using the intermediate parameters to obtain the encryption key.

[0039] In this implementation, the vehicle uses intermediate parameters to perform secondary encryption on the master key to obtain the encryption key. Because the intermediate parameters are random and unpredictable, the resulting encryption key is also guaranteed to be random and unpredictable. Furthermore, even if a malicious attack occurs during the communication process between the terminal and the vehicle, the encryption key will be the first key attacked; therefore, the encryption key provides a degree of protection for the master key.

[0040] In conjunction with the first aspect, the ninth implementation method, the step of calculating intermediate parameters based on the identification parameter and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically includes:

[0041] By connecting the user ID and the component ID, intermediate parameters are obtained.

[0042] In this implementation, a user ID and a component ID are introduced during the calculation of intermediate parameters. The user ID uniquely identifies the terminal, ensuring that the generated intermediate parameters are relevant to the terminal. The component ID uniquely identifies the ECU (Electronic Control Unit), allowing for the generation of different intermediate parameters for each ECU. These intermediate parameters participate in the calculation of the first vehicle key, enabling the generation of different first vehicle keys for different ECUs. The communication between the terminal and the vehicle using this first vehicle key ensures high security.

[0043] In conjunction with the first aspect, the tenth implementation method, the step of calculating intermediate parameters based on the identification parameter and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically includes:

[0044] By connecting the user ID, the component ID, and the first transmission parameter, intermediate parameters are obtained.

[0045] In this implementation, a first transmission parameter and a component ID are introduced during the calculation of intermediate parameters. The component ID uniquely identifies the ECU, allowing for the generation of different intermediate parameters for different ECUs. The first transmission parameter is random and unpredictable; therefore, the intermediate parameters calculated based on this first transmission parameter are also random and unpredictable. The first vehicle key calculated using this intermediate parameter is also random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0046] In conjunction with the first aspect, the eleventh implementation method, the step of calculating intermediate parameters based on the identification parameter and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically includes:

[0047] By connecting the user ID, the component ID, the first transmission parameter, and the second transmission parameter, an intermediate parameter is obtained.

[0048] In this implementation, a user ID, a component ID, a first transmission parameter, and a second transmission parameter are introduced during the calculation of intermediate parameters. The component ID uniquely identifies the ECU, allowing for the generation of different intermediate parameters for different ECUs. Furthermore, the user ID uniquely identifies the terminal, ensuring that the generated intermediate parameters correspond to the terminal. Moreover, the first and second transmission parameters are random and unpredictable, thus the generated intermediate parameters are also random and unpredictable. The first vehicle key calculated using these intermediate parameters is also random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0049] In conjunction with the first aspect and the twelfth implementation, the step of calculating intermediate parameters based on the identification parameter and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically includes:

[0050] Intermediate parameters are obtained by connecting the user ID, the component ID, the vehicle ID, the first transmission parameter, and the second transmission parameter.

[0051] In this implementation, a user ID, component ID, vehicle ID, a first transmission parameter, and a second transmission parameter are introduced during the calculation of intermediate parameters. The component ID uniquely identifies the ECU, allowing for the generation of different intermediate parameters for different ECUs. Similarly, the user ID uniquely identifies the terminal, ensuring the generated intermediate parameters correspond to the terminal; the vehicle ID uniquely identifies the vehicle, ensuring the generated intermediate parameters correspond to the vehicle. Furthermore, the first and second transmission parameters are random and unpredictable, resulting in random and unpredictable intermediate parameters. The first vehicle key calculated using these intermediate parameters is also random and unpredictable. This first vehicle key prevents replay attacks during communication between the terminal and the vehicle, resulting in high communication security.

[0052] In conjunction with the first aspect, the thirteenth implementation method, the step of calculating intermediate parameters based on the identification parameter and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically includes:

[0053] By connecting the vehicle ID and the second transmitted parameter, intermediate parameters are obtained.

[0054] In this implementation, a second transmission parameter and a vehicle ID are introduced during the calculation of intermediate parameters. The vehicle ID uniquely identifies the vehicle, ensuring that the generated intermediate parameters are vehicle-specific. The second transmission parameter is random and unpredictable, thus the generated intermediate parameters are also random and unpredictable. The first vehicle key calculated using this intermediate parameter is also random and unpredictable. When the terminal and vehicle communicate using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0055] Secondly, embodiments of this application provide a method for establishing vehicle safety communication, the method being applicable to a terminal, including:

[0056] Receive a second set of interaction parameters, wherein the second set of interaction parameters includes at least the first vehicle key;

[0057] Decrypt the first vehicle key to obtain the encryption parameters and the shared key;

[0058] The shared key is encrypted using the encryption parameters to obtain the second vehicle key, or the second vehicle key is generated using the encryption parameters.

[0059] Send the second vehicle key to the vehicle.

[0060] In this implementation, the terminal can decrypt the first vehicle key sent by the vehicle to obtain encryption parameters and a shared key. Then, it uses the encryption parameters to encrypt the shared key to obtain a second vehicle key. Finally, it sends the second vehicle key to the vehicle, allowing the vehicle to decrypt the second vehicle key using its internally stored encryption parameters to obtain the shared key and / or encryption parameters. The vehicle can compare the decrypted shared key and / or encryption parameters with its own stored shared key and / or encryption parameters. If they match, decryption is successful. Upon successful decryption, the terminal and vehicle can use the shared key to encrypt and / or protect the integrity of the transmitted data.

[0061] Thirdly, embodiments of this application provide a vehicle, including a key management system, the key management system comprising:

[0062] The processor and memory used to store processor-executable instructions;

[0063] The processor is configured to implement the method provided in the first aspect when executing the instructions.

[0064] Fourthly, embodiments of this application provide a terminal, including:

[0065] The processor and memory used to store processor-executable instructions;

[0066] The processor is configured to implement the method provided in the second aspect when executing the instructions.

[0067] Fifthly, embodiments of this application provide a secure communication system, including:

[0068] A vehicle configured to implement the method provided in the first aspect when executing the instructions;

[0069] A terminal configured to implement the method provided in the second aspect when executing the instructions.

[0070] Sixthly, embodiments of this application provide a secure communication system, including:

[0071] A first application installed on the vehicle, the first application being configured to implement the method provided in the first aspect when executing the instructions;

[0072] A second application installed on the terminal, the second application being configured to implement the method provided in the second aspect when executing the instructions.

[0073] In a seventh aspect, embodiments of this application provide a non-volatile computer-readable storage medium having computer program instructions stored thereon, wherein the computer program instructions, when executed by a processor, implement the method provided in the first aspect or the method provided in the second aspect.

[0074] Eighthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method provided in the first aspect, or causes the computer to perform the method provided in the second aspect. Attached Figure Description

[0075] Figure 1 A scenario diagram illustrating communication between a smart car and external entities;

[0076] Figure 2 A schematic diagram of a network architecture to which this application applies;

[0077] Figure 3 This is a conceptual diagram of the technical solution proposed in this application;

[0078] Figure 4 This is a structural block diagram of the KMS provided in this embodiment;

[0079] Figure 5 A flowchart of the method for establishing vehicle safety communication provided in this embodiment;

[0080] Figure 6 This is a schematic diagram of an elliptic curve;

[0081] Figure 7 A flowchart of an encryption parameter generation method provided for a feasible embodiment;

[0082] Figure 8 A flowchart of an encryption parameter generation method provided for a feasible embodiment;

[0083] Figure 9 A flowchart of an encryption parameter generation method provided for a feasible embodiment;

[0084] Figure 10 A flowchart of a second transfer parameter generation method provided as a feasible embodiment;

[0085] Figure 11 A flowchart of the method for establishing vehicle safety communication provided in this embodiment;

[0086] Figure 12 This is a structural block diagram of the system for establishing vehicle safety communication provided in this embodiment;

[0087] Figure 13 This is a flowchart illustrating the interaction between a terminal and a vehicle, provided as a feasible embodiment. Detailed Implementation

[0088] The method, vehicle, terminal, and system proposed in this application will be described below with reference to specific embodiments.

[0089] Figure 2 The diagram shown illustrates a network architecture applicable to this application, including a vehicle 210, a cloud server 220, and a terminal 230.

[0090] In this application, vehicle 210 is equipped with an ECU (Electronic Control Unit) and a communication device. The ECU can communicate with terminal 230 or cloud server 220 through the communication device. The ECU can be, but is not limited to, VCU (Vehicle Control Unit), MDC (Mobile Data Center), BCM (Body Control Module), BMS (Battery Management System), ESP (Electronic Stability Program), EPS (Electronic Power Steering), SDM (Supplemental Restraint System Diagnostic Module), etc. ECUs can communicate with each other using CAN (Controller Area Network). The communication device is a component used to communicate with external devices or external servers according to various communication protocol types. The communication device may include at least one of the following: Wi-Fi chip, BLE (Bluetooth Low Energy) communication protocol chip, wired Ethernet communication protocol chip, other network communication protocol chips or near-field communication protocol chips, and an infrared receiver. For example, when the distance between the vehicle and the terminal is less than a preset distance, the vehicle 210 and the terminal 230 can communicate bidirectionally through a short-range communication device, such as Bluetooth, RFID (Radio Frequency Identification), or NFC (Near Field Communication). The terminal 230 and the cloud server 220 can communicate through a long-range communication device, such as a T-Box (Telematics BOX, pre-installed smart gateway) or a GW (Gateway, vehicle gateway) integrated in the vehicle.In this application, the vehicle supports one or more wireless communication technologies, such as Wifi (wireless fidelity), LTE (long term evolution), 5G (5th Generation Mobile Communication Technology), 4G (4th Generation Mobile Communication Technology), etc.

[0091] In this application, the cloud server 220 is a vehicle-to-everything (V2X) management platform deployed in the cloud. Communication between the cloud server 220 and the vehicle 210 / terminal 230 can be achieved through a communication network. This communication network typically includes access devices and network devices; this application does not limit the types of access devices and network devices. Specifically, the access device can be a base station of an evolved universal terrestrial radio access network (E-UTRAN) or a 5G network base station, etc. The network device can be a 4G core network (CN) device or network element, or a 5G CN device or network element. The cloud server 220 is a trusted server for the vehicle 210 / terminal 230, and the vehicle 210 / terminal 230 can establish a secure communication channel with the cloud server 220. As a V2X management platform, the cloud server 220 can also connect to or manage the vehicle 210 / terminal 230. Through pre-configuration or negotiation, a secure communication channel or secure connection can be established between the cloud server 220 and the terminal 230 for secure communication. The cloud server 220 serves as a management platform for vehicles / terminals. Vehicles and terminals open accounts or register on the cloud server 220. The cloud server 220 stores the account opening or registration information of vehicles / terminals, which may include long-term valid identity and security information of vehicles, such as vehicle license plate number, VIN (Vehicle identification number), PSK (Pre-Shared Key), PSKID (Pre-Shared Key identification), etc. It may also include long-term valid identity and security information of terminals, such as terminal account, terminal identification number, etc.

[0092] In this application, terminal 230 can be a handheld device with wireless connectivity or a processing device connected to a wireless modem. For example, it can be a mobile phone, computer, tablet, PDA (personal digital assistant), MID (mobile internet device), wearable device, and e-book reader; it can also be a portable, pocket-sized, handheld, or computer-embedded mobile device. Specifically, terminal 230 can communicate bidirectionally with vehicle 210 or cloud server 220 through a built-in or integrated communication device. In this application, when the distance between the terminal and the vehicle is less than a preset distance, the terminal can communicate directly with the vehicle using its integrated short-range communication device. For example, when the distance between the terminal and the vehicle is less than the preset distance, the terminal can use its integrated Bluetooth module to send door / window opening commands, authentication information, automatic parking control commands, vehicle location commands, or charging gun unlocking commands to the vehicle. When the distance between the terminal and the vehicle is greater than the preset distance, the terminal can communicate with the vehicle via a cloud server. For example, the terminal can use the full communication channel between the terminal and the cloud server to transmit vehicle status query instructions or vehicle control instructions to the cloud server 220, and then the cloud server can use the full communication channel between the cloud server and the vehicle to transmit the above instructions to the target vehicle.

[0093] Whether the terminal communicates directly with the vehicle through its integrated communication device or via a cloud server, the information or instructions sent by the terminal to the vehicle are crucial. The target vehicle needs to accurately receive this information or instructions and prevent them from being maliciously intercepted by other vehicles or users. Therefore, for secure communication, the information or instructions transmitted between the terminal and the vehicle, between the terminal and the cloud server, and between the cloud server and the vehicle require secure processing, such as encryption or integrity protection. However, in actual network deployments, cloud servers are vulnerable to malicious attacks, leading to the leakage of data or control commands during communication. Therefore, how the terminal can communicate securely with the vehicle is the technical problem this embodiment aims to solve.

[0094] Figure 3 The diagram shows the technical concept proposed in this application.

[0095] In this application, the vehicle 310 is equipped with a KMS (Key Management System) 311 and one or more ECUs 312, such as VDC, CDC, or MDC. In this example, the KMS can distribute a shared key to the ECUs 312 and the terminal 320 according to the key generation method, so as to realize secure communication between the terminal 320 and the ECUs 312.

[0096] In this application, the shared key is applied both inside and outside the vehicle. Application inside the vehicle can include use with a single ECU 312. For example, the shared key can be used for securely starting the ECU, flashing the ECU, protecting configuration files, and protecting software / hardware IP. When applied to multiple ECUs, the shared key can be used for authentication and secure communication between the ECUs. The shared key can also be applied outside the vehicle. Application outside the vehicle can include vehicle authentication, access control, and various communications with external devices (e.g., terminal 320, cloud server 330).

[0097] like Figure 4 The KMS shown in this embodiment can be a chip system. In this embodiment, the chip system can be composed of chips or may include chips and other discrete devices.

[0098] KMS includes at least one processor 410 for implementing the method provided in this embodiment. Exemplarily, the processor 410 can generate and send vehicle keys, transmit parameters, and other information, as detailed in the method examples, which will not be repeated here.

[0099] In this embodiment, the processor 410 can be a general-purpose processor, a digital information processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in this embodiment. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in this embodiment can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0100] The KMS may also include at least one memory 420 for storing program instructions and / or data. The memory 420 is coupled to the processor 410. In this embodiment, the coupling is an indirect coupling or communication connection between devices, units, or modules, and may be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 410 may operate in conjunction with the memory 420. The processor 410 may execute program instructions stored in the memory 420.

[0101] In this embodiment, the memory 420 can be a non-volatile memory, such as an HDD (hard disk drive) or SSD (solid-state drive), or it can be a volatile memory, such as RAM (random-access memory). Memory is any medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited to these. In this embodiment, the memory can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0102] KMS may also include a communication interface 430 for communicating with other devices via a transmission medium, thereby enabling communication between the vehicle and other devices. Exemplarily, this other device may be a terminal. The processor 410 utilizes the communication interface 430 to send and receive data and to implement... Figures 5-9 The methods described in the corresponding embodiments.

[0103] This embodiment does not limit the specific connection medium between the communication interface 430, the processor 410, and the memory 420.

[0104] This embodiment is in Figure 4 The memory 420, processor 410, and communication interface 430 are connected via a bus 440, and the bus 440 is in... Figure 4 The connections between other components are shown in bold lines only and are not intended to be limiting. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, Figure 3 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.

[0105] The following will refer to Figure 5 The specific steps and flow of KMS in establishing vehicle safety communication according to embodiments of this application are explained in detail.

[0106] In S51, KMS receives the first set of interaction parameters.

[0107] In this embodiment, the first set of interaction parameters is a set of parameters sent by the terminal to the vehicle when the terminal requests data interaction with the vehicle. The first set of interaction parameters may include: curve parameters, base points, and first transmission parameters.

[0108] In this embodiment, the curve parameters are parameters used to uniquely determine the elliptic curve; wherein, the elliptic curve is a set of parameters that satisfy y 2 =x 3 +ax+b and satisfy 4a 3 +27b 2The set of points (x, y) ≠ 0. An elliptic curve is determined, using the curve parameters T = (a, b). Before requesting data interaction with the vehicle, the terminal pre-selects an elliptic curve; once selected, the curve parameters a and b are determined. Alternatively, the terminal can randomly select an elliptic curve before each data interaction request. This elliptic curve is only applied to the current data interaction between the terminal and the vehicle. Therefore, even if the current data interaction is maliciously attacked, it will not affect subsequent data interactions, thus preventing replay attacks.

[0109] In this embodiment, the base point is a valid point on the elliptic curve, which can be represented as P. The order of the base point is determined using a method for calculating the order of points on the elliptic curve. If the calculated order is an integer, the base point is valid. This embodiment does not limit the selection method of the base point; methods commonly used in the art can be employed. For example, the base point can be selected as follows: First, a random value x1 is selected, where x1 is any value. Then, the x1 value is used to determine if the elliptic curve has a solution. If a solution exists, y1 is calculated. Then, y1 is substituted into the elliptic curve to calculate x2. The coordinates of the base point are then (x2, y1).

[0110] In this embodiment, the first transmission parameter is the parameter obtained by hashing the user password onto an elliptic curve and then performing a point-plus calculation with the first elliptic parameter, which can be represented as C1. Here, the first elliptic parameter is the coordinate value of any point on the elliptic curve, which can be represented as X, and X is random and unpredictable. The result of the point-plus calculation is obtained by extending the line connecting two points on the elliptic curve to obtain an extension line, and then flipping the intersection of the extension line and the elliptic curve about the X-axis to obtain the coordinates of the point on the elliptic curve. The point-plus calculation process is explained below with reference to the specific accompanying drawings. Figure 6 This is a schematic diagram of an elliptic curve, with two points Q and L on the curve. The extension of the line connecting Q and L intersects the elliptic curve at point M. Flipping M about the X-axis yields the coordinates of point N on the elliptic curve, which is the sum of the coordinates of Q and L. The first transfer parameter can be generated as follows: Arbitrarily select a point x on the elliptic curve selected by the terminal, and generate the first elliptic parameter X according to the following formula: The terminal hashes PW (Password) onto a selected elliptic curve to obtain HashtoPoint(PW). This refers to the dot product calculation of an elliptic curve. Multiplying any numerical value by a base point converts that value into the coordinates of the corresponding point on the elliptic curve. PW is a fixed piece of information set by the user. Because X is random and unpredictable, C1 calculated based on X also exhibits randomness and unpredictability. Furthermore, C1 calculated based on HashtoPoint(PW) is related to PW.

[0111] As a feasible implementation method, the first set of interaction parameters also includes: a first subset, wherein the first subset includes at least one identifier parameter.

[0112] In this embodiment, the identification parameter is a parameter that uniquely identifies a component or device. For example, the identification parameter could be a user ID that uniquely identifies a terminal.

[0113] In S52, KMS generates an encryption parameter set based on the parameters contained in the first interaction parameter set, the encryption parameter set including at least one encryption parameter.

[0114] There are several ways to generate encryption parameters. The following examples illustrate how to generate encryption parameters.

[0115] Please see Figure 7 , Figure 7 A flowchart of an encryption parameter generation method provided in a feasible embodiment, wherein KMS is configured to perform the following steps:

[0116] In S71, KMS performs a point subtraction calculation between the first transfer parameter and the second ellipse parameter to obtain the first ellipse parameter;

[0117] In this embodiment, the first ellipse parameter can be represented as X, and X can be calculated using the following formula: X = C1 - HashtoPoint(PW). Wherein, HashtoPoint(PW) is the second ellipse parameter.

[0118] In this embodiment, HashtoPoint(PW) is the ellipse parameter obtained by hashing PW onto an elliptic curve.

[0119] In this embodiment, the password (PW) is a fixed piece of information set by the user, used for determining terminal access permissions and calculating encryption parameters. Since the user password is a fixed piece of information, if it is cracked once, there is a possibility of a replay attack during data interaction between the terminal and the vehicle. Therefore, in the solution shown in this embodiment, the user password is pre-stored in the vehicle's KMS (Knowledge Management System), and during key negotiation, the user password is not transmitted as plaintext between the KMS and the terminal.

[0120] The process of storing the user password in the KMS can be as follows: When the terminal is first bound to the vehicle, the terminal registers a user account number, which is used to bind the correspondence between the vehicle and the terminal. The process of registering the user account number can be as follows: The terminal transmits registration information to the KMS using a short-range communication medium. In this embodiment, the registration information includes at least a user ID and a PW (Password). The KMS stores the received registration information. Each time the terminal attempts to communicate with the vehicle, the terminal transmits the user ID to the vehicle's KMS. Then, the KMS calls the corresponding PW according to the correspondence between the user ID and the PW.

[0121] In this embodiment, the time for the terminal to transmit the user ID is not limited. As a feasible implementation, each time the terminal attempts to communicate with the vehicle, it can pre-transmit the user ID to the KMS. The KMS authenticates the received user ID. If authentication is successful, the KMS outputs feedback information to the terminal. After receiving the feedback information from the KMS, the terminal can execute the action of sending the first set of interaction parameters. The authentication process may, but is not limited to, the KMS determining whether the received user ID is pre-stored in its internal memory; if pre-stored, authentication is successful; otherwise, authentication fails. As a feasible implementation, the terminal can transmit the user ID as a parameter along with the curve parameters, P, and C1 to the KMS. It is worth noting that this embodiment only exemplifies two methods for the terminal to transmit the user ID; the above transmission time is not a limitation. In actual applications, the terminal's user ID transmission time can be, but is not limited to, the above two implementation methods.

[0122] In S72, KMS connects the first elliptic parameter and the second elliptic parameter to obtain the master key.

[0123] In this embodiment, the master key can be represented as MK, and MK can be calculated using the following formula: MK = X||HashtoPoint(PW).

[0124] The technical solution illustrated in this embodiment introduces a first elliptic parameter and a second elliptic parameter during the calculation of the master key. The second elliptic parameter is obtained by hashing the user password onto an elliptic curve, thus ensuring the master key is related to the user password. The first elliptic parameter is calculated based on the first transmission parameter. Since the first transmission parameter is random and unpredictable, the first elliptic parameter is also random and unpredictable. Introducing the first elliptic parameter during master key calculation increases the randomness and unpredictability of the master key. The first vehicle key calculated using this master key is random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in higher communication security.

[0125] Please see Figure 8 , Figure 8 This is a flowchart illustrating a feasible embodiment of a method for generating encryption parameters. Figure 7 As shown, KMS is also configured to perform the following steps:

[0126] In S81, the first transfer parameter is subtracted from the second ellipse parameter to obtain the first ellipse parameter;

[0127] In this embodiment, the first ellipse parameter can be represented as X, and X can be calculated using the following formula: X = C1 - HashtoPoint(PW).

[0128] In S82, the first ellipse parameter is multiplied by the random parameter to obtain the third ellipse parameter.

[0129] In this embodiment, KMS can calculate the third ellipse parameters using the following formula: Where y is a random parameter. In this embodiment, y is a randomly generated string, and y has randomness and unpredictability.

[0130] In S83, KMS connects the third elliptic parameter and the second elliptic parameter to obtain the master key.

[0131] In this embodiment, MK can be calculated using the following formula: ||HashtoPoint(PW).

[0132] The technical solution illustrated in this embodiment introduces a first elliptic parameter, a second elliptic parameter, and a random parameter during the master key calculation process. The second elliptic parameter is obtained by hashing the user password onto an elliptic curve, thus ensuring the master key is related to the user password. The first elliptic parameter is calculated based on the first transmission parameter; since the first transmission parameter is random and unpredictable, the first elliptic parameter is also random and unpredictable. The random parameter is also random and unpredictable. Introducing both the first elliptic parameter and the random parameter during master key calculation further increases the randomness and unpredictability of the master key. The first vehicle key calculated using this master key is random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0133] To further enhance the security of terminal-vehicle communication, a feasible embodiment of this application provides a method for generating encryption parameters. For example... Figure 9 As shown above, in the above Figure 7 or Figure 8 In addition to providing a method for generating encryption parameters, KMS is also configured to perform the following steps:

[0134] In S91, KMS calculates intermediate parameters based on the identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter.

[0135] There are multiple ways to calculate intermediate parameters based on the identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter.

[0136] As a feasible implementation method, the identification parameters may include: user ID and component ID. KMS can connect user ID and component ID to obtain intermediate parameters.

[0137] In this embodiment, the user ID refers to a parameter that can uniquely identify the terminal. This embodiment does not limit the style of the user ID; any identifier that can uniquely identify the terminal can be used as the user ID. For example, the user ID can be a random string assigned to the terminal by KMS when the terminal first registers an account. The user ID can also be, but is not limited to, the terminal's device ID.

[0138] In this embodiment, the component ID refers to a parameter that can uniquely identify the ECU. This embodiment does not limit the style of the component ID; any identifier that can uniquely identify the ECU can be used as a component ID. For example, the component ID can be the ECU name assigned by the manufacturer during the vehicle manufacturing process, such as VDC, CDC, MDC, etc.

[0139] In this implementation, the first set of interactive parameters sent by the terminal may include: {curve parameters, P, C1, user ID, and component ID}.

[0140] In this implementation, the intermediate parameter can be represented as W, which can be calculated using the following formula: W = User ID || Component ID.

[0141] In this implementation, a user ID and a component ID are introduced during the calculation of intermediate parameters. The user ID uniquely identifies the terminal, ensuring that the generated intermediate parameters are relevant to the terminal. The component ID uniquely identifies the ECU (Electronic Control Unit), allowing for the generation of different intermediate parameters for each ECU. These intermediate parameters participate in the calculation of the first vehicle key, enabling the generation of different first vehicle keys for different ECUs. The communication between the terminal and the vehicle using this first vehicle key ensures high security.

[0142] As a feasible implementation method, KMS can connect the user ID and the first transmitted parameter to obtain intermediate parameters.

[0143] In this implementation, the first set of interactive parameters sent by the terminal may include: {curve parameters, P, C1, user ID}.

[0144] In this implementation, the intermediate parameters can be calculated as follows: W = User ID || C1.

[0145] In this implementation, a user ID and a first transmission parameter are introduced during the calculation of intermediate parameters. The user ID uniquely identifies the terminal, ensuring that the generated intermediate parameters are associated with the terminal. The first transmission parameter is random and unpredictable; therefore, the intermediate parameters calculated based on this first transmission parameter are also random and unpredictable. The first vehicle key calculated using this intermediate parameter is also random and unpredictable. When the terminal and vehicle communicate using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0146] As a feasible implementation method, KMS can connect the user ID, component ID, and the first transmitted parameter to obtain intermediate parameters.

[0147] In this implementation, the first set of interactive parameters sent by the terminal may include: {curve parameters, P, C1, user ID, component ID}.

[0148] In this implementation, the intermediate parameters can be calculated as follows: W = User ID || Component ID || C1.

[0149] In this implementation, a first transmission parameter, a component ID, and a user ID are introduced during the calculation of intermediate parameters. The user ID uniquely identifies the terminal, ensuring that the generated intermediate parameters are terminal-specific. The component ID uniquely identifies the ECU, allowing for the generation of different intermediate parameters for different ECUs. The first transmission parameter is random and unpredictable; therefore, the intermediate parameters calculated based on this first transmission parameter are also random and unpredictable. The first vehicle key calculated using these intermediate parameters is also random and unpredictable. The communication between the terminal and the vehicle using this first vehicle key effectively prevents replay attacks, resulting in high communication security.

[0150] To generate intermediate parameters corresponding to the vehicle, after obtaining the first set of interaction parameters, the KMS can combine it with the vehicle ID stored within the KMS to generate the vehicle's intermediate parameters. In this embodiment, the vehicle ID refers to information that can uniquely identify the vehicle. As an example, the vehicle ID can be a unique identifier assigned to the vehicle by the manufacturer during the manufacturing process. For example, the vehicle ID may also include, but is not limited to, a vehicle identification code.

[0151] As a feasible implementation method, KMS can connect the vehicle ID and the first transmitted parameter to obtain intermediate parameters.

[0152] In this implementation, the first set of interactive parameters sent by the terminal may include {curve parameters, P, C1}.

[0153] In this implementation, the intermediate parameters can be calculated as follows: W = Vehicle ID || C1.

[0154] In this implementation, a first transmission parameter and a vehicle ID are introduced during the calculation of intermediate parameters. The first transmission parameter is random and unpredictable, and the vehicle ID uniquely identifies the vehicle. Therefore, the generated intermediate parameters are random and unpredictable, and each intermediate parameter corresponds to a vehicle. The first vehicle key calculated using these intermediate parameters is also random and unpredictable. When the terminal and vehicle communicate using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0155] To further enhance the randomness and unpredictability of intermediate parameters, after obtaining the first set of interaction parameters, KMS can combine the calculated second transfer parameters to generate intermediate parameters for the vehicle.

[0156] In this embodiment, the second transmission parameter is a parameter calculated by KMS based on the first transmission parameter, and it has randomness and unpredictability. Figure 10 A flowchart of a second transmission parameter generation method is provided for a feasible embodiment. The KMS performs the following steps: In S101, the KMS selects an elliptic curve based on the curve parameters. In this embodiment, the first set of interaction parameters may include: {curve parameters, P, C1}. After receiving {curve parameters, P, C1}, the KMS selects the corresponding elliptic curve using the curve parameters. In S102, the KMS hashes the user password onto the elliptic curve to obtain the second elliptic parameter. In this embodiment, the user password is pre-stored in the KMS. The KMS hashes the user password onto the elliptic curve to obtain the second elliptic parameter HashtoPoint(PW). In S103, the KMS performs a point-to-point addition calculation between the second elliptic parameter and the fourth elliptic parameter to obtain the second transmission parameter. In this embodiment, the fourth elliptic parameter is the coordinate value corresponding to any point on the elliptic curve, which can be represented as Y. The generation process of Y may be: the KMS selects a random number y, and then calculates Y according to the following formula: In this embodiment, the second transfer parameter can be expressed as C2: C2 = HashtoPoint(PW) + Y. A fourth elliptic parameter is introduced during the calculation of the second transfer parameter. The fourth elliptic parameter is the coordinate value corresponding to any point on the elliptic curve. Therefore, the fourth elliptic parameter has randomness. Introducing the fourth elliptic parameter during the calculation of the second transfer parameter makes the second transfer parameter random and unpredictable.

[0157] As a feasible implementation method, KMS can connect the vehicle ID and the second transmitted parameters to obtain intermediate parameters.

[0158] In this implementation, the intermediate parameters can be calculated as follows: W = Vehicle ID || C2.

[0159] In this implementation, a second transmission parameter and a vehicle ID are introduced during the calculation of intermediate parameters. The vehicle ID uniquely identifies the vehicle, ensuring that the generated intermediate parameters are vehicle-specific. The second transmission parameter is random and unpredictable, thus the generated intermediate parameters are also random and unpredictable. The first vehicle key calculated using this intermediate parameter is also random and unpredictable. When the terminal and vehicle communicate using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0160] As one feasible approach, the user ID, component ID, first transmission parameter, and second transmission parameter are connected to obtain intermediate parameters.

[0161] In this implementation, the first set of interactive parameters sent by the terminal may include {curve parameters, user ID, component ID, P, C1}.

[0162] In this implementation, the intermediate parameters can be calculated as follows: W = User ID || Component ID || C1 || C2.

[0163] In this implementation, a user ID, a component ID, a first transmission parameter, and a second transmission parameter are introduced during the calculation of intermediate parameters. The component ID uniquely identifies the ECU, allowing for the generation of different intermediate parameters for different ECUs. Furthermore, the user ID uniquely identifies the terminal, ensuring that the generated intermediate parameters correspond to the terminal. Moreover, the first and second transmission parameters are random and unpredictable, thus the generated intermediate parameters are also random and unpredictable. The first vehicle key calculated using these intermediate parameters is also random and unpredictable. During communication between the terminal and the vehicle using this first vehicle key, replay attacks can be prevented, resulting in high communication security.

[0164] As one feasible approach, the user ID, component ID, vehicle ID, first transmission parameter, and second transmission parameter are connected to obtain intermediate parameters.

[0165] In this implementation, the first set of interactive parameters sent by the terminal may include {curve parameters, user ID, component ID, P, C1}.

[0166] In this implementation, the intermediate parameters can be calculated as follows: W = User ID || Component ID || Vehicle ID || C1 || C2.

[0167] In this implementation, a user ID, component ID, vehicle ID, a first transmission parameter, and a second transmission parameter are introduced during the calculation of intermediate parameters. The component ID uniquely identifies the ECU, allowing for the generation of different intermediate parameters for different ECUs. Similarly, the user ID uniquely identifies the terminal, ensuring the generated intermediate parameters correspond to the terminal; the vehicle ID uniquely identifies the vehicle, ensuring the generated intermediate parameters correspond to the vehicle. Furthermore, the first and second transmission parameters are random and unpredictable, resulting in random and unpredictable intermediate parameters. The first vehicle key calculated using these intermediate parameters is also random and unpredictable. This first vehicle key prevents replay attacks during communication between the terminal and the vehicle, resulting in high communication security.

[0168] It is worth noting that this embodiment is merely an exemplary description of several implementation methods for calculating intermediate parameters based on identification parameters and / or vehicle ID and / or first transmission parameters and / or second transmission parameters. The above implementation methods are not intended to be limiting. In practical applications, parameters participating in the intermediate parameter calculation can be flexibly selected according to requirements to achieve a flexible encryption process.

[0169] Please continue reading. Figure 9 To further enhance the security of communication between the terminal and the vehicle, based on the technical solution provided in the above embodiments, KMS is also configured to perform the following steps:

[0170] In S92, KMS uses intermediate parameters to encrypt the master key to obtain the encryption key.

[0171] In this embodiment, KMS can use the intermediate parameters and the master key to generate a tuple. For example: (intermediate parameters, master key), or (master key, intermediate parameters). During the generation of the tuple, KMS can pre-set the position of each element in the tuple.

[0172] Subsequently, the tuple is encrypted using a key generation algorithm to generate an encryption key. In this implementation, the key length and format of the output encryption key can be preset. For example, the key format can be determined to be "JMKey:", and the key length of the output encryption key can be determined to be a 32-bit string. Furthermore, the encryption key generation algorithm can be a common key generation algorithm in related technologies, such as DES (Data Encryption Standard), KDF (Key Derivation Function), AEAD (Authenticated Encryption with Associated Data), etc.

[0173] In this embodiment, KMS uses intermediate parameters to perform secondary encryption on the master key to obtain the encryption key. Because the intermediate parameters are random and unpredictable, the resulting encryption key is also random and unpredictable. Furthermore, even if the communication between the terminal and the vehicle is maliciously attacked, the encryption key will be the first key attacked; therefore, the encryption key provides a certain degree of protection for the master key.

[0174] In S53, KMS uses encryption parameters to encrypt the shared key and obtain the first vehicle key.

[0175] In this embodiment, the PSK (pre-shared key) is a randomly generated string; the terminal and KMS can determine whether the other party's identity is legitimate, i.e. whether they can communicate, by judging whether the other party possesses the same shared key.

[0176] In this embodiment, KMS can generate tuples using encryption parameters and a shared key. For example: (master key, shared key), (encryption key, shared key, intermediate parameters), (shared key, master key, intermediate parameters). During the tuple generation process, KMS can pre-set the position of each element in the tuple.

[0177] Subsequently, the aforementioned tuple is encrypted using a key generation algorithm to generate an encrypted first vehicle key. In this embodiment, the key length and key format of the output encrypted first vehicle key can be preset. For example, the key format can be determined to be "CARKey:", and the key length of the output first vehicle key can be determined to be a 32-bit string. Furthermore, the key generation algorithm for the encrypted first vehicle key can be a common key generation algorithm in related technologies, such as the DES algorithm, KDF algorithm, AEAD algorithm, etc.

[0178] In S54, KMS sends a second set of interactive parameters to the terminal.

[0179] In this embodiment, the second set of interaction parameters includes at least the first vehicle key. In some feasible implementations, the second set of interaction parameters further includes a second subset, which includes at least one interaction parameter that participates in the calculation of the encryption parameters but is not recorded in the terminal.

[0180] In this embodiment, if all parameters involved in the encryption parameter calculation are stored in the terminal, then the second set of interaction parameters sent by KMS to the terminal contains only the first vehicle key. The following example illustrates an application scenario where the second set of interaction parameters sent by KMS contains only the first vehicle key.

[0181] In one feasible embodiment, the first vehicle key can be represented as C3, where C3 = AEAD(MK, W||PSK). Here, MK = X||HashtoPoint(PW), and W = User ID||C1. In this embodiment, the encryption parameters include MK and W. The parameters involved in the encryption parameter calculation include X, PW, User ID, and C1. Since X, PW, User ID, and C1 are all stored in the terminal, in this embodiment, the second set of interaction parameters sent by KMS to the terminal only contains the first vehicle key C3.

[0182] In one feasible embodiment, the first vehicle key can be represented as C3, where C3 = AEAD(K, W||PSK). Here, K = KDF(MK, W), MK = X||HashtoPoint(PW), and W = User ID||Component ID||C1. In this embodiment, the encryption parameters include K and W. The parameters involved in the encryption parameter calculation include X, PW, User ID, Component ID, and C1. Since X, PW, User ID, Component ID, and C1 are all stored in the terminal, in this embodiment, the second set of interaction parameters sent by KMS to the terminal only contains the first vehicle key C3.

[0183] It is worth noting that this application merely illustrates two application scenarios where the second interaction parameter set sent by KMS contains only the first vehicle key, and these application scenarios are not intended to be limiting. In practical applications, encryption parameters can be flexibly configured according to requirements, and correspondingly, the parameters included in the second interaction parameter set also need to be adjusted based on the encryption parameters.

[0184] In this embodiment, if some parameters involved in the encryption parameter calculation are not recorded in the terminal, the second set of interaction parameters sent by KMS to the terminal includes the first vehicle key and the second subset. The application scenario of the second set of interaction parameters including the first vehicle key and the second subset is illustrated below with specific examples.

[0185] In one feasible embodiment, the first vehicle key can be represented as C3, C3 = AEAD(MK, W||PSK), where MK = X||HashtoPoint(PW), and W = User ID||C1||Vehicle ID. In this embodiment, the encryption parameters include MK and W, and the parameters involved in the encryption parameter calculation include X, PW, User ID, C1, and Vehicle ID. X, PW, User ID, and C1 are stored in the terminal, while the Vehicle ID is not stored in the terminal. Therefore, in this embodiment, the second set of interaction parameters sent to the terminal includes the first vehicle key C3 and a second subset, wherein the second subset includes the Vehicle ID.

[0186] In one feasible embodiment, the first vehicle key can be represented as C3, where C3 = AEAD(K, W||PSK). Here, K = KDF(MK, W), MK = X||HashtoPoint(PW), W = User ID||Component ID||C1||Vehicle ID||C2, and C2 = HashtoPoint(PW) + Y. In this embodiment, the encryption parameters include K and W, and the parameters involved in the encryption parameter calculation include X, PW, User ID, Component ID, C1, C2, and Vehicle ID. X, PW, User ID, Component ID, and C1 are stored in the terminal, while Vehicle ID and C2 are not stored in the terminal. Therefore, in this embodiment, the second set of interaction parameters sent to the terminal includes the first vehicle key C3 and a second subset, where the second subset includes Vehicle ID and C2.

[0187] It is worth noting that this application merely illustrates two application scenarios where the second set of interaction parameters sent by KMS includes the first vehicle key and the second subset, and these application scenarios do not constitute a limitation. In practical applications, encryption parameters can be flexibly configured according to requirements, and correspondingly, the parameters included in the second set of interaction parameters also need to be adjusted based on the encryption parameters.

[0188] The method for establishing secure vehicle communication provided in this embodiment is applicable to a vehicle's KMS. The KMS can generate encrypted parameters based on the parameters contained in the first set of interactive parameters sent by the terminal; then, it uses the encrypted parameters to encrypt a shared key to obtain a first vehicle key; finally, it sends a second set of interactive parameters containing the first vehicle key to the terminal, enabling the terminal to decrypt the first vehicle key to obtain the shared key. This allows the terminal and KMS to use the shared key to encrypt and / or protect the integrity of the transmitted data.

[0189] Furthermore, the method provided in this application can achieve secure end-to-end data transmission. The data can include control flow and data flow. For example, the data can include remote interactive data such as remote configuration, remote control, and remote diagnostics. The data can also include data such as facial recognition, fingerprints, passwords, keys, and certificates registered and configured by external application terminals; and data can also include data from in-vehicle audio, images, and sensor monitoring accessed by the terminal.

[0190] Furthermore, the method provided in this application is not bound to the underlying protocol and can support multiple underlying protocols.

[0191] This embodiment also provides a method for establishing vehicle safety communication. The method is applicable to terminals and will be referred to below. Figure 11 The following is a detailed explanation of the steps involved in establishing vehicle safety communication using a terminal in an embodiment of this application:

[0192] In S111, the terminal receives the second set of interactive parameters provided in this embodiment;

[0193] In this embodiment, the second set of interaction parameters includes at least the first vehicle key. In some feasible implementations, the second set of interaction parameters further includes a second subset, which includes at least one interaction parameter that participates in the calculation of the encryption parameters but is not recorded in the terminal.

[0194] In S112, the terminal decrypts the first vehicle key to obtain the encryption parameters and the shared key;

[0195] In this embodiment, the encryption parameters participating in the calculation of the first vehicle key are either pre-stored in the terminal or included in the second set of interaction parameters and sent to the terminal via KMS. Therefore, after receiving the second set of interaction parameters, the terminal can obtain all the encryption parameters participating in the calculation of the first vehicle key. The terminal can decrypt the first vehicle key to obtain the shared key. The decryption of the first vehicle key can be implemented using decryption methods in the art, and no further limitations are imposed here.

[0196] In S113, the terminal uses encryption parameters to encrypt the shared key to obtain the second vehicle key, or uses encryption parameters to generate the second vehicle key.

[0197] The method for generating the second vehicle key is explained below.

[0198] As a feasible implementation, the terminal can generate a second vehicle key using all the encryption parameters. For example, in one feasible embodiment, the encryption parameters involved in generating the first vehicle key include: vehicle ID, C2, and C3. The terminal can use vehicle ID, C2, and C3 to generate a second vehicle key. For example, the second vehicle key = AEAD(vehicle ID||C2||C3).

[0199] As a feasible implementation, the terminal can generate a second vehicle key using some of the encryption parameters. For example, in one feasible embodiment, the encryption parameters involved in generating the first vehicle key include: vehicle ID, C2, and C3. The terminal can use vehicle ID and C3 to generate the second vehicle key. For example, the second vehicle key = AEAD(vehicle ID||C3).

[0200] As a feasible implementation, the terminal can generate a second vehicle key using the shared key and all encryption parameters. For example, in one feasible embodiment, the encryption parameters involved in generating the first vehicle key include: vehicle ID, C2, and C3. The terminal can use the vehicle ID, C2, C3, and the shared key to generate the second vehicle key, for example, second vehicle key = AEAD(vehicle ID||C2||C3||shared key).

[0201] As a feasible implementation, the terminal can generate a second vehicle key using a shared key and some encryption parameters. For example, in one feasible embodiment, the encryption parameters involved in generating the first vehicle key include: vehicle ID, C2, and C3. The terminal can use the vehicle ID, C3, and the shared key to generate the second vehicle key. For example, the second vehicle key = AEAD(vehicle ID||C3||shared key).

[0202] This application merely illustrates several methods for generating a second vehicle key. The above methods are not intended to limit the scope of the application. In practical applications, the parameters used to generate the second vehicle key can be flexibly selected according to the requirements.

[0203] In S114, the second vehicle key is sent to the vehicle.

[0204] The method for establishing secure vehicle communication provided in this embodiment is applicable to a terminal. The terminal can decrypt a first vehicle key sent by the vehicle to obtain encryption parameters and a shared key. Then, it uses the encryption parameters to encrypt the shared key to obtain a second vehicle key. Finally, it sends the second vehicle key to the vehicle, enabling the vehicle to decrypt the second vehicle key using its internally stored encryption parameters to obtain the shared key and / or encryption parameters. The vehicle can compare the decrypted second vehicle key and / or encryption parameters with its own stored shared key and / or encryption parameters. If they match, decryption is successful. In the case of successful decryption, the terminal and the vehicle can use the shared key to encrypt and / or protect the integrity of the transmitted data.

[0205] This embodiment provides a system for establishing vehicle safety communication. For details, please refer to [link / reference needed]. Figure 12 , Figure 12This is a structural block diagram of a system for establishing vehicle safety communication provided in this embodiment. The system includes a vehicle 121 and a terminal 122.

[0206] Vehicle 121 includes KMS1211 and ECU1212. KMS1211 is used for execution... Figures 5-10 The provided method allows the ECU1212 to securely communicate with a terminal using a shared key sent by the KMS1211. The terminal is used to execute the provided... Figure 11 The methods provided.

[0207] This application provides a secure communication system, including:

[0208] A first application installed on the vehicle is configured to implement the instructions when executing them. Figures 5-10 The methods provided;

[0209] A second application installed on the terminal, configured to execute the instructions. Figure 11 The methods provided.

[0210] The operation process of the above system will be described below with reference to the specific accompanying drawings. Figure 13 The interaction flowchart between the terminal and the vehicle provided for a feasible embodiment shows that:

[0211] In this embodiment, the terminal selects a key negotiation algorithm and an elliptic curve. Once the elliptic curve is selected, its curve parameters are determined. A random number x is selected, and a base point P is chosen on the elliptic curve. The terminal calculates the first elliptic parameter according to the following formula. The first transmission parameter C1 is calculated according to the following formula: C1 = HashtoPoint(PW) + X. Then, the terminal sends the first set of interaction parameters to KMS. In this embodiment, the first parameter set includes {curve parameter, user ID, component ID, P, C1}.

[0212] KMS receives the first set of interaction parameters, selects an elliptic curve based on the curve parameters, and chooses a random parameter y; KMS calculates the fourth elliptic parameter according to the following formula. The second transfer parameter C2 is calculated using the following formula: C2 = HashtoPoint(PW) + Y; the first elliptic parameter X is calculated using the following formula: X = C1 - HashtoPoint(PW); the master key is calculated using the following formula. ||HashtoPoint(PW); Calculate the intermediate parameter W according to the following formula: W = User ID || Component ID || Vehicle ID || C1 || C2; Calculate the encryption key K according to the following formula: K = KDF(MK, W); Calculate the first vehicle key C3 according to the following formula: C3 = AEAD(K, W || PSK). KMS sends the second set of interaction parameters to the terminal. In this embodiment, the second set of interaction parameters includes: {C3, Vehicle ID, C2}.

[0213] The terminal receives the second set of interaction parameters and calculates the fourth elliptic parameter Y according to the following formula: Y = C2 - HashtoPoint(PW); calculates the master key MK according to the following formula: MK = x°Y||HashtoPoint(PW); calculates the intermediate parameter W according to the following formula: W = User ID||Component ID||Vehicle ID||C1||C2; calculates the encryption key K according to the following formula: K = KDF(MK, W); then the terminal uses K and W to decrypt C3 to obtain the PSK and stores the PSK. Next, the terminal uses the following formula to encrypt the PSK to obtain the second vehicle key C4: C4 = AEAD(K, W||C1||C2||C3). Finally, the terminal sends C4 to KMS.

[0214] KMS receives C4 and decrypts it. If decryption is successful, KMS sends PSK to ECU so that the terminal and ECU can use PSK to encrypt and / or protect the integrity of the transmitted data.

[0215] Embodiments of this application provide a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0216] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, static random access memory, portable compact disk read-only memory, digital multifunction disks (DMDs), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0217] The computer-readable program instructions or code described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0218] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture instructions, machine instructions, machine-dependent instructions, microcode firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages. Programming languages ​​include object-oriented programming languages—such as Smalltalk, C++, etc.—and conventional procedural programming languages—such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer may be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, FPGAs (Field-Programmable Gate Arrays), or PLAs (Programmable Logic Arrays), are personalized by utilizing state information from computer-readable program instructions. These electronic circuits can execute computer-readable program instructions to implement various aspects of this application.

[0219] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0220] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0221] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0222] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.

[0223] It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, can be implemented using hardware (such as circuits or ASICs (Application Specific Integrated Circuits)) that performs the corresponding function or action, or using a combination of hardware and software, such as firmware.

[0224] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, the disclosure, and the appended claims in carrying out the claimed invention. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce a good effect. Various embodiments of this application have been described above. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market of the embodiments, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for establishing vehicle secure communication, the method being applicable to vehicles, characterized in that, include: The system receives a first set of interaction parameters, which is a set of parameters sent by the terminal to the vehicle when the terminal requests data interaction with the vehicle. The first set of interaction parameters includes: curve parameters, base points, and a first transmission parameter. The curve parameters are parameters used to uniquely determine the elliptical curve. The first transmission parameter is a parameter obtained by adding a first elliptical parameter and a second elliptical parameter. The first elliptical parameter is the coordinate value of any point on the elliptical curve, and the second elliptical parameter is the elliptical parameter obtained by hashing the user password onto the elliptical curve. An encrypted parameter set is generated based on the parameters contained in the first interactive parameter set, wherein the encrypted parameter set includes at least one encrypted parameter; The shared key is encrypted using the encryption parameters to obtain the first vehicle key, wherein the shared key is a randomly generated string. A second set of interaction parameters is sent to the terminal. The second set of interaction parameters includes at least the first vehicle key. The first vehicle key is used to be decrypted by the terminal to obtain the shared key. The shared key is used by the terminal and the vehicle to encrypt and / or protect the integrity of the sent data.

2. The method according to claim 1, characterized in that, The first set of interaction parameters further includes a first subset, which includes at least one identifier parameter, including a user ID and / or a component ID.

3. The method according to claim 1, characterized in that, The second set of interaction parameters further includes a second subset, which includes at least one interaction parameter that is a parameter that participates in the calculation of the encryption parameter and is not recorded in the terminal.

4. The method according to claim 1, characterized in that, The step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set includes: The first ellipse parameter is obtained by subtracting the first transfer parameter from the second ellipse parameter. The master key is obtained by connecting the first ellipse parameter and the second ellipse parameter. The user password is pre-stored in the vehicle. The ellipse curve is a curve selected according to the curve parameter.

5. The method according to claim 1, characterized in that, The step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set includes: The first transmission parameter and the second ellipse parameter are subtracted by a point to obtain the first ellipse parameter. The user password is pre-stored in the vehicle. The ellipse curve is a curve selected according to the curve parameter. The first ellipse parameter is multiplied by the random parameter to obtain the third ellipse parameter, wherein the random parameter is a randomly generated parameter; By connecting the third elliptic parameter and the second elliptic parameter, the master key is obtained.

6. The method according to claim 4 or 5, characterized in that, The step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set further includes: An intermediate parameter is calculated based on the identification parameter and / or the vehicle ID and / or the first transmission parameter and / or the second transmission parameter, wherein the vehicle ID is pre-stored in the vehicle and the second transmission parameter is a parameter calculated based on the parameters in the first set of interaction parameters.

7. The method according to claim 6, characterized in that, The calculation process for the second transfer parameter is as follows: Select an elliptic curve based on the curve parameters; The user password is hashed onto the elliptic curve to obtain the second ellipse parameter; The second ellipse parameter and the fourth ellipse parameter are added together to obtain the second transfer parameter, where the fourth ellipse parameter is the coordinate value of any point on the elliptic curve.

8. The method according to claim 6, characterized in that, The step of generating an encrypted parameter set based on the parameters contained in the first interaction parameter set further includes: The master key is encrypted using the intermediate parameters to obtain the encryption key.

9. The method according to claim 6, characterized in that, The step of calculating intermediate parameters based on identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically involves: Connect the user ID and component ID to obtain intermediate parameters.

10. The method according to claim 6, characterized in that, The step of calculating intermediate parameters based on identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically involves: By connecting the user ID, component ID, and the first transmitted parameter, intermediate parameters are obtained.

11. The method according to claim 6, characterized in that, The step of calculating intermediate parameters based on identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically involves: By connecting the user ID, component ID, the first transmission parameter, and the second transmission parameter, intermediate parameters are obtained.

12. The method according to claim 6, characterized in that, The step of calculating intermediate parameters based on identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically involves: Intermediate parameters are obtained by connecting the user ID, component ID, vehicle ID, first transmission parameter, and second transmission parameter.

13. The method according to claim 6, characterized in that, The step of calculating intermediate parameters based on identification parameters and / or vehicle ID and / or the first transmission parameter and / or the second transmission parameter specifically involves: By connecting the vehicle ID and the second transmitted parameter, intermediate parameters are obtained.

14. A method for establishing vehicle safety communication, the method being applicable to a terminal, characterized in that, include: The system receives a second set of interaction parameters, which includes at least a first vehicle key generated based on encryption parameters and a shared key. The encryption parameters are generated based on the first set of interaction parameters, which includes curve parameters, a base point, and a first transmission parameter. The curve parameters are parameters used to uniquely determine an elliptic curve. The first transmission parameter is a parameter obtained by adding a first elliptic parameter and a second elliptic parameter. The first elliptic parameter is the coordinate value of any point on the elliptic curve, and the second elliptic parameter is the elliptic parameter obtained by hashing the user password onto the elliptic curve. Decrypt the first vehicle key to obtain the encryption parameters and the shared key; The shared key is encrypted using the encryption parameters to obtain a second vehicle key, or a second vehicle key is generated using the encryption parameters. The second vehicle key is sent to the vehicle, and the second vehicle key is used to be decrypted by the vehicle to obtain the shared key. The shared key is used by the terminal and the vehicle to encrypt and / or protect the integrity of the sent data.

15. A vehicle, characterized in that, Includes a key management system, the key management system comprising: The processor and memory used to store processor-executable instructions; The processor is configured to implement the method according to any one of claims 1-13 when executing the instructions.

16. A terminal, characterized in that, include: The processor and memory used to store processor-executable instructions; The processor is configured to implement the method of claim 14 when executing the instructions.

17. A secure communication system, characterized in that, include: A vehicle configured to implement the method of any one of claims 1-13 when executing instructions; A terminal configured to implement the method of claim 14 when executing instructions.

18. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method of any one of claims 1-13, or the method of claim 14.

19. A computer program product, characterized in that, When it is run on a computer, it causes the computer to perform the method of any one of claims 1-13, or the method of claim 14.

Images