WO2021196043A1 - 一种安全通信的方法及装置 - Google Patents

一种安全通信的方法及装置 Download PDF

Info

Publication number
WO2021196043A1
WO2021196043A1 PCT/CN2020/082614 CN2020082614W WO2021196043A1 WO 2021196043 A1 WO2021196043 A1 WO 2021196043A1 CN 2020082614 W CN2020082614 W CN 2020082614W WO 2021196043 A1 WO2021196043 A1 WO 2021196043A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
fleet
negotiation
message
certificate
Prior art date
Application number
PCT/CN2020/082614
Other languages
English (en)
French (fr)
Inventor
陈幼雷
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN202080004876.7A priority Critical patent/CN112640504B/zh
Priority to JP2022558490A priority patent/JP7464337B2/ja
Priority to EP20928311.8A priority patent/EP4117225A4/en
Priority to PCT/CN2020/082614 priority patent/WO2021196043A1/zh
Publication of WO2021196043A1 publication Critical patent/WO2021196043A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H04W12/0471—Key exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/005—Moving wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • This application relates to the field of automatic driving technology, and in particular to a method and device for safe communication.
  • V2X vehicle to everything
  • V2X is based on an open wireless communication network, which is easier than traditional networks Being attacked will also cause greater damage to the field of vehicle formation based on V2X communication. Therefore, in the scene of autonomous driving vehicles in formation, higher requirements are put forward for the safety of V2X communication.
  • the present application provides a method and device for safe communication, which are used to realize safe communication between team members during group driving in the field of autonomous driving.
  • This method can be implemented by a terminal device, for example, a vehicle or a vehicle-mounted device (for example, a vehicle-mounted T-BOX (Telematics BOX)), or can be implemented by a component of a terminal device, such as a processing device, circuit, chip, etc. in the terminal device
  • a chip related to the wireless communication function in the T-BOX such as a system chip or a communication chip.
  • the system chip is also called system-on-chip, or SoC chip.
  • the communication chip may include a radio frequency processing chip and a baseband processing chip.
  • the baseband processing chip is sometimes called a modem.
  • the communication chip can be integrated inside the SoC chip or not integrated with the SoC chip.
  • the baseband processing chip is integrated in the SoC chip, and the radio frequency processing chip is not integrated with the SoC chip.
  • an embodiment of the present application provides a method for secure communication.
  • the method includes: a first vehicle receives a first message from a first terminal device, and the first message is used to indicate that the first vehicle is in a fleet of vehicles. Number, send a first negotiation message, the first negotiation message includes the first negotiation parameter of the first vehicle, the number of the first vehicle in the fleet and the certificate of the first vehicle, and receive the first negotiation message from the second vehicle The first negotiation message of the second vehicle; wherein the second vehicle is a vehicle other than the first vehicle in the fleet, and the first negotiation message of the second vehicle includes the first negotiation of the second vehicle Parameters, the number of the second vehicle in the fleet and the certificate of the second vehicle; and after the certificate of the vehicle adjacent to the number of the first vehicle in the fleet is verified, according to the and
  • the first negotiation parameters of the vehicles with adjacent numbers of the first vehicle in the fleet determine the second negotiation parameters; a second negotiation message is sent, and the second negotiation message includes the second negotiation parameters and the first vehicle The number in the fleet and the certificate of
  • the second vehicle may be a vehicle other than the first vehicle in the fleet, or multiple other vehicles, or any other vehicle.
  • the identity information of the vehicles is verified through the certificates carried in the first negotiation message and the second negotiation message used to determine the group key.
  • the identity information of each vehicle is verified, which shortens the time delay for verifying the member vehicles of the fleet during the formation of the fleet, improves the security and reliability in the group key negotiation process, and realizes the inside of the fleet. Secure communication between member vehicles.
  • the first negotiation message of the second vehicle further includes first signature data; wherein, the first signature data uses the second negotiation parameter and the second vehicle in the The number of the fleet is obtained by the signature operation.
  • the first vehicle after the first vehicle has passed the verification of the certificate of the second vehicle, it can also verify the first signature data, avoiding tampering with the first negotiation message during the transmission process, and further improving the security of the group key negotiation process Sex and reliability.
  • the first vehicle is in accordance with the number of the first vehicle in the fleet
  • Determining the second negotiation parameters by the first negotiation parameters of the vehicles with adjacent numbers in the numbered vehicle includes: after the certificate verification of the second vehicle is passed and the first signature data is verified, the first vehicle is based on The first negotiation parameter of the vehicle adjacent to the number of the first vehicle in the fleet determines the second negotiation parameter.
  • the certificate of the second vehicle contains the public key of the second vehicle; the first vehicle verifies the first signature data in the following manner: the first vehicle uses the The public key of the second vehicle decrypts the first signature data to obtain a first digital digest, and uses the second negotiation parameters of the second vehicle and the number of the second vehicle in the fleet, The first value is determined based on the preset digest algorithm; when it is verified that the second digital digest is consistent with the first value, the first signature data verification passes, otherwise, the first signature data verification fails.
  • the second negotiation message of the second vehicle further includes second signature data; wherein, the second signature data uses the second negotiation parameter and the second vehicle The number is obtained from the signature operation.
  • the first vehicle receives the second negotiation message.
  • the second signature data can also be verified to avoid the transmission of the second negotiation message. It has been tampered with, which enhances the security and reliability of the group key negotiation process.
  • the first vehicle after the certificate verification of the second vehicle is passed, the first vehicle generates a connection with any vehicle in the fleet according to the second negotiation parameters of each of the second vehicles.
  • the group key for secure communication includes: after the certificate verification of the second vehicle is passed, and the second signature data is verified, the first vehicle is in accordance with the second negotiation of each of the second vehicles.
  • the parameter generates the group key.
  • the certificate of the second vehicle includes the public key of the second vehicle; the first vehicle verifies the second signature data in the following manner: the first vehicle uses the public key of the second vehicle The key decrypts the second signature data to obtain a second digital digest, and uses the second negotiation parameter of the second vehicle and the number of the second vehicle in the fleet, which is determined based on the preset digest algorithm A second value; when the first digital digest is consistent with the second value, the verification of the second signature data passes, otherwise, the verification of the second signature data fails.
  • the first message includes a negotiation request field, vehicle information of the fleet, third signature data, and a certificate of the first device that sent the first message; wherein, the negotiation request The field is used to trigger the vehicles in the fleet to send the first negotiation message; the vehicle information of the fleet includes the vehicle identification of each vehicle in the fleet and the number of the vehicle in the fleet corresponding to the vehicle identification;
  • the third signature data is obtained by encrypting a third digital digest using the private key of the first terminal device, and the third digital digest is obtained by using the negotiation request field and the vehicle information of the fleet, based on The preset digest algorithm is determined.
  • the certificate of the first terminal device includes the public key of the first terminal device; after the first vehicle receives the first message, it further includes: after the certificate verification of the first terminal device is passed, and the first vehicle After the verification of the three-signature data certificate is passed, the first vehicle determines the number corresponding to its own vehicle identification according to the vehicle information of the fleet.
  • the method further includes: the first vehicle uses a first random number generated by itself to obtain the first negotiation parameter based on a first preset algorithm calculation.
  • determining the second negotiation parameter by the first vehicle according to the second negotiation parameter of the second vehicle includes: the first vehicle uses a first random number generated by itself and the first vehicle 2. The first negotiation parameter of the vehicle is calculated based on a second preset algorithm to obtain the second negotiation parameter.
  • the first vehicle generates a group key for secure communication with any vehicle in the fleet according to the second negotiation parameters of each of the second vehicles, including: the first vehicle The vehicle uses the first random number generated by itself, the second negotiation parameter of the second vehicle, and the second negotiation parameter of the second vehicle whose number is located after the number of the first vehicle in the fleet, based on the third prediction Suppose an algorithm operation is used to obtain the group key.
  • each vehicle in the fleet generates a group key based on the third preset algorithm according to its own random number and the second negotiation parameters of other vehicles. Since the random number of each vehicle does not need to be transmitted, the security is higher. Even if the second negotiation message is acquired by other vehicles, the group key cannot be calculated.
  • the group key negotiation process of the embodiment of the present application is simpler, the amount of calculation is small, and the security is higher.
  • the method further includes: before the first vehicle sends data to any vehicle in the fleet, encrypting the data that needs to be interacted with using the group key, and encrypting the encrypted data The data of is sent to the target vehicle; and/or after the first vehicle receives the data from any vehicle in the fleet, the group key is used to decrypt the received data.
  • an embodiment of the present application provides a method for secure communication.
  • the method includes: a first terminal device obtains vehicle information of a fleet from an application server, and the vehicle information of the fleet includes the vehicle identification of each vehicle in the fleet The number of the vehicle in the vehicle fleet corresponding to the vehicle identifier; the first terminal device sends a first message to each vehicle in the vehicle fleet, and the first message includes a negotiation request field and the vehicle fleet The vehicle information, the third signature data, and the certificate of the first device that sent the first message; wherein the negotiation request field is used to trigger the vehicles in the fleet to send the first negotiation message; the vehicle information of the fleet Including the vehicle identification of each vehicle in the fleet and the number of the vehicle in the fleet corresponding to the vehicle identification; the third signature data is the use of the private key of the first terminal device, and the third number
  • the abstract is obtained through encryption, and the third digital abstract is determined based on the preset abstract algorithm using the negotiation request field and the vehicle information of the fleet.
  • the method further includes: the first terminal device receives a first negotiation message from any other vehicle in the fleet; and the first terminal device sends the first data packet to the Any other vehicle in the fleet, the first data packet includes the first negotiation message of any vehicle in the fleet; and/or the first terminal device receives the first negotiation message from any other vehicle in the fleet 2.
  • negotiation message The first terminal device sends a second data packet to any other vehicle in the fleet, and the second data packet contains a second negotiation message for any vehicle in the fleet.
  • the first terminal device is any numbered vehicle in the fleet, or the first terminal device is a roadside device RSU.
  • the embodiments of the present application provide a terminal device that has the function of implementing the method described in the first aspect.
  • the function can be implemented by hardware, software, or hardware execution of corresponding software.
  • the device includes one or more modules corresponding to the above-mentioned functions, such as a transceiver unit and a processing unit.
  • the device can be a chip or an integrated circuit.
  • the device includes a memory, a processor, and a transceiver.
  • the transceiver is used to receive and send data.
  • the memory is used to store programs or instructions executed by the processor. When the programs or instructions are executed by the processor, The device can execute the above-mentioned first aspect and the methods involved in various possible designs in the first aspect.
  • the device could be a vehicle.
  • the embodiments of the present application provide a terminal device that has the function of implementing the method described in the second aspect.
  • the function can be implemented by hardware, or by software, or by hardware executing corresponding software.
  • the device includes one or more modules corresponding to the above-mentioned functions, such as a transceiver unit and a processing unit.
  • the device can be a chip or an integrated circuit.
  • the device includes a memory, a processor, and a transceiver.
  • the transceiver is used to receive and send data.
  • the memory is used to store programs or instructions executed by the processor. When the programs or instructions are executed by the processor, The device can execute the above-mentioned first aspect and the methods involved in various possible designs in the first aspect.
  • the device could be a vehicle or RSU.
  • an embodiment of the present application provides a device that includes a processor, a memory, and a communication interface, the communication interface is used to receive signals or send signals; the memory is used to store programs or instruction codes; The processor is configured to call the program or instruction code from the memory to execute the methods involved in the various possible designs as in the first aspect and the first aspect or to execute the methods as in the second aspect and the second aspect The methods involved in the various possible designs.
  • an embodiment of the present application provides a device.
  • the communication device includes a processor and an interface circuit.
  • the interface circuit is configured to receive a program or instruction code and transmit it to the processor;
  • the program or instruction code is used to execute the methods related to the various possible designs in the first aspect and the first aspect or to execute the methods related to the various possible designs in the second aspect and the second aspect.
  • the present application provides a device, which may be a terminal device or a chip for the terminal device.
  • the device has the function of realizing each embodiment of the first aspect or the second aspect described above. This function can be realized by hardware, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • an embodiment of the present application provides a computer-readable storage medium, where the computer-readable storage medium is used to store a program or instruction, and when the program or instruction is executed, the first aspect and the first aspect thereof.
  • embodiments of the present application provide a computer program product including instructions, which when executed, enable the methods involved in the first aspect and various possible designs in the first aspect, or the second aspect And the methods involved in the various possible designs in the second aspect are implemented.
  • an embodiment of the present application also provides a secure communication system, including: an application server, a first terminal device, and a secure communication device.
  • the secure communication device can perform the first aspect or any one of the first aspects.
  • the first terminal device can perform the corresponding function in the second aspect or any one of the possible implementation manners of the second aspect.
  • FIG. 1 is a schematic diagram of a system architecture provided by an embodiment of the application
  • FIG. 2 is a schematic diagram of another system architecture provided by an embodiment of the application.
  • FIG. 3 is a schematic flowchart of a secure communication method provided by an embodiment of this application.
  • FIG. 5 is a schematic flowchart of a method for secure communication according to Embodiment 2 of this application;
  • FIG. 6 is a schematic diagram of the first round of broadcast scenarios in the group key agreement process provided in the second embodiment of the application.
  • FIG. 7 is a schematic diagram of the second round of broadcast scenarios in the group key agreement process provided in Embodiment 2 of this application;
  • FIG. 8 is a schematic flowchart of another secure communication method provided in Embodiment 3 of this application.
  • FIG. 9 is a schematic structural diagram of a secure communication device provided by an embodiment of this application.
  • FIG. 10 is a schematic structural diagram of a secure communication device provided by an embodiment of this application.
  • Fig. 1 exemplarily shows a schematic diagram of a system architecture to which an embodiment of the present application is applicable.
  • the system architecture includes network equipment and terminal equipment groups.
  • the terminal device group includes at least two terminal devices. At least two terminal devices can form a terminal device group.
  • the terminal device group can include a master terminal device. Terminal devices other than the master terminal device can be called slave devices. .
  • Network equipment is mainly used to store equipment information of terminal equipment, communicate and interact with terminal equipment, form terminal equipment groups, and formulate numbers for terminal equipment in the terminal equipment groups.
  • the terminal device may be a device with wireless transceiver function.
  • the appearance of terminal equipment is also different.
  • the terminal device may be a mobile phone, a tablet computer, etc.
  • terminal devices can be mobile Internet devices, wearable devices, various wireless terminals in industry or smart homes.
  • terminal devices can be vehicles, on-board units (OBU), roadside units (RSU), and roadside units in the Internet of Vehicles. Side equipment (road side equipment, RSE), on-board electronic control unit (ECU), etc.
  • the terminal device can establish a communication connection with the application server through the V2X communication network to perform communication interaction.
  • the terminal device can obtain the device information of any member terminal device in the terminal device group from the application server.
  • the terminal devices can establish a communication connection through a V2V or I2V (scene containing RSU) communication network to carry out communication interaction.
  • the master terminal device can also be used to communicate and interact with the application server, obtain information about the terminal devices in the terminal device group, and initiate a group formation request to the terminal devices in the terminal device group. After joining the terminal device group, communicate and interact with the slave device to complete the group key required for the communication and interaction between the terminal device groups.
  • the slave device can also be used to respond to the group formation request initiated by the master terminal device. After joining the terminal device group, it communicates with the master terminal device to complete the communication interaction between the terminal device groups. Group key. Between the master terminal device and the slave device, the group key can be used to encrypt the data that needs to be exchanged between the slave device and the slave device, so as to realize secure communication.
  • the device used to implement the function of the terminal device may be a terminal device, or a device capable of supporting the terminal device to implement the function, such as a chip system, and the device may be installed in the terminal device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the device used to implement the functions of the terminal is a terminal device as an example to describe the technical solutions provided in the embodiments of the present application.
  • the two terminal devices shown in FIG. 1 are only an example, and are not a limitation of the present application.
  • the network device in FIG. 1 can provide services for multiple terminal devices, and this application does not specifically limit the number of terminal devices in the communication system.
  • the architecture shown in Figure 1 can be applied to a variety of communication scenarios, for example, the fifth generation (5G) communication system, the future sixth generation communication system and other evolved communication systems, the fourth generation (the 4th generation) communication system, vehicle to everything (V2X), long-term evolution-Internet of Vehicles (LTE-vehicle, LTE-V), vehicle to vehicle (V2V), Internet of Vehicles, machine communication (machine type communications, MTC), Internet of things (IoT), long-term evolution-machine to machine (LTE-machine to machine, LTE-M), machine to machine (machine to machine, M2M) and other communication scenarios , This application does not limit this.
  • 5G fifth generation
  • the future sixth generation communication system and other evolved communication systems the fourth generation (the 4th generation)
  • the P terminal devices are a terminal device group as an example, P is an integer greater than or equal to 1, and the P terminal devices can be terminals respectively Device 1, terminal device 2, ..., terminal device P, where 1, 2, ..., P can be understood as the number assigned by the application server to the slave device in the terminal device group.
  • the P terminal devices include a master terminal device
  • the application server may set a number for the master terminal device, or not for the master terminal device. For example, if the number is not set for the master terminal device, Then the numbers of the P-1 slave devices except the master terminal device can be 1, 2, ..., P-1, respectively.
  • the network device can be an application server, and when the terminal device is a vehicle, the terminal device group can be called a fleet, the master terminal device can be called the leader car, and the slave device can be called the group member vehicle.
  • FIG. 2 is a schematic diagram of another system architecture provided by an embodiment of this application.
  • the system architecture includes an application server, a team leader vehicle and a team member vehicle, a team leader vehicle and three team member vehicles. It should be noted that the number of the leader car shown in FIG. 2 is only for illustration.
  • the leader car in the embodiment of the present application may be any numbered vehicle in the fleet, which is not limited in the embodiment of the present application.
  • Application server It is mainly used for configuration, temporary formation and maintenance of the fleet, and management of the fleet, including but not limited to: pre-configure the certificate of the managed fleet, the vehicle information of each member of the fleet, and the vehicle information of the fleet.
  • Each vehicle is assigned a vehicle number.
  • the vehicle number is a continuous and non-repeated positive integer.
  • the vehicle numbers are 1, 2, 3...n, where n is a positive integer, and each vehicle in the fleet has a different vehicle number.
  • It can also communicate with vehicles in the fleet.
  • the leader vehicle sends a request for obtaining fleet information to the application server to obtain information including the vehicle information, serial number, and certificate of each vehicle in the fleet where the leader vehicle is located.
  • the application server sends the vehicle information, serial number, certificate and other information of each vehicle in the fleet to the leader vehicle.
  • the communication method between the vehicle and the application server may be a V2X communication method.
  • the vehicle periodically reports its own location information to the application server, and the application server obtains the location information of the vehicle, and temporarily forms a fleet of vehicles based on the location information of the vehicle.
  • the application server may be a vehicle network application server (V2X application server, V2X AS).
  • V2X application server V2X AS.
  • Team leader car It is mainly used to communicate with the application server to obtain the vehicle information of any vehicle in the fleet, for example, vehicle identification, vehicle number, or vehicle certificate. It is also used to communicate with the group member vehicles, for example, the team leader car and the group member vehicle conduct a group key negotiation process, determine the group key, and use the group key for encrypted communication.
  • the leader vehicle may be any numbered or driving position vehicle in the fleet, which is not limited in the embodiment of the present application.
  • Team member vehicles mainly used to monitor the team formation request initiated by the leader car, enter the team's group key negotiation process after joining the team, determine the group key, and use the group key for encrypted communication, for example, use the group key
  • the key encrypts or decrypts the data exchanged in the vehicle fleet.
  • V2X in version (Rel)-14/15/16, V2X as a major application of device-to-device (device-to-device, D2D) technology was successfully established.
  • V2X will optimize the specific application requirements of V2X on the basis of the existing D2D technology. It is necessary to further reduce the access delay of V2X devices and solve the problem of resource conflicts.
  • V2X specifically includes several application requirements such as direct communication of V2V, V2I, and V2P, and communication interaction of V2N.
  • V2V refers to the communication between vehicles
  • V2P refers to the communication between vehicles and people (including pedestrians, cyclists, drivers, or passengers)
  • V2I refers to the communication between vehicles and network equipment, such as RSU
  • RSU includes two types: terminal type RSU, because it is located on the roadside, this terminal type RSU is in a non-mobile state, and there is no need to consider mobility; base station type RSU can provide timing synchronization for vehicles communicating with it And resource scheduling.
  • the master control terminal device may also be an RSU.
  • the RSU may or may not have a vehicle number.
  • the technical solution of the present application will be specifically introduced for this scenario below.
  • this application provides a secure communication method. As shown in FIG. 3, the method includes:
  • Step 300 The first terminal device obtains vehicle information of the fleet from the application server;
  • the vehicle information of the fleet includes the vehicle identification of each vehicle in the fleet and the number of the vehicle in the fleet corresponding to the vehicle identification.
  • Step 301 The first terminal device sends a first message to each member vehicle in the fleet;
  • the first message is used to indicate the number of the first vehicle in the fleet.
  • Step 302 The first vehicle receives the first message sent by the first terminal device
  • Step 303 The first vehicle sends a first negotiation message
  • the first negotiation message includes the first negotiation parameter of the first vehicle, the number of the first vehicle in the fleet, and the certificate of the first vehicle.
  • Step 304 The first vehicle receives the first negotiation message from the second vehicle in the fleet;
  • the second vehicle is any vehicle other than the first vehicle in the fleet.
  • the first negotiation message of the second vehicle includes the first negotiation parameter of the second vehicle, the number of the second vehicle in the fleet, and the certificate of the second vehicle.
  • Step 305 After the certificate verification of the vehicle adjacent to the number of the first vehicle in the fleet is passed, the first vehicle determines the second negotiation parameter according to the first negotiation parameter of the vehicle adjacent to the number of the first vehicle in the fleet ;
  • Step 306 The first vehicle sends a second negotiation message
  • the second negotiation message includes the second negotiation parameter, the number of the first vehicle in the fleet, and the certificate of the first vehicle.
  • Step 307 The first vehicle receives a second negotiation message from a second vehicle in the fleet;
  • the second negotiation message of the second vehicle includes the second negotiation parameter of the second vehicle, the number of the second vehicle in the fleet, and the certificate of the second vehicle.
  • the second vehicle includes the second vehicle.
  • Step 308 After the certificate verification of any second vehicle is passed, the first vehicle generates a group key for secure communication with any vehicle in the fleet according to the second negotiation parameters of each second vehicle.
  • step 300 the application server can communicate and interact with any vehicle in the fleet.
  • step 300 another implementation of step 300 is that the application server sends the vehicle information of the fleet to the fleet. Part or all of the vehicles in.
  • the above method is applicable to any vehicle in the fleet. Take one of the vehicles as an example to describe the group key agreement process. Hereinafter, this vehicle is referred to as the first vehicle. Understandably, any vehicle in the fleet executes Operation of the first vehicle:
  • the first vehicle Ui After the first vehicle Ui obtains its own number in the fleet from the first terminal device, it generates the first negotiation parameter Ni, and combines the first negotiation parameter Ni generated by itself, its own number in the fleet, and the certificate of the first vehicle Ui Encapsulated in the first negotiation message Mi, the first vehicle Ui sends the first negotiation message Mi, and receives the first negotiation message Mj sent by the second vehicle Uj in the fleet, the first negotiation message Mj includes the first negotiation of the second vehicle Uj Parameter Nj, the number of the second vehicle Uj in the fleet and the certificate of the second vehicle Uj.
  • the second vehicle Uj is any vehicle in the fleet except the first vehicle Ui.
  • the first vehicle Ui uses the first negotiation parameter Ni-1 and the first negotiation parameter Ni+1 of the vehicles adjacent to the number of the first vehicle Ui in the fleet to generate the second negotiation Parameter Ni', the first vehicle Ui sends a second negotiation message Mi', the second negotiation message Mi' includes the second negotiation parameter Ni', the number of the first vehicle Ui in the fleet and the certificate of the first vehicle Ui, and receives the fleet
  • the second negotiation parameter Ni' of Uj of each second vehicle in the fleet is used to generate a group key.
  • the member vehicles of the fleet are verified in the group key agreement process, which shortens the time delay for verifying the member vehicles of the fleet when forming the fleet, and improves the security and reliability of the group key agreement process. Realize the safe communication between member vehicles in the fleet.
  • the pre-configuration phase of the fleet will be mainly introduced.
  • FIG. 4 shows a schematic flowchart corresponding to the secure communication method according to the first embodiment of the present application. As shown in FIG. 4, it includes:
  • step 401 the application server pre-configures public parameters and vehicle certificates required for group key negotiation for vehicles participating in automatic driving formation driving.
  • the application server configures public parameters and vehicle certificates for the vehicles that it manages to support participating in formation.
  • the public parameters are included in the algorithm for calculating the group key when the vehicle joins the fleet and the group key negotiation process is carried out with the member vehicles in the fleet. Public parameters.
  • the vehicle certificate is issued by the vehicle certification authority for the vehicle, and is used to uniquely identify the legal identity of the vehicle.
  • the vehicle certificate may also be pre-configured in the application server by the vehicle manager, which can be used by the application server.
  • the server delivers to the vehicle.
  • the application server may interact with the vehicle certification authority to obtain the vehicle certificate. For example, the application server sends a certificate acquisition request to the vehicle certification authority, the request carries the identification of the vehicle, and the vehicle certification authority feeds back the certificate of the vehicle requested by the certificate acquisition request to the application server.
  • step 402 the team leader vehicle sends a request for building a fleet to the application server.
  • the application server receives the request for building a team from the leader vehicle.
  • the leader car here is only a representative name, which can be the vehicle at the head of the fleet in the fleet to be formed, or a vehicle in another position. Here, it is used to indicate the vehicle that initiates the request for fleet formation.
  • the fleet formation request can be used to instruct the application server to form a fleet for the lead car.
  • the application server can also select one or more vehicles in the area near the lead car according to the location and driving direction of the vehicle.
  • the leader car forms a team, or it can be the leader car itself to form a team.
  • the team formation requests the vehicle identification of the vehicles carrying the team.
  • the application server verifies the identification of each vehicle and agrees to form the team. serial number.
  • the vehicles included in the fleet and the vehicle information may also be pre-configured on the application server.
  • the vehicle manager configures the multiple transport trucks as a fleet through the application server.
  • the application server compiles the numbers in the fleet for the vehicles included in the fleet.
  • the application server may also store information such as certificates and vehicle identities of each vehicle in the fleet.
  • the identification of the vehicle may be a vehicle identification number (Vehicle Identification Number, VIN), and the VIN may be assigned to the vehicle by the manufacturer, and each vehicle has an exclusive VIN.
  • VIN Vehicle Identification Number
  • Step 403 The application server sends the vehicle information of the fleet to the lead car, and correspondingly, the lead vehicle receives the vehicle information of the fleet sent by the application server.
  • the application server sends the vehicle information of the fleet to the leader car.
  • the vehicle information of the fleet includes, but is not limited to: the vehicle identification and vehicle number of any vehicle in the fleet.
  • the vehicle information sent by the application server to the leader car may be vehicle identification (VIN_1, VIN_2, VIN_3, VIN_4) and vehicle number (1, 2, 3, 4), where the vehicle There is a one-to-one correspondence between the identification and the vehicle number in the order of arrangement.
  • the vehicle information characterization the vehicle number of the vehicle with the vehicle identification VIN_1 is 1, the vehicle number of the vehicle with the vehicle identification VIN_2 is 2, and so on.
  • the vehicle information sent by the application server to the leader car may be the group information of the vehicle identification and the vehicle number, for example: (VIN_1, 1), (VIN_2, 2), (VIN_3, 3) and (VIN_4, 4) .
  • the above-mentioned vehicle numbers are only examples, and this application does not limit the specific values of the vehicle numbers.
  • the numbers of the vehicles included in the fleet are consecutive integers, and the numbers of any vehicles in the fleet are different.
  • the numbers of the vehicles in the fleet shown in Fig. 2 may also be (2, 3, 4, 5), or (10, 11, 12, 13).
  • step 403 may also be initiated by the application server.
  • the application server actively sends the vehicle information of the fleet to the lead car, which is used to instruct the lead car to form a vehicle that contains the instructions of the application server.
  • the leader vehicle here can be any numbered vehicle in the fleet or a vehicle at any driving position.
  • step 404 the leader car executes a group key agreement process with message authentication with the group member vehicles according to the vehicle information of the fleet.
  • Crew vehicle refers to any vehicle in the convoy except the leader vehicle.
  • the group key negotiation process may be obtained through a series of calculations based on a preset algorithm.
  • each vehicle in the fleet completes one or more rounds of negotiation to generate a group key.
  • the vehicles in the fleet generate the first round of negotiation parameters based on the preset algorithm
  • the vehicles in the fleet interact with the first round of negotiation parameters
  • each vehicle generates the second round of negotiation parameters based on the preset algorithm and the first round of negotiation parameters.
  • the second round of negotiation parameters are exchanged between the vehicles in, and each vehicle generates a group key based on the second round of negotiation parameters obtained by itself.
  • the embodiment of this application does not limit the preset algorithm used to calculate the group key.
  • the following uses the Burmester-Desmedt group key exchange protocol (BD protocol for short) as an example to describe the group key negotiation process of the embodiment of this application. Describe.
  • BD protocol Burmester-Desmedt group key exchange protocol
  • the group key agreement process based on the BD protocol may include the following steps:
  • ri represents the random number generated by the vehicle with the vehicle number i.
  • the first round of negotiation parameter yi is generated and broadcast, and the first round of negotiation parameter yi satisfies the following formula 1.
  • g and p are public parameters, and the public parameters can be configured by the application server in step 401.
  • Step 2 The vehicle receives broadcast messages from other vehicles, uses the first round of negotiation parameters of the vehicles adjacent to its own vehicle number, and generates and broadcasts the second round of negotiation parameters Xi.
  • the second round of negotiation parameters Xi meets the following formula 2 .
  • i+1 and i-1 are the vehicle numbers of vehicles adjacent to i.
  • the adjacent refers to the adjacent numbers after being arranged in the order of the size of the numbers, where the adjacent numbers of i are (i+1) and (i-1), exemplified by For the fleet shown in Figure 2, the numbers (1, 2, 3, 4) of the vehicles contained in the fleet are taken as an example, where the adjacent numbers of number 1 are 2 and 4, and the adjacent numbers of number 2 are 3 and 1.
  • the adjacent numbers of number 3 are 4 and 2, and the adjacent numbers of number 4 are 1 and 3.
  • the first round of broadcast messages of vehicles in the fleet contains the yi generated based on the above public 1, the number of the vehicle in the fleet and the certificate of the vehicle. The number is used to indicate to other vehicles in the fleet which vehicle sent the broadcast message Yes, when other vehicles receive the first round of broadcast messages from other vehicles in the fleet, they need to verify the vehicle’s certificate. After the verification is passed, the subsequent group key negotiation process will continue. If the verification fails, the broadcast message will be discarded. Exit the group key agreement process. Corresponding to the second round of broadcasting, the same process as the first round of broadcasting is performed, which will not be repeated here.
  • the vehicle can also use its own private key to sign the negotiation parameters (the first round of negotiation parameters and the second round of negotiation parameters) before sending it to the broadcast message.
  • the signature data is verified after the certificate verification of the vehicle is passed. After the signature data verification is passed, the subsequent group key negotiation process is continued. If the certificate or signature data verification fails The broadcast message is discarded, and the group key negotiation process is exited. In this way, the safety and reliability of communication between team members are improved.
  • the above group key negotiation process is only an example. It can be that the vehicles of the fleet broadcast negotiation messages, or the group member vehicles send the negotiation parameters to the same designated terminal device, for example, the team leader car, the team leader car receives in the team
  • the negotiation message of each member vehicle is packaged, and the negotiation message of each vehicle in the fleet is packaged, and the packaged message is sent to each member vehicle in the fleet.
  • the group member vehicle receives the message sent by the leader vehicle, and obtains the negotiation parameters of other vehicles through the message.
  • step 405 the team leader vehicle and the group member vehicle complete the group key agreement process, and each generates a group key.
  • any vehicle in the fleet uses the obtained second round of negotiation parameters to generate a group key, and the group key satisfies the following formula 3.
  • step 406 the group keys are used for secure communication between the vehicles in the fleet.
  • the process executed by the leader vehicle can also be executed by the RSU.
  • the RSU can form a fleet of vehicles within the coverage area according to its own coverage area, see above for details. The related description of the text will not be repeated this time.
  • the system architecture shown in Fig. 2 will be used.
  • the vehicles in the fleet complete the group key negotiation through two rounds of broadcasting as an example to perform the secure communication in the second embodiment of the application specific description.
  • FIG. 5 is a schematic diagram of a process corresponding to a secure communication method provided by an embodiment of the application. Wherein, steps 501 to 503 are the same as the execution steps of steps 401 to 403 in FIG.
  • step 504 the leader vehicle broadcasts the first message to each member vehicle in the fleet, and correspondingly, each member vehicle in the fleet receives the first message broadcast by the leader vehicle.
  • the first message includes but is not limited to: a preset negotiation request field, vehicle information of the fleet, third signature data, or a certificate of the leader vehicle.
  • the preset negotiation request field is used to indicate the type of the first message, and the group key negotiation process is executed after triggering the vehicle of the fleet to join the fleet.
  • the third signature data is obtained after signing the third digital digest using the private key of the leader car.
  • the third digital digest is obtained after the leader car digests the preset negotiation request fields and the vehicle information of the fleet based on the preset digest algorithm. owned.
  • the digest algorithm and the signature algorithm can use international standard algorithms. The embodiment of this application does not limit the digest algorithm and the signature algorithm. The following are examples of several.
  • the digest algorithm can be a hash algorithm (such as SHA-256) or SM3, etc.
  • the signature algorithm can be ECDSA or SM2-based signature algorithm.
  • the first message (called M1) is:
  • represents a hyphen, which is used to connect message fields to form a new message
  • Auth_GKA_req is the negotiation request field, which can be a preset character string, such as 01011011;
  • (IDi, Ui) represents the group information of the vehicle identification Idi of any vehicle i in the fleet and the number Ui of the vehicle i in the fleet. Taking Figure 2 as an example, (IDi, Ui) includes (ID1, U1), (ID2, U2), (ID3, U3) and (ID4, U4).
  • Sign Means that the message is signed based on the preset signature algorithm, and the signature data is obtained
  • Hash Means the digest operation is performed on the message based on the preset digest algorithm to obtain the digital digest
  • (IDi,Ui)] means the first digital digest obtained by encrypting [(Auth_GKA_req
  • Both the signature operation and the digest operation can be understood as the encryption operation using the corresponding encryption algorithm.
  • Lcert represents the certificate of the vehicle, here is the certificate of the leader car.
  • step 505 after receiving the first message broadcast by the leader car, each member vehicle in the fleet verifies the first message.
  • the group member vehicle determines according to the preset negotiation request field that the first message is a group key agreement request message initiated by the leader vehicle, joins the fleet according to the first message, and enters the group key agreement process.
  • each group member vehicle After each group member vehicle receives the first message, it verifies the first message separately. If the verification passes, the group key agreement process is executed, and if the verification fails, the message is discarded, and the group key agreement process is exited.
  • step 504 and step 505 can be described as that vehicle 1 broadcasts the first message, and vehicle 2, vehicle 3, and vehicle 4 receive the first message broadcast by vehicle 1 respectively.
  • Vehicle 2, vehicle 3, and vehicle 4 respectively verify the first message.
  • a member vehicle vehicle 2
  • the process of verifying the first message (M1) by vehicle 2 is described below.
  • the verification process of vehicle 2 on M1 includes:
  • Step 1 Verify the certificate of the leader car contained in M1;
  • the vehicle issuing authority configures the vehicle’s public-private key pair, where the public key can decrypt the data signed with the private key, the vehicle issuing authority informs the vehicle of the private key in a confidential way, and the public key is carried in the vehicle issuing In the certificate issued by the agency for the vehicle.
  • the certificate of the vehicle contains three parts, which are the identity information of the vehicle, the public key assigned by the certificate authority to the vehicle, and the certificate authority uses its own private key to perform digest operations on the first two parts of the message and after the signature operation The data obtained.
  • Table 1 takes the certificate of the leader car as an example to illustrate the structure of the certificate.
  • Identification information (ID) of the lead car The public key of the leader car (Public Key) Sigh ⁇ hash(ID
  • the public key of the vehicle issuing authority is publicly shared data, which can be obtained and stored by any vehicle to verify the certificates of other vehicles.
  • vehicle 2 uses the public key of the vehicle issuing authority to decrypt the third part of the certificate. If the decryption fails, the certificate fails the verification; if the decryption succeeds, the digital digest 1 ( ⁇ hash(ID
  • Step 2 After the certificate verification is passed, verify the third signature data
  • vehicle 2 After the certificate verification is passed, vehicle 2 obtains the public key of the leader car contained in the certificate, and uses the public key of the leader car to decrypt the third signature data. If the decryption fails, the third signature data is not Pass the verification; if the decryption is successful, get the digital digest 3, namely hash[(Auth_GKA_req
  • each member vehicle in the fleet matches the number Ui corresponding to its own vehicle identification IDi based on the (IDi, Ui) contained in the first message, and the vehicle can continue to perform subsequent follow-ups based on the acquired number Group key agreement process.
  • the vehicle identification IDi may be the vehicle VIN assigned when the vehicle leaves the factory, and the vehicle identification is known to the vehicle.
  • each vehicle in the fleet (including the leader vehicle) generates a first negotiation parameter.
  • the following uses the BD protocol as an example to describe the process of generating the first negotiation parameters for the group member vehicles, and the process may include:
  • Vehicle i randomly generates a random number ri, i is an integer greater than 0 and less than n, 1, 2, ..., n is the number of the vehicle in the fleet.
  • vehicle 1 generates random number r1 based on a random function
  • vehicle 2 randomly generates random number r2
  • vehicle 3 randomly generates random number r3
  • vehicle 4 randomly generates random number r4.
  • the vehicle i calculates the first negotiation parameter (indicated by yi) based on the first preset algorithm and its own random number ri. Assume that the first preset algorithm is the above formula 1.
  • Vehicle i uses its own private key to sign the first negotiation parameter yi and the number of vehicle i in the fleet to obtain the first signature data (referred to as method 1).
  • vehicle i can also pass The first signature data is obtained in the following manner.
  • vehicle i uses its own private key to sign the first negotiation parameters, the identification of vehicle i, and the number of vehicle i in the fleet to obtain the first signature data (referred to as the method 2).
  • the following uses Mode 2 as an example for description.
  • Ui) ⁇ , encapsulate Ni to obtain the first negotiation message (indicated by Mi), example sexually, Mi yi
  • Each vehicle in the fleet generates its own first negotiation parameter yi and the first negotiation message Mi in the above-mentioned manner.
  • i identifies the vehicle i.
  • the first negotiation parameter yi generated by the at least two vehicles is also the same.
  • Step 507 Each vehicle in the fleet broadcasts the first negotiation message generated by itself, and receives the first negotiation message broadcast from any other vehicle in the fleet.
  • the first broadcast message is the first negotiation message generated by each vehicle.
  • the first negotiation message generated by vehicle 1 is represented by M1
  • the first negotiation message generated by vehicle 2 is represented by M2
  • the first negotiation message generated by vehicle 3 is represented by M3
  • the first negotiation message generated by vehicle 4 is represented by M3.
  • the first negotiation message is represented by M4.
  • the first round of broadcast of the fleet includes: Vehicle 1 broadcasts M1 and receives M2, M3 and M4. Vehicle 2 broadcasts M2 and receives M1, M3 and M4. Vehicle 3 broadcasts M3 and receives M1, M2 and M4. Vehicle 4 broadcasts M4 and receives M1, M2 and M3.
  • each vehicle in the fleet verifies the received first negotiation message from other vehicles, and generates a second negotiation parameter after the verification is passed.
  • a member vehicle verifies the first negotiation message of another member vehicle (vehicle 1) as an example to describe the verification process of the first negotiation message, which may include:
  • Vehicle 2 verifies the certificate of vehicle 1 included in the first negotiation message.
  • verification method of the certificate please refer to the detailed description of step 505 above, which will not be repeated here.
  • step 505 After the certificate verification of the vehicle 1 is passed, the first signature data included in the first negotiation message is verified.
  • the verification method of the first signature data please refer to the detailed description of step 505 above, and will not be repeated here.
  • each vehicle in the fleet After the first negotiation message is verified, each vehicle in the fleet generates a second negotiation parameter based on the first negotiation parameter of the vehicle adjacent to its own number in the vehicle.
  • the process of generating the first negotiation parameters for the group member vehicles may include:
  • the vehicle i calculates the second negotiation parameter Xi based on the second preset algorithm and its own random number ri. Assume that the second preset algorithm is the above formula 2.
  • Vehicle i uses its own private key to sign the second negotiation parameter Xi and the number of vehicle i in the fleet to obtain the second signature data (referred to as method 1).
  • vehicle i can also pass The second signature data is obtained in the following manner.
  • vehicle i uses its own private key to sign the second negotiation parameter Xi, the identification IDi of vehicle i, and the number Ui of vehicle i in the fleet to obtain the second signature data ( Called method 2).
  • the following takes Mode 2 as an example for description.
  • Ui) ⁇ , encapsulates Ni', and obtains the second negotiation message (indicated by Mi' ), for example, Mi' Xi
  • Each vehicle in the fleet generates its own second negotiation parameter Xi and second negotiation message Mi' in the above-mentioned manner.
  • step 506 if each vehicle saves the certificate of any other vehicle after receiving the first negotiation message of any other vehicle in the fleet, then in step 507, the second negotiation generated by each vehicle The message may not carry the certificate. If each vehicle does not save the certificates of other vehicles after receiving the first negotiation message of other vehicles in the fleet, the second negotiation message generated by each vehicle needs to carry its own certificate.
  • each vehicle in the fleet broadcasts the second negotiation message generated by itself, and receives the second negotiation message broadcast from any other vehicle in the fleet.
  • FIG 7 it is a schematic diagram of the interactive scene of the second round of broadcast by the team.
  • the message broadcast in the second round is the second negotiation message generated by each vehicle.
  • the second negotiation message generated by vehicle 1 is represented by M1'
  • the second negotiation message generated by vehicle 2 is represented by M2'
  • the second negotiation message generated by vehicle 3 is represented by M3'
  • the first negotiation message generated by the vehicle 4 is represented by M4'.
  • the second round of broadcast of the fleet includes: Vehicle 1 broadcasts M1' and receives M2', M3' and M4'.
  • Vehicle 2 broadcasts M2' and receives M1', M3' and M4'.
  • Vehicle 3 broadcasts M3' and receives M1', M2' and M4'.
  • Vehicle 4 broadcasts M4' and receives M1', M2' and M4'.
  • each vehicle in the fleet verifies the acquired second negotiation message of any other vehicle, and after the verification is passed, uses the acquired second negotiation message of any other vehicle to generate a group key.
  • a member vehicle verifies the second negotiation message of another member vehicle (vehicle 1) as an example to describe the verification process of the second negotiation message, which may include:
  • Vehicle 2 verifies the certificate of vehicle 1 included in the second negotiation message.
  • verification method of the certificate please refer to the detailed description of step 506 above, which will not be repeated here.
  • step 506 vehicle 2 has verified the certificates of the adjacent numbered vehicles (vehicle 1 and vehicle 3), then in step 511, vehicle 2 can repeat the verification of the certificates of vehicle 1 and vehicle 3
  • vehicle 2 may also no longer perform repeated verifications on the certificates of the vehicle 1 and the vehicle 3, which is not limited in the embodiment of the present application.
  • step 506 After the certificate verification of the vehicle 1 is passed, the second signature data included in the second negotiation message is verified.
  • the verification method of the second signature data please refer to the detailed description of step 506 above, which will not be repeated here.
  • each vehicle in the fleet After the verification of the second negotiation message is passed, each vehicle in the fleet generates a group key based on the acquired second negotiation parameters of other vehicles in the fleet.
  • the process may include that the vehicle i calculates the group key based on the third preset algorithm and its own random number ri. Assume that the third preset algorithm is the above formula 3.
  • Step 511 The vehicles in the fleet use the group key to securely communicate with any other vehicles in the fleet.
  • the operations performed by the leader car can also be performed by the RSU.
  • the RSU has a number in the fleet.
  • the fleet is composed of RSU, vehicle 2, vehicle 3, and vehicle 4.
  • the number of the RSU is 1, the number of the vehicle 2 is 2, the number of the vehicle 3 is 3, and the number of the vehicle 4 is 4.
  • the RSU executes the operation steps of the leader car, that is, the RSU participates in the calculation and broadcast in the group key agreement process
  • the steps executed by the leader car in the process shown in FIG. 5, which will not be repeated here.
  • the system architecture shown in Fig. 2 will be used.
  • the group key negotiation is completed through two rounds of unicast as an example, and the secure communication in the embodiment of this application is performed. specific description.
  • FIG. 8 is a schematic diagram of a process corresponding to a secure communication method provided by an embodiment of this application. Wherein, the execution steps of steps 801 to 806 and step 815 are the same as the execution steps of steps 501 to 506 and step 511 in FIG.
  • step 807 the vehicles in the fleet send the first negotiation message generated respectively to the same designated terminal device.
  • the designated terminal device is a vehicle in the fleet.
  • the designated terminal device may be a leader car, or a designated numbered vehicle, or a designated driving position, which is not limited in the embodiment of the present application.
  • step 807 Taking the designated terminal device as the leader car as an example, step 807 will be described in detail below.
  • the members of the vehicle fleet send the first negotiation parameters they generate to the leader car.
  • vehicle 1 is the leader car
  • vehicle 1, vehicle 2, vehicle 3, and vehicle 4 are respectively in step 806 Generate respective first negotiation messages.
  • vehicle 2 sends the first negotiation message generated by vehicle 2 itself to vehicle 1 in a unicast (point-to-point) manner.
  • vehicle 3 uses unicast (point-to-point) Point)
  • the first negotiation message generated by the vehicle 3 itself is sent to the vehicle 1
  • the vehicle 4 sends the first negotiation message generated by the vehicle 4 itself to the vehicle 1 in a unicast (point-to-point) manner.
  • Step 808 The designated terminal device verifies the received first negotiation message from other vehicles in the fleet, and generates a first data packet after the verification is passed.
  • the first data packet contains the first negotiation parameter of each vehicle in the fleet.
  • the leader car After the leader car receives the first negotiation message corresponding to vehicle 2, vehicle 3, and vehicle 4, it verifies the first negotiation message of each group member’s vehicle.
  • the process includes: verifying the certificate of each vehicle. After the certificate is verified, the first signature data in the first negotiation message is verified.
  • the specific verification method please refer to the verification step of step 505 above, which will not be repeated here.
  • the leader car obtains the first negotiation parameter (yi) in the first negotiation message of each vehicle, and packs the first negotiation parameters of all vehicles in the fleet to generate the first data packet, for example sexually (Example 1)
  • the first data packet contains the first negotiation parameters of each vehicle and the number of the vehicle in the fleet.
  • the first data packet includes (first negotiation parameter of vehicle 1, 1), ( The first negotiation parameter of vehicle 2, 2), (the first negotiation parameter of vehicle 3, 3), and (the first negotiation parameter of vehicle 4, 4).
  • each first negotiation parameter in the first data packet is arranged according to the number of the vehicle in the fleet.
  • the first data packet includes the first negotiation parameter of vehicle 1 and the first negotiation parameter of vehicle 2.
  • the first negotiation parameter, the first negotiation parameter of the vehicle 3, and the first negotiation parameter of the vehicle 4. Take Example 2 as an example below to describe the subsequent process.
  • the designated terminal device may generate only the first negotiation parameter in step 806. In addition, if the verification of the first negotiation message of any vehicle fails, the designated terminal device discards the message and exits the group key negotiation process.
  • the packaging process of the first data packet includes: based on a preset summary algorithm, perform a summary operation on the first negotiation parameter yi of each vehicle in the fleet arranged according to the number to obtain the corresponding digital summary, and specify the terminal device to use its own
  • the private key performs a signature operation on the digital digest to obtain the corresponding signature data 1, and encapsulates the first negotiation parameters and signature data 1 of all vehicles in the fleet arranged according to the number to generate the first data packet.
  • y1 is the first negotiation parameter of vehicle 1
  • y2 is the first negotiation parameter of vehicle 2
  • y3 is the first negotiation parameter of vehicle 3
  • y4 is the first negotiation parameter of vehicle 4.
  • Step 809 The designated terminal device sends the first data packet to any other vehicle in the fleet.
  • the designated terminal device may broadcast the first data packet, and other vehicles in the corresponding vehicle fleet receive the first data packet broadcast by the designated terminal device.
  • the designated terminal device may also send the first data packet to each component vehicle separately in a unicast manner.
  • each vehicle in the fleet except the designated terminal device receives the first data packet sent by the designated terminal device, and verifies the first data packet, and generates a second negotiation message after the first data packet is verified.
  • vehicle 1 broadcasts the first data packet
  • vehicle 2, vehicle 3, and vehicle 4 respectively receive the first data packet broadcast by vehicle 1, and vehicle 2, vehicle 3, and vehicle 4 respectively respond to the received first data packet.
  • vehicle 2 vehicle 2 as an example to describe the verification process of the first data packet, which includes:
  • the vehicle 2 verifies the certificate of the vehicle 1, and after the certificate verification of the vehicle 1 is passed, the signature data 1 is verified.
  • the signature data 1 is verified.
  • step 505 please refer to the description of step 505 above, which will not be repeated here.
  • the first negotiation parameter of the vehicle adjacent to the own number is obtained, and the second negotiation parameter and the second negotiation message are generated.
  • the specific generation process please refer to the description of step 508, which will not be repeated here.
  • Each vehicle in the fleet generates its own second negotiation parameter and second negotiation message in the above-mentioned manner. It should be noted that since the leader car does not need to send its own second negotiation message, the leader car may only generate the second negotiation parameters in step 810.
  • Step 811 The vehicles in the fleet send the second negotiation message generated respectively to the same designated terminal device.
  • Step 812 The designated terminal device verifies the received second negotiation message from other vehicles in the fleet, and generates a second data packet after the verification is passed, the second data packet contains the second negotiation parameters of each vehicle in the fleet.
  • step 510 For the verification method of the second negotiation message of each vehicle, please refer to the specific description of step 510, which will not be repeated here.
  • the leader car After the verification of the second negotiation message of each vehicle is passed, the leader car obtains the second negotiation parameter (Xi) in the first negotiation message of each vehicle, and packs the second negotiation parameters of all vehicles in the fleet to generate a second negotiation parameter.
  • Data packet wherein each first negotiation parameter in the second data packet is arranged according to the number of the vehicle in the vehicle fleet, exemplarily, exemplarily (example 3), the second data packet contains the second parameter of each vehicle Negotiation parameters and the number of the vehicle in the fleet, for example, the first data packet includes (the second negotiation parameter of vehicle 1, 1), (the second negotiation parameter of vehicle 2, 2), (the second negotiation parameter of vehicle 3) , 3) and (the second negotiation parameter of vehicle 4, 4).
  • each second negotiation parameter in the second data packet is arranged according to the number of the vehicle in the fleet.
  • the first data packet includes the second negotiation parameter of vehicle 1 and the second negotiation parameter of vehicle 2.
  • the second negotiation parameter, the second negotiation parameter of the vehicle 3, and the second negotiation parameter of the vehicle 4. Take Example 4 as an example below to describe the subsequent process.
  • the packaging process of the second data packet includes: based on a preset summary algorithm, the second negotiation parameters of each vehicle in the fleet arranged according to the number are summarized by Xi) to obtain the corresponding digital summary, and the designated terminal device is used
  • the private key of its own performs a signature operation on the digital digest to obtain the corresponding signature data 2, and encapsulates the second negotiation parameters and signature data 2 of each vehicle in the fleet arranged according to the number to generate a second data packet.
  • Step 813 The designated terminal device sends the second data packet to any other vehicle in the fleet.
  • the designated terminal device may broadcast the second data packet, and other vehicles in the corresponding vehicle fleet receive the second data packet broadcast by the designated terminal device.
  • the designated terminal device may also send the second data packet to each component vehicle separately in a unicast manner.
  • each vehicle in the fleet except the designated terminal device receives the second data packet sent by the designated terminal device, and verifies the second data packet. After the second data packet is verified, a group key is generated.
  • step 814 For the execution method of step 814, please refer to the execution steps of each vehicle verifying the first data packet in the above step 810, which will not be repeated here.
  • step 810 For the method of generating the group key for each vehicle in the fleet, please refer to the execution steps of step 810, which will not be repeated here.
  • the operations performed by the designated terminal device can also be performed by the RSU.
  • the RSU has a number in the fleet, for example, the fleet consists of RSU, vehicle 2, vehicle 3, and vehicle.
  • the number of RSU is 4, the number of RSU is 1, the number of vehicle 2 is 2, the number of vehicle 3 is 3, and the number of vehicle 4 is 4.
  • RSU executes the above-mentioned designated terminal equipment operation steps. For details, refer to the flow chart shown in Figure 8 The steps performed by the specified terminal device will not be repeated here.
  • the RSU when the RSU is used as the designated terminal device, the RSU may not have a number in the fleet.
  • the fleet is composed of RSU, vehicle 2, vehicle 3, and vehicle 4.
  • the number of vehicle 2 is 1, and the number of vehicle 3.
  • the number is 2, the number 3 of vehicle 4, where the number of the fleet is only an example, and does not limit the number of the fleet to be compiled from 1.
  • the number in the embodiment of the present application is a continuous and non-repetitive positive integer, for example, vehicle 2
  • the number of is 3, the number of vehicle 3 is 4, and the number of vehicle 4 is 5, which is not limited in the embodiment of the application.
  • the RSU executes the operation steps of the designated terminal device.
  • the RSU does not have the number in the fleet, the RSU does not participate in the calculation process of the first negotiation parameter and the second negotiation parameter, and is only used for Perform aggregation and forwarding operations for the vehicles in the fleet, that is, the RSU receives the first negotiation message and the second negotiation message of each vehicle in the fleet, and generates and sends the first data packet and the second data packet.
  • the methods provided in the embodiments of the present application are respectively introduced from the perspective of interaction between various devices.
  • the first terminal, the second terminal, and the network device may include a hardware structure and/or a software module, in the form of a hardware structure, a software module, or a hardware structure plus a software module To achieve the above functions. Whether a certain function among the above-mentioned functions is executed by a hardware structure, a software module, or a hardware structure plus a software module depends on the specific application and design constraint conditions of the technical solution.
  • the division of modules in the embodiments of the present application is illustrative, and is only a logical function division, and there may be other division methods in actual implementation.
  • the functional modules in the various embodiments of the present application may be integrated in one processor, or may exist alone physically, or two or more modules may be integrated in one module.
  • the above-mentioned integrated modules can be implemented in the form of hardware or software functional modules.
  • an embodiment of the present application further provides an apparatus 900 for implementing the function of the first vehicle or the first terminal device in the foregoing method.
  • the device may be a software module or a chip system.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the apparatus 900 may include: a processing unit 901 and a communication unit 902.
  • the communication unit may also be referred to as a transceiver unit, and may include a sending unit and/or a receiving unit, which are respectively used to execute the data sent and received by the first vehicle, the first terminal device, or the application server in the above method embodiments. step.
  • the device 900 can implement the steps or processes corresponding to the first vehicle or the first terminal device in the above method embodiment, which will be described separately below.
  • the communication unit 902 is configured to receive a first message from a first terminal device, where the first message is used to indicate the number of the first vehicle in the fleet; to send a first negotiation message, the first negotiation message includes the The first negotiation parameter of the first vehicle, the number of the first vehicle in the fleet, and the certificate of the first vehicle; receiving the first negotiation message from the second vehicle; wherein, the second vehicle is the fleet For any vehicle other than the first vehicle in the vehicle, the first negotiation message of the second vehicle includes the first negotiation parameter of the second vehicle, the number of the second vehicle in the fleet, and The certificate of the second vehicle;
  • the processing unit 901 is configured to: after the certificate verification of the vehicle adjacent to the number of the first vehicle in the fleet is passed, according to the first negotiation of the vehicle adjacent to the number of the first vehicle in the fleet The parameter determines the second negotiation parameter;
  • the communication unit 902 is further configured to send a second negotiation message, the second negotiation message including the second negotiation parameter, the number of the first vehicle in the fleet and the certificate of the first vehicle;
  • the second negotiation message of the second vehicle includes the second negotiation parameters of the second vehicle, the number of the second vehicle in the fleet, and the number of the second vehicle Certificate;
  • the processing unit 901 is further configured to generate a group key for secure communication with any vehicle in the fleet according to the second negotiation parameter of each second vehicle after the certificate verification of the second vehicle is passed.
  • the first negotiation message of the second vehicle further includes first signature data; wherein, the first signature data uses the second negotiation parameter and the second vehicle in the The number of the fleet is obtained by the signature operation.
  • the processing unit 901 is specifically configured to: after the certificate verification of the second vehicle is passed, and the first signature data verification is passed, according to the comparison with the first vehicle
  • the first negotiation parameters of adjacently numbered vehicles in the fleet determine the second negotiation parameters.
  • the second negotiation message of the second vehicle further includes second signature data; wherein, the second signature data uses the second negotiation parameters and the second vehicle The number is obtained from the signature operation.
  • the processing unit 901 is specifically configured to: after the certificate verification of the second vehicle is passed and the second signature data verification is passed, according to the information of each second vehicle The second negotiation parameter generates the group key.
  • the first message includes a negotiation request field, vehicle information of the fleet, third signature data, and a certificate of the first device that sent the first message; wherein, the negotiation request The field is used to trigger the vehicles in the fleet to send the first negotiation message; the vehicle information of the fleet includes the vehicle identification of each vehicle in the fleet and the number of the vehicle in the fleet corresponding to the vehicle identification;
  • the third signature data is obtained by encrypting a third digital digest using the private key of the first terminal device, and the third digital digest is obtained by using the negotiation request field and the vehicle information of the fleet, based on The preset digest algorithm is determined.
  • the certificate of the first terminal device includes the public key of the first terminal device; the processing unit 901 is specifically configured to: after the certificate of the first terminal device is verified, And after the verification of the third signature data certificate is passed, the number corresponding to the own vehicle identification is determined according to the vehicle information of the fleet.
  • the processing unit 901 is further configured to: use the first random number generated by itself to obtain the first negotiation parameter based on a first preset algorithm operation.
  • the processing unit 901 is specifically configured to: use the first random number generated by itself and the first negotiation parameter of the second vehicle, and calculate the second vehicle based on a second preset algorithm.
  • Negotiation parameters are specifically configured to: use the first random number generated by itself and the first negotiation parameter of the second vehicle, and calculate the second vehicle based on a second preset algorithm.
  • the processing unit 901 is specifically configured to: use the first random number generated by itself, the second negotiation parameter of the second vehicle, and the number located in the vehicle fleet of the first vehicle.
  • the second negotiation parameter of the second vehicle after the number is calculated based on the third preset algorithm to obtain the group key.
  • the communication unit 902 is further configured to: before sending data to any vehicle in the fleet, use the group key to encrypt the data that needs to be interacted, and to encrypt the data.
  • the latter data is sent to the target vehicle; and/or after the first vehicle receives data from any vehicle in the fleet, the group key is used to decrypt the received data.
  • the communication device is a first terminal device.
  • the communication unit 902 is configured to obtain vehicle information of a fleet from an application server, the vehicle information of the fleet includes the vehicle identification of each vehicle in the fleet and the number of the vehicle in the fleet corresponding to the vehicle identification; Send a first message to each vehicle in the fleet, the first message including a negotiation request field, vehicle information of the fleet, third signature data, and a certificate of the first device that sent the first message; wherein, The negotiation request field is used to trigger the vehicles in the fleet to send the first negotiation message; the vehicle information of the fleet includes the vehicle identification of each vehicle in the fleet and the vehicle corresponding to the vehicle identification is in the The number of the fleet; the third signature data is obtained by encrypting a third digital digest using the private key of the first terminal device, and the third digital digest is obtained by using the negotiation request field and the fleet The vehicle information is determined based on the preset summary algorithm.
  • the communication unit 902 is further configured to receive a first negotiation message from any other vehicle in the fleet; send the first data packet to any other vehicle in the fleet, The first data packet includes the first negotiation message of any vehicle in the fleet; and/or the second negotiation message is received from any other vehicle in the fleet; the second data packet is sent to the fleet For any other vehicle in the vehicle, the second data packet includes a second negotiation message of any vehicle in the fleet.
  • the first terminal device is any numbered vehicle in the fleet, or the first terminal device is a roadside device RSU.
  • the communication device is an application server.
  • the communication unit 902 sends the vehicle information of the fleet to the first terminal device.
  • FIG. 10 is an apparatus 1000 provided by an embodiment of the application, and the apparatus shown in FIG. 10 may be a hardware circuit implementation of the apparatus shown in FIG. 10.
  • the communication device can be applied to the flowcharts shown in FIG. 3 to FIG. 5 and FIG. 8 to perform the functions of the first vehicle, the first terminal device or the application server in the foregoing method embodiment.
  • FIG. 10 only shows the main components of the communication device.
  • the apparatus 1000 shown in FIG. 10 includes at least one processor 1020, which is configured to implement any one of the methods in FIGS. 3 to 5 and 8 provided in the embodiments of the present application.
  • the device 1000 may also include at least one memory 1030 for storing program instructions and/or data.
  • the memory 1030 and the processor 1020 are coupled.
  • the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units or modules, and may be in electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the processor 1020 may operate in cooperation with the memory 1030.
  • the processor 1020 may execute program instructions stored in the memory 1030. At least one of the at least one memory may be included in the processor.
  • the steps of the above method can be completed by hardware integrated logic circuits in the processor or instructions in the form of software.
  • the steps of the method disclosed in combination with the embodiments of the present application may be embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.
  • the software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.
  • the processor in the embodiment of the present application may be an integrated circuit chip with signal processing capability.
  • the steps of the foregoing method embodiments may be completed by hardware integrated logic circuits in the processor or instructions in the form of software.
  • the above-mentioned processor may be a general-purpose processor, a digital signal processing circuit (digital signal processor, DSP), a dedicated integrated circuit (application specific integrated circuit, ASIC), a field programmable gate array (field programmable gate array, FPGA) or other Programming logic devices, discrete gates or transistor logic devices, discrete hardware components.
  • DSP digital signal processing circuit
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • Programming logic devices discrete gates or transistor logic devices, discrete hardware components.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application may be embodied as being executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers.
  • the storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
  • the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory can be read-only memory (ROM), programmable read-only memory (programmable ROM, PROM), erasable programmable read-only memory (erasable PROM, EPROM), and electrically available Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • the volatile memory may be random access memory (RAM), which is used as an external cache.
  • RAM random access memory
  • static random access memory static random access memory
  • dynamic RAM dynamic RAM
  • DRAM dynamic random access memory
  • synchronous dynamic random access memory synchronous DRAM, SDRAM
  • double data rate synchronous dynamic random access memory double data rate SDRAM, DDR SDRAM
  • enhanced synchronous dynamic random access memory enhanced SDRAM, ESDRAM
  • synchronous connection dynamic random access memory serial DRAM, SLDRAM
  • direct rambus RAM direct rambus RAM
  • the apparatus 1000 may further include a communication interface 1010 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1000 can communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.
  • the transceiver when the communication interface is a transceiver, the transceiver may include an independent receiver and an independent transmitter; it may also be a transceiver with integrated transceiver functions, or an interface circuit.
  • the device 1000 may further include a communication line 1040.
  • the communication interface 1010, the processor 1020, and the memory 1030 may be connected to each other through a communication line 1040;
  • the communication line 1040 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (extended industry standard architecture). , Referred to as EISA) bus and so on.
  • the communication line 1040 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used to represent in FIG. 10, but it does not mean that there is only one bus or one type of bus.
  • the communication interface 1010 is configured to receive a first message from a first terminal device, where the first message is used to indicate the number of the first vehicle in the fleet; to send a first negotiation message, the first negotiation message includes the The first negotiation parameter of the first vehicle, the number of the first vehicle in the fleet, and the certificate of the first vehicle; receiving the first negotiation message from the second vehicle; wherein, the second vehicle is the fleet For any vehicle other than the first vehicle in the vehicle, the first negotiation message of the second vehicle includes the first negotiation parameter of the second vehicle, the number of the second vehicle in the fleet, and The certificate of the second vehicle;
  • the processor 1020 is configured to, after the certificate verification of the vehicle adjacent to the number of the first vehicle in the fleet is passed, according to the first negotiation of the vehicle adjacent to the number of the first vehicle in the fleet
  • the parameter determines the second negotiation parameter
  • the communication interface 1010 is also used to send a second negotiation message, the second negotiation message including the second negotiation parameter, the number of the first vehicle in the fleet, and the certificate of the first vehicle;
  • the second negotiation message of the second vehicle includes the second negotiation parameters of the second vehicle, the number of the second vehicle in the fleet, and the number of the second vehicle Certificate;
  • the processor 1020 is further configured to generate a group key for secure communication with any vehicle in the fleet according to the second negotiation parameter of each second vehicle after the certificate verification of the second vehicle is passed.
  • the processor may be a general-purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware
  • the components can implement or execute the methods, steps, and logical block diagrams disclosed in the embodiments of the present application.
  • the general-purpose processor may be a microprocessor or any conventional processor or the like.
  • the steps of the method disclosed in combination with the embodiments of the present application may be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.
  • At least one item (a) of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple .
  • “plurality" means two or more.
  • the term "exemplary” is used to mean serving as an example, illustration, or illustration. Any embodiment or design solution described as an "example” in this application should not be construed as being more preferable or advantageous than other embodiments or design solutions. Rather, the term example is used to present the concept in a concrete way.
  • the ordinal numbers such as “first” and “second” mentioned in the embodiments of the present application may be used to distinguish multiple objects, and are not used to limit the order, timing, priority, or importance of multiple objects.
  • the first information and the second information are only for distinguishing different signaling, but do not indicate the difference in content, priority, sending order, or importance of the two types of information.
  • the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or a volatile memory (volatile memory), for example Random-access memory (RAM).
  • the memory is any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.
  • the memory in the embodiment of the present application may also be a circuit or any other device capable of realizing a storage function for storing program instructions and/or data.
  • the methods provided in the embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software When implemented by software, it can be implemented in the form of a computer program product in whole or in part.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a digital video disc (digital video disc, DVD for short)), or a semiconductor medium (for example, SSD).
  • the embodiments can be mutually cited.
  • the methods and/or terms between the method embodiments can be mutually cited, such as the functions and/or functions between the device embodiments.
  • Or terms may refer to each other, for example, functions and/or terms between the device embodiment and the method embodiment may refer to each other.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

本申请提供一种安全通信的方法及装置，可应用于自动驾驶技术领域，其中方法包括：第一车辆从第一终端设备接收第一消息，发送第一协商消息，并接收来自第二车辆的第一协商消息；第二车辆的第一协商消息包括第二车辆的第一协商参数、第二车辆在所述车队中的编号和第二车辆的证书；并在与第一车辆在车队中的编号相邻的车辆的证书验证通过后，根据该编号相邻的车辆的第一协商参数确定第二协商参数；发送第二协商消息，并接收来自所述第二车辆的第二协商消息；在第二车辆的证书验证通过后，根据每个第二车辆的第二协商参数生成组密钥。车队的车辆可以在组密钥协商过程中对车辆证书进行验证，缩短了组密钥协商时延，提高了信息安全和网络安全的性能。

Description

一种安全通信的方法及装置 技术领域
本申请涉及自动驾驶技术领域，尤其涉及一种安全通信的方法及装置。
背景技术
自动驾驶应用中的一个重要场景是车辆的编队行驶，在车辆编队行驶场景中，最前车辆可以充当“火车头”的角色，后车自动跟随行驶，并实现编队车辆几乎同步加减速、转向及制动。
在车辆编队行驶过程中，群组内的车队成员之间主要通过V2X(vehicle to everything，车到万物)方式来进行车辆间的通信，但V2X基于开放的无线通信网络，相比传统网络更容易受到攻击，对于主要基于V2X通信的车辆编队行驶领域所带来的损害也更大。因此，在自动驾驶的车辆编队行驶场景下，对V2X通信的安全性提出更高的要求。
因此，现有急需提出一种针对自动驾驶领域中车辆编队行驶过程中车队成员之间进行安全通信的方案。
发明内容
本申请提供一种安全通信的方法及装置，用于实现自动驾驶领域中群组行驶过程中车队成员之间的安全通信。
该方法可以由终端设备实现，例如，车辆或车载设备(例如，车载T-BOX(Telematics BOX))，也可以由终端设备的部件实现，如由终端设备中的处理装置、电路、芯片等部件实现，例如，T-BOX中支持无线通信功能相关的芯片，如系统芯片或通信芯片。其中，系统芯片也称为片上系统，或称为SoC芯片。通信芯片可以包括射频处理芯片和基带处理芯片。基带处理芯片有时也称为调制解调器(modem)。在物理实现中，通信芯片可集成在SoC芯片内部，也可以不与SoC芯片集成。例如，基带处理芯片集成在SoC芯片中，射频处理芯片不与SoC芯片集成。
第一方面，本申请实施例提供一种安全通信的方法，该方法包括：第一车辆从第一终端设备接收第一消息，所述第一消息用于指示所述第一车辆在车队中的编号，发送第一协商消息，所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书，接收来自第二车辆的第一协商消息；其中，所述第二车辆为所述车队中除所述第一车辆之外的其他车辆，所述第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；并在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；发送第二协商消息，所述第二协商消息包括所述第二协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；并接收来自所述第二车辆的第二协商消息；所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；在所述第二车辆的证书验证通过后，根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥。
具体的，第二车辆可以是车队中除第一车辆之外的其他一个车辆，或其他多个车辆，还可以是其他任意一辆车辆。
通过上述方法，车队中的车辆在组密钥协商流程中，通过用于确定组密钥的第一协商消息和第二协商消息中携带的证书，对车辆的身份信息进行验证，不需要在车队组建前，对每一车辆的身份信息进行验证，缩短了在组建车队时对车队的成员车辆进行验证的时延，提高了在组密钥协商过程中的安全性和可靠性，实现了车队内成员车辆之间的安全通信。
在一种可能的实现方法中，所述第二车辆的第一协商消息还包含第一签名数据；其中，所述第一签名数据是使用所述第二协商参数和所述第二车辆在所述车队的编号进行签名操作得到的。
通过上述方法，第一车辆在对第二车辆的证书验证通过后，还可以对第一签名数据进行验证，避免在第一协商消息在传输过程中被篡改，进一步了组密钥协商过程的安全性和可靠性。
在一种可能的实现方法中，所述在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，所述第一车辆根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数，包括：所述在所述第二车辆的证书验证通过后，且所述第一签名数据验证通过后，所述第一车辆根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数。
在一种可能的实现方法中，第二车辆的证书包含所述第二车辆的公钥；所述第一车辆通过下列方式对所述第一签名数据进行验证：所述第一车辆使用所述第二车辆的所述公钥对所述第一签名数据进行解密，得到第一数字摘要，以及使用所述第二车辆的第二协商参数和所述第二车辆在所述车队中的编号，基于所述预设摘要算法确定第一数值；在验证所述第二数字摘要与所述第一数值一致时，所述第一签名数据验证通过，否则，所述第一签名数据验证失败。
在一种可能的实现方法中，所述第二车辆的第二协商消息包括还包括第二签名数据；其中，所述第二签名数据是使用所述第二协商参数和所述第二车辆的编号进行签名操作得到的。
通过上述方法，组密钥协商过程中，第一车辆接收第二协商消息，在对第二车辆的证书验证通过后，还可以对第二签名数据进行验证，避免在第二协商消息在传输过程中被篡改，增强了组密钥协商过程的安全性和可靠性。
在一种可能的实现方法中，所述在所述第二车辆的证书验证通过后，所述第一车辆根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥，包括：在所述第二车辆的证书验证通过后，且所述第二签名数据验证通过后，所述第一车辆根据每个所述第二车辆的第二协商参数生成所述组密钥。
所述第二车辆的证书包含所述第二车辆的公钥；所述第一车辆通过下列方式对所述第二签名数据进行验证：所述第一车辆使用所述第二车辆的所述公钥对所述第二签名数据进行解密，得到第二数字摘要，以及使用所述第二车辆的第二协商参数和所述第二车辆在所述车队的编号，基于所述预设摘要算法确定第二数值；在所述第而数字摘要与所述第二数值一致时，所述第二签名数据验证通过，否则，所述第二签名数据验证失败。
在一种可能的实现方法中，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；其中，所述协商请求字段用于触发 所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
所述第一终端设备的证书包含所述第一终端设备的公钥；所述第一车辆接收第一消息之后，还包括：在所述第一终端设备的证书验证通过后，且所述第三签名数据证书验证通过后，所述第一车辆根据所述车队的车辆信息，确定自身的车辆标识对应的所述编号。
在一种可能的实现方法中，还包括：所述第一车辆使用自身生成的第一随机数，基于第一预设算法运算得到第一协商参数。
在一种可能的实现方法中，所述第一车辆根据所述第二车辆的第二协商参数确定第二协商参数，包括：所述第一车辆使用自身生成的第一随机数和所述第二车辆的第一协商参数，基于第二预设算法运算得到所述第二协商参数。
在一种可能的实现方法中，所述第一车辆根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥，包括：所述第一车辆使用自身生成的第一随机数、所述第二车辆的第二协商参数和所述编号位于所述第一车辆在车队中的编号之后的第二车辆的第二协商参数，基于第三预设算法运算得到所述组密钥。
通过上述方法，车队内的各车辆根据自身的随机数和其他车辆的第二协商参数，基于第三预设算法生成组密钥，由于各车辆的随机数不需要传输，因此安全性更高，即时第二协商消息被其他车辆获取也无法计算出组密钥。本申请实施例的组密钥协商流程更加简单，计算量小，且安全性更高。
在一种可能的实现方法中，还包括：所述第一车辆向所述车队中的任一车辆发送数据之前，使用所述组密钥对需要交互的数据进行加密，并将所述加密后的数据发送至目标车辆；和/或所述第一车辆接收来自所述车队中的任一车辆的数据后，使用所述组密钥对接收到的所述数据进行解密。
第二方面，本申请实施例提供一种安全通信的方法，该方法包括：第一终端设备从应用服务器获取车队的车辆信息，所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队中的编号；所述第一终端设备向所述车队中每一车辆发送第一消息，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
在一种可能的实现方法中，还包括：所述第一终端设备接收来自所述车队中的其他任一车辆的第一协商消息；所述第一终端设备将第一数据包发送至所述车队中的其他任一车辆，所述第一数据包包含所述车队中任一车辆的第一协商消息；和/或所述第一终端设备接收来自所述车队中的其他任一车辆的第二协商消息；所述第一终端设备将第二数据包发送至所述车队中的其他任一车辆，所述第二数据包包含所述车队中任一车辆的第二协商消息。
在一种可能的实现方法中，所述第一终端设备为所述车队中的任一编号的车辆，或所述第一终端设备为路侧设备RSU。
第三方面，本申请实施例提供一种终端设备，该装置具有实现第一方面所述的方法的功能，所述功能可以通过硬件实现，也可以通过软件实现，或者通过硬件执行相应的软件实现。所述装置包括一个或多个与上述功能相对应的模块，比如包括收发单元和处理单元。
在一个可能的设计中，该装置可以是芯片或者集成电路。
在一个可能的设计中，该装置包括存储器、处理器和收发器，收发器用于接收和发送数据，存储器用于存储所述处理器执行的程序或指令，当程序或指令被处理器执行时，所述装置可以执行上述第一方面及其第一方面中的各种可能设计所涉及的方法。
在一个可能的设计中，该装置可以为车辆。
第四方面，本申请实施例提供一种终端设备，该装置具有实现第二方面所述的方法的功能，所述功能可以通过硬件实现，也可以通过软件实现，或者通过硬件执行相应的软件实现。所述装置包括一个或多个与上述功能相对应的模块，比如包括收发单元和处理单元。
在一个可能的设计中，该装置可以是芯片或者集成电路。
在一个可能的设计中，该装置包括存储器、处理器和收发器，收发器用于接收和发送数据，存储器用于存储所述处理器执行的程序或指令，当程序或指令被处理器执行时，所述装置可以执行上述第一方面及其第一方面中的各种可能设计所涉及的方法。
在一个可能的设计中，该装置可以为车辆或RSU。
第五方面，本申请实施例提供一种装置，所述装置包括处理器、存储器和通信接口，所述通信接口，用于接收信号或者发送信号；所述存储器，用于存储程序或指令代码；所述处理器，用于从所述存储器调用所述程序或指令代码执行如第一方面及其第一方面中的各种可能设计所涉及的方法或执行如第二方面及其第二方面中的各种可能设计所涉及的方法。
第六方面，本申请实施例提供一种装置，所述通信装置包括处理器和接口电路，所述接口电路，用于接收程序或指令代码并传输至所述处理器；所述处理器运行所述程序或指令代码以执行如第一方面及其第一方面中的各种可能设计所涉及的方法或执行如第二方面及其第二方面中的各种可能设计所涉及的方法。
第七方面，本申请提供一种装置，该装置可以是终端设备，还可以是用于终端设备的芯片。该装置具有实现上述第一方面或第二方面的各实施例的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
第八方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序或指令，当所述程序或指令被执行时，使得第一方面及其第一方面中的各种可能设计所涉及的方法，或第二方面及其第二方面中的各种可能设计所涉及的方法被实现。
第九方面，本申请实施例提供一种包括指令的计算机程序产品，当所述指令被执行时，使得第一方面及其第一方面中的各种可能设计所涉及的方法，或第二方面及其第二方面中的各种可能设计所涉及的方法被实现。
第十方面，本申请实施例还提供了一种安全通信系统，包括：应用服务器、第一终端设备和安全通信装置，所述安全通信装置可以执行上述第一方面或第一方面任一种可能实现方式中的相应功能，所述第一终端设备可以执行上述第二方面或第二方面任一种可能实现方式中的相应功能，具体参见方法示例中的详细描述，此处不做赘述。
附图说明
图1为本申请实施例提供的一种系统架构示意图；
图2为本申请实施例提供的另一种系统架构示意图；
图3为本申请实施例提供的一种安全通信的方法流程示意图；
图4为本申请实施例一提供的一种安全通信的方法流程示意图；
图5为本申请实施例二提供的一种安全通信的方法流程示意图；
图6为本申请实施例二中提供的组密钥协商流程中的第一轮广播场景示意图；
图7为本申请实施例二中提供的组密钥协商流程中的第二轮广播场景示意图；
图8为本申请实施例三提供的另一种安全通信的方法流程示意图；
图9为本申请实施例提供的一种安全通信的装置结构示意图；
图10为本申请实施例提供的一种安全通信的装置结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述。方法实施例中的具体操作方法也可以应用于设备实施例或系统实施例中。其中，在本申请的描述中，除非另有说明，“多个”的含义是两个或两个以上。
图1示例性示出了本申请实施例适用的一种系统架构示意图。如图1所示，该系统架构包括网络设备和终端设备组。其中，终端设备组包括至少两个终端设备，至少两个终端设备可以组成终端设备组，终端设备组中可以包括主控终端设备，除主控终端设备之外的其他终端设备可以称为从设备。
网络设备，主要用于存储终端设备的设备信息，与终端设备进行通信交互，组建终端设备群组，为终端设备群组中的终端设备制定编号。
终端设备，可以是一种具有无线收发功能的设备。在不同的应用场景中，终端设备的表现形式也不同。示例性的，在传统的移动通信场景中，终端设备可以是手机、平板电脑等。在物联网(internet of things，IoT)通信场景中，终端设备可以是移动互联网设备、可穿戴设备、工业中或智能家居中的各种无线终端。在车联网或车到万物(vehicle to everything，V2X)通信场景中，终端设备可以是车辆、车联网中的车载单元(on board unit，OBU)、路侧单元(road side unit，RSU)、路侧设备(road side equipment，RSE)、车载电控制单元(electronic control unit，ECU)等。
需要说明的是，在本申请提供的系统中，终端设备可以通过V2X通信网络与应用服务器建立通信连接，进行通信交互。示例性地，终端设备与应用服务器建立连接后，终端设备可以从应用服务器获取终端设备组中任一组员终端设备的设备信息。终端设备之间可以通过V2V或I2V(包含RSU的场景)通信网络建立通信连接，进行通信交互。
示例性地，主控终端设备，还可以用于与应用服务器进行通信交互，获取终端设备群组内的终端设备的信息，向终端设备群组内的终端设备发起群组组建请求，在从设备加入终端设备群组后，与从设备进行通信交互，完成用于终端设备群组之间通信交互所需的组密钥。从设备，还可以用于响应主控终端设备发起的群组组建请求，在加入终端设备群组后，与主控终端设备进行通信交互，完成用于终端设备群组之间通信交互所需的组密钥。主控终端设备与从设备之间，从设备与从设备之间可以使用组密钥对需要交互的数据进行 加密，以此实现安全通信。
本申请实施例中，用于实现终端设备的功能的装置可以是终端设备，也可以是能够支持终端设备实现该功能的装置，例如芯片系统，该装置可以被安装在终端设备中。本申请实施例中，芯片系统可以由芯片构成，也可以包括芯片和其他分立器件。本申请实施例提供的技术方案中，以用于实现终端的功能的装置是终端设备为例，描述本申请实施例提供的技术方案。
应理解，图1中所示出的两个终端设备仅为一种示例，不作为本申请的限定。图1中的网络设备可以为多个终端设备提供服务，本申请对通信系统中终端设备的数量不做具体限定。另外，图1所示的架构可以应用到多种通信场景中，例如，第五代(the 5th generation，5G)通信系统、未来的第六代通信系统和演进的其他通信系统、第四代(the 4th generation)通信系统、车到万物(vehicle to everything，V2X)、长期演进-车联网(LTE-vehicle，LTE-V)、车到车(vehicle to vehicle，V2V)、车联网、机器类通信(machine type communications，MTC)、物联网(internet of things，IoT)、长期演进-机器到机器(LTE-machine to machine，LTE-M)、机器到机器(machine to machine，M2M)等通信场景中，本申请对此不作限定。
下面对上述系统架构进行详细介绍：
基于图1所示意的系统架构，以系统架构中包括P个终端设备，该P个终端设备为一个终端设备群组为例，P为大于或等于1的整数，P个终端设备可以分别为终端设备1、终端设备2、……、终端设备P，其中，1、2、……、P可以理解为应用服务器为从设备分配在终端设备群组中的编号。
可选的，P个终端设备中包括主控终端设备，应用服务器可以为主控终端设备制定编号，也可以不为该主控终端设备制定编号，例如，若不为主控终端设备制定编号，则除主控终端设备之外的P-1个从设备的编号可以分别是，1、2、……、P-1。
为便于对本申请实施例进行介绍，下面以P＝4为例，描述一种可能的系统架构，该系统架构可以适用于车联网系统，例如自动驾驶车辆系统。在应用于自动驾驶车辆系统时，网络设备可以是应用服务器，终端设备为车辆时，终端设备群组可以称为车队，主控终端设备可以称为领队车，从设备可以称为组员车辆。参见图2，为本申请实施例提供的另一种系统架构示意图，该系统架构包含应用服务器，领队车辆和组员车辆，领队车和3个组员车辆。需要说明的是，图2所示的领队车的编号仅为示意，本申请实施例中的领队车可以是车队内任意编号的车辆，本申请实施例对此不作限定。
下面以图2的场景为例，对上述各个设备进行解释说明，以便于本领域技术人员理解。
(1)应用服务器：主要用于配置、临时组建以及维护车队，对车队进行管理，包括但不限于：预先配置所管理的车队的证书、车队中各组员车辆的车辆信息，为车队中的每一车辆制定车辆编号，示例性地，车辆编号为连续且不重复的正整数。比如，车辆编号为1，2，3…n，n为正整数，车队中的每一车辆的车辆编号不同。还可以与车队中的车辆进行通信，例如，领队车辆向应用服务器发送获取车队信息请求，用于获取包括领队车辆所在的车队中的每一车辆的车辆信息、编号和证书等信息。应用服务器向领队车辆发送车队中每一车辆的车辆信息、编号和证书等信息。示例性地，车辆与应用服务器之间的通信方式可以是V2X通信方式。又例如，车辆周期性向应用服务器上报自身的位置信息，应用服务器获取车辆的位置信息，并根据车辆的位置信息临时组建车队。
示例性地，应用服务器可以为车辆网应用服务器(V2X application server，V2X AS)。
(2)领队车：主要用于与应用服务器进行通信，获取车队中任一车辆的车辆信息，例如，车辆标识、车辆编号或车辆证书等。还用于与组员车辆之间进行通信，例如，领队车与组员车辆进行组密钥协商流程，确定组密钥，使用组密钥进行加密通信。
其中，领队车可以是车队内的任一编号或行驶位置的车辆，本申请实施例对此不作限定。
(3)组员车辆：主要用于监听领队车发起的车队组建请求，加入车队后进入车队的组密钥协商流程，确定组密钥，并使用组密钥进行加密通信，例如，使用组密钥对车队内交互的数据进行加密或解密通信。
(4)V2X，在版本(Rel)-14/15/16版本中，V2X作为设备到设备(device-to-device，D2D)技术的一个主要应用顺利立项。V2X将在已有的D2D技术的基础上对V2X的具体应用需求进行优化，需要进一步减少V2X设备的接入时延，解决资源冲突问题。V2X具体又包括V2V、V2I、V2P的直接通信，以及V2N的通信交互等几种应用需求。V2V指的是车辆间的通信；V2P指的是车辆与人(包括行人、骑自行车的人、司机、或乘客)的通信；V2I指的是车辆与网络设备的通信，网络设备例如RSU，另外还有一种V2N可以包括在V2I中，V2N指的是车辆与基站/网络的通信。其中，RSU包括两种类型：终端类型的RSU，由于布在路边，该终端类型的RSU处于非移动状态，不需要考虑移动性；基站类型的RSU，可以给与之通信的车辆提供定时同步及资源调度。
示例性地，本申请实施例中，在车队中，主控终端设备还可以是RSU，RSU可以具有车辆编号，也可以不具有车辆编号，下文将会针对该场景对本申请技术方案进行具体介绍。
为解决背景技术中提到的问题，本申请提供一种安全通信方法，参阅图3所示，该方法包括：
步骤300：第一终端设备从应用服务器获取车队的车辆信息；
车队的车辆信息包括该车队中每一车辆的车辆标识和该车辆标识对应的该车辆在该车队中的编号。
步骤301：第一终端设备向车队中的每一组员车辆发送第一消息；
第一消息用于指示所述第一车辆在车队中的编号。
步骤302：第一车辆接收第一终端设备发送的第一消息；
步骤303：第一车辆发送第一协商消息；
所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书。
步骤304：第一车辆接收来自车队中的第二车辆的第一协商消息；
其中，第二车辆为所述车队中除所述第一车辆之外的其他任一车辆。
第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书。
步骤305：在与第一车辆在车队中的编号相邻的车辆的证书验证通过后，第一车辆根据与第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；
步骤306：第一车辆发送第二协商消息；
第二协商消息包括第二协商参数、第一车辆在车队中的编号和第一车辆的证书。
步骤307：第一车辆接收来自所述车队中第二车辆的第二协商消息；
所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所 述车队中的编号和所述第二车辆的证书。其中，第二车辆包含第二车辆。
步骤308：在任一第二车辆的证书验证通过后，第一车辆根据每一第二车辆的第二协商参数生成与车队中任一车辆进行安全通信的组密钥。
需要说明的是，上述步骤仅为示例，本申请实施例中应用服务器可以与车队中的任意车辆进行通信交互，例如步骤300的另一种实现方式为，应用服务器将车队的车辆信息发送给车队中的部分或全部车辆。
上述方式，适用于车队中的任一车辆，以其中一个车辆为例，对组密钥协商流程进行描述，下文将该车辆称为第一车辆，可以理解地，车队内的任一车辆均执行第一车辆的操作：
第一车辆Ui从第一终端设备获取到自身在车队内的编号后，生成第一协商参数Ni，并将自身生成的第一协商参数Ni、自身在车队中的编号和第一车辆Ui的证书封装在第一协商消息Mi中，第一车辆Ui发送第一协商消息Mi，并接收车队内第二车辆Uj发送的第一协商消息Mj，第一协商消息Mj包括第二车辆Uj的第一协商参数Nj，第二车辆Uj在车队中的编号和第二车辆Uj的证书，第二车辆Uj为车队内除第一车辆Ui之外的任一车辆。
在第二车辆Uj的证书验证通过后，第一车辆Ui使用与第一车辆Ui在车队中的编号相邻的车辆的第一协商参数Ni-1和第一协商参数Ni+1生成第二协商参数Ni＇，第一车辆Ui发送第二协商消息Mi＇，第二协商消息Mi＇包括第二协商参数Ni＇，第一车辆Ui在车队中的编号和第一车辆Ui的证书，并接收车队内第二车辆Uj发送的第二协商消息Nj＇，第二协商消息Mj＇，包括第二车辆Uj的第二协商参数Nj＇，第二车辆Uj在车队中的编号和第二车辆Uj的证书。
在对第二车辆Uj的证书验证通过后，使用车队中每一第二车辆的Uj的第二协商参数Ni＇生成组密钥。
上述方式，在组密钥协商流程中对车队的成员车辆进行验证，缩短了在组建车队时对车队的成员车辆进行验证的时延，并且提高了组密钥协商流程的安全性和可靠性，实现了车队内成员车辆之间的安全通信。
下面结合具体实施例(实施例一至实施例四)，对图2所示的实施例的方案进行详细描述。
【实施例一】
在实施例一中，将主要对车队的预配置阶段进行介绍。
请参考图4，图4示出了本申请实施例一的安全通信的方法所对应的流程示意图，如图4所示，包括：
步骤401，应用服务器为参与自动行驶编队行驶的车辆预配置用于组密钥协商所需的公共参数以及车辆证书。
应用服务器为其管理的支持参与编队行驶的车辆配置公共参数和车辆证书，该公共参数是车辆加入车队后，与车队内的成员车辆进行组密钥协商流程时计算组密钥的算法中包含的公共参数。
其中，车辆的证书为车辆证书颁发机构为该车辆颁发的，用于唯一标识该车辆的合法身份，示例性地，车辆的证书也可以是车辆管理人员预配置在应用服务器中的，可以由应用服务器下发至该车辆。再示例性地，还可以是应用服务器与该车辆证书颁发机构进行交互，来获取车辆的证书。例如，应用服务器向该车辆证书颁发机构发送证书获取请求，该 请求携带车辆的标识，车辆证书颁发机构向应用服务器反馈证书获取请求请求的车辆的证书。
步骤402，领队车向应用服务器发送车队组建请求，对应的，应用服务器接收领队车发送的车队组建请求。
这里的领队车仅是一种代称，可以是待组建的车队中处于车队头部的车辆，也可以是其他位置的车辆，此处用于指示发起车队组建请求的车辆。
示例性地，该车队组建请求可以用于指示应用服务器为领队车组建车队，例如，应用服务器还可以根据车辆的位置、行驶方向等信息挑选该领队车附近区域内的1个或多个车辆与该领队车组成车队，也可以是领队车自身组建车队，该车队组建请求携带该车队的车辆的车辆标识，应用服务器验证各车辆标识，并同意组建车队后，为车队的车辆编制在车队中的编号。
再示例性地，车队所包含的车辆，以及车辆的信息还可以是预先配置在应用服务器上的，例如，对于多辆运输卡车，车辆管理人员通过应用服务器将该多辆运输卡车配置为一个车队，应用服务器为车队包含的车辆编制在车队中的编号。应理解的是，应用服务器还可以存储有车队中各车辆的证书、车辆的标识等信息。示例性地，车辆的标识可以是车辆识别号码(Vehicle Identification Number，VIN)，VIN可以是生产商为该车辆分配的，每个每一车辆具有专属的VIN。
需要说明的是，上述组建车队的方式仅为举例，不应构成对本申请组建车队的限定，任何组建车队的方式均适用于本申请实施例。
步骤403，应用服务器向领队车发送车队的车辆信息，对应的，领队车接收应用服务器发送的车队的车辆信息。
应用服务器向领队车发送车队的车辆信息，示例性地，车队的车辆信息包括但不限于：该车队中任一车辆的车辆标识与车辆编号。示例性地，对于图2所示的车队，应用服务器向领队车发送的车辆信息可以是车辆标识(VIN_1，VIN_2，VIN_3，VIN_4)和车辆编号(1，2，3，4)，其中，车辆标识与车辆编号按照排列顺序一一对应。该车辆信息表征：车辆标识为VIN_1的车辆的车辆编号为1，车辆标识为VIN_2的车辆的车辆编号为2，依次类推。再示例性地，应用服务器向领队车发送的车辆信息可以是车辆标识与车辆编号的组信息，例如：(VIN_1，1)，(VIN_2，2)，(VIN_3，3)和(VIN_4，4)。
需要说明的是，上述车辆编号仅为举例，本申请对车辆编号的具体数值不作限定，本申请实施例中车队中包含的车辆的编号为连续的整数，且车队中的任一车辆的编号不同，例如，图2所示的车队的车辆的编号还可以是(2，3，4，5)，或(10，11，12，13)。
其中，步骤403还可以是应用服务器主动发起的，例如，辆管理人员通过应用服务器配置车队时，应用服务器主动向领队车发送车队的车辆信息，用于指示领队车组建包含应用服务器指示的车辆的车队。其中，这里的领队车可以是车队中的任意编号的车辆或者是任意行驶位置的车辆。
步骤404，领队车根据车队的车辆信息与组员车辆执行带消息认证的组密钥协商流程。
组员车辆是指车队中除领队车之外的任一车辆。
具体的，组密钥协商流程可以基于预设算法经过一系列运算得到的，示例性地，车队中的每一车辆完成一轮或多轮协商，以此生成组密钥。例如，车队中的车辆基于预设算法生成第一轮协商参数，车队中的车辆之间交互第一轮协商参数，各车辆基于预设算法和第 一轮协商参数生成第二轮协商参数，车队中的车辆之间交互第二轮协商参数，各车辆基于自身获取的第二轮协商参数生成组密钥。
本申请实施例对用于计算组密钥的预设算法不作限定，为了方便描述，下面以Burmester-Desmedt组密钥交换协议(简称BD协议)为例，对本申请实施例的组密钥协商流程进行描述。
示例性地，基于BD协议的组密钥协商流程可以包括如下步骤：
步骤1，车队内的任一车辆生成随机数ri，其中i＝1,2,3,…2，(1,2,3,…n)为车队中所有成员车辆的车辆编号。ri表示车辆编号为i的车辆产生的随机数，基于随机数ri生成并广播第一轮协商参数yi，第一轮协商参数yi满足于下列公式1。
Figure PCTCN2020082614-appb-000001
其中，g和p为公共参数，该公共参数可以由步骤401中的应用服务器进行配置。
步骤2，车辆接收其他车辆的广播消息，使用和与自身的车辆编号相邻的车辆的第一轮协商参数，生成并广播第二轮协商参数Xi，第二轮协商参数Xi满足于下列公式2。
Figure PCTCN2020082614-appb-000002
其中，i+1和i-1为与i相邻的车辆的车辆编号。需要说明的是，该相邻是指按照编号的大小顺序收尾相接排列后相邻的编号，其中，i的相邻编号为(i+1)和(i-1)，示例性地，以图2所示的车队，该车队包含的车辆的编号(1，2，3，4)为例，其中，编号1的相邻编号为2和4，编号2的相邻编号为3和1，编号3的相邻编号为4和2，编号4的相邻编号为1和3。
其中，车队内车辆的第一轮广播消息包含基于上述公共1生成的yi、该车辆在车队的编号和该车辆的证书，该编号用于向车队内其他车辆指示，该广播消息是哪个车辆发送的，其他车辆接收到来自车队中其他车辆的第一轮广播消息时，需要对该车辆的证书进行验证，验证通过后，继续执行后续组密钥协商流程，若验证失败则丢弃该广播消息，退出组密钥协商流程。对应第二轮广播执行第一轮广播相同的流程，此处不再赘述。
可选的，车辆在发送还可以使用自身的私钥对协商参数时(第一轮协商参数和第二轮协商参数)进行签名操作后再封装至广播消息中。在接收到车队中其他车辆的广播消息后，在该车辆的证书验证通过后，再验证该签名数据，签名数据验证通过后，再继续执行后续组密钥协商流程，若证书或签名数据验证失败则丢弃该广播消息，退出组密钥协商流程。以此提高车队成员之间进行通信的安全性和可靠性。
需要说明的是，上述组密钥协商流程仅为举例，可以是车队的车辆广播协商消息，还可以是组员车辆将协商参数发送至同一指定终端设备，例如，领队车，领队车接收车队中每一个组员车辆的协商消息，并将车队中每一车辆的协商消息进行打包，并将打包后的消息发送至车队中每一组员车辆。组员车辆接收领队车发送的消息，通过该消息获取其他车辆的协商参数。
步骤405，领队车和组员车辆完成组密钥协商流程，各自生成组密钥。
示例性地，车队中的任一车辆使用获取到的第二轮协商参数，生成组密钥，组密钥满足于下列公式3。
Figure PCTCN2020082614-appb-000003
Figure PCTCN2020082614-appb-000004
步骤406，车队中的车辆之间使用组密钥进行安全通信。
需要说明的是，上述步骤中，由领队车所执行的流程还可以由RSU来执行，由RSU来执行时，RSU可以根据自身的覆盖范围，将覆盖范围内的车辆组建为车队，具体参见上文相关描述，此次不再赘述。
下面通过实施例二至实施例四对组密钥协商流程进行具体描述。
【实施例二】广播
在实施例二中，将以图2所示的系统架构，车队中的车辆在协商组密钥流程中，通过两轮广播完成组密钥协商为例，对本申请实施例二中的安全通信进行具体描述。
图5为本申请实施例提供的安全通信方法所对应的流程示意图。其中，步骤501～步骤503与图4中的步骤401～步骤403的执行步骤相同，此处不再赘述，以下仅对不同之处进行说明。
步骤504，领队车向车队中的每一组员车辆广播第一消息，对应的，车队中的每一组员车辆接收领队车广播的第一消息。
具体的，第一消息包括但不限于：预设协商请求字段，车队的车辆信息、第三签名数据或领队车的证书。
其中，预设协商请求字段用于指示第一消息的类型，触发车队的车辆加入车队后执行组密钥协商流程。第三签名数据为使用领队车的私钥对第三数字摘要进行签名操作后得到的，第三数字摘要是领队车基于预设摘要算法对预设协商请求字段和车队的车辆信息进行摘要操作后得到的。其中，摘要算法和签名算法可以采用国际标准算法，本申请实施例对摘要算法和签名算法不作限定，以下示例性地列举几种，摘要算法可以是哈希算法(例如SHA-256)或SM3等，签名算法可以是ECDSA或基于SM2的签名算法。
示例性地，第一消息(以M1代称)为：
M1＝Auth_GKA_req||(IDi,Ui)||Sign{hash[(Auth_GKA_req||(IDi,Ui))]}||Lcert
其中，||表示连字符，用于将消息字段进行连接，组成一个新的消息；
Auth_GKA_req为协商请求字段，可以是预设字符串，例如01011011；
(IDi,Ui)表示车队中任一车辆i的车辆标识Idi和车辆i在车队的编号Ui的组信息。以图2为例，(IDi,Ui)包括(ID1,U1)、(ID2,U2)、(ID3,U3)和(ID4,U4)。
Sign：表示基于预设签名算法对消息进行签名操作，得到签名数据；
Hash：表示基于预设摘要算法对消息进行摘要操作，得到数字摘要；
具体的，hash[(Auth_GKA_req||(IDi,Ui)]，表示使用哈希算法对[(Auth_GKA_req||(IDi,Ui)]进行加密得到的第一数字摘要；Sign{hash[(Auth_GKA_req||(IDi,Ui))]}，则表示使用领队车的私钥对该第一数字摘要进行签名操作，签名操作和摘要操作均可以理解为使用对应的加密算法进行加密的操作。
Lcert表示车辆的证书，此处为领队车的证书。
步骤505，车队中的每一组员车辆在接收到领队车广播的第一消息后，对第一消息进行验证。
组员车辆根据预设协商请求字段确定该第一消息为领队车发起的组密钥协商请求消息，根据该第一消息加入车队，并进入组密钥协商流程。
各组员车辆在接收到第一消息后，分别对该第一消息进行验证，若验证通过，则执行组密钥协商流程，若验证失败，则丢弃该消息，退出组密钥协商流程。
举例来说，在图2中，假设领队车的编号为1，其余组员车辆的编号分别为2、3和4， 为了方便描述，下面将领队车简称为车辆1，其余组员车辆简称为车辆2、车辆3和车辆4。步骤504和步骤505的流程可以描述为，车辆1广播第一消息，车辆2、车辆3和车辆4分别接收车辆1广播的第一消息。车辆2、车辆3和车辆4分别对该第一消息进行验证，下面以一个组员车辆(车辆2)为例，对车辆2对第一消息(M1)进行验证的流程进行描述。具体的，车辆2对M1的验证流程包括：
步骤1，对M1包含的领队车的证书进行验证；
首先对车辆的证书进行介绍：
车辆颁发机构为车辆配置该车辆的公私钥对，其中，公钥能够对使用私钥签名的数据进行解密，车辆颁发机构通过保密的方式将私钥通知给该车辆，公钥则携带在车辆颁发机构为该车辆颁发的证书中。示例性地，车辆的证书包含三部分，分别为该车辆的身份信息、证书颁发机构为该车辆分配的公钥和证书颁发机构使用自身的私钥对前两部分消息进行摘要操作以及签名操作后得到的数据。如下表1所示，为方便描述，表1以领队车的证书为例，对证书的结构进行示例性展示。
表1
第一部分 第二部分 第三部分
领队车的身份信息(ID) 领队车的公钥(Public Key) Sigh{hash(ID||Public Key)}
应理解地是，车辆颁发机构的公钥为公开共享的数据，任意车辆都可以获取并存储，用于对其他车辆的证书进行验证。
举例来说，车辆2使用车辆颁发机构的公钥对证书的第三部分进行解密，若解密失败，则证书未通过验证；若解密成功，则获得数字摘要1({hash(ID||public key)})。同时车辆2基于预设摘要算法，对证书的第一部分和第二部分进行摘要操作，得到数字摘要2，若数字摘要1与数字摘要2一致，则该证书验证通过，否则，该证书验证不通过，车辆2丢弃该第一消息，不参与组密钥协商流程。
步骤2，在证书验证通过后，对第三签名数据进行验证；
在证书验证通过后，车辆2获取证书中包含的该领队车的公钥(public key)，并使用该领队车的公钥对第三签名数据进行解密，若解密失败，则第三签名数据未通过验证；若解密成功，则获得数字摘要3，即hash[(Auth_GKA_req||(IDi,Ui))，并基于预设摘要算法，对M1包含的Auth_GKA_req||(IDi,Ui)进行摘要操作，得到数字摘要4，若数字摘要3与数字摘要4一致，则该第一消息验证通过，否则，车辆2丢弃该第一消息，不参与组密钥协商流程。
在第一消息验证通过后，车队中的每一组员车辆基于第一消息中包含的(IDi,Ui)匹配自身的车辆标识IDi对应的编号Ui，该车辆可以基于获取的编号继续执行后续的组密钥协商流程。其中，车辆标识IDi可以是该车辆出厂时被分配的车辆VIN，该车辆标识为车辆已知的。
步骤506，车队中的每一车辆(包括领队车)生成第一协商参数。
下面以BD协议为例，对组员车辆生成第一协商参数的流程进行描述，该流程可以包括：
(1)，车辆i随机生成随机数ri，i为大于0小于n的整数，1,2,……，n为车队中的车辆的编号。例如，车辆1基于随机函数生成随机数r1，车辆2随机生成随机数r2，车辆3随机生成随机数r3，车辆4随机生成随机数r4。
(2)，车辆i基于第一预设算法和自身的随机数ri，运算得到第一协商参数(以yi表示)。假设第一预设算法为上述公式1。
(3)，车辆i使用自身的私钥对第一协商参数yi和车辆i在车队中的编号进行签名操作，得到第一签名数据(称为方式1)，可选的，车辆i还可以通过下列方式得到第一签名数据，示例性地，车辆i使用自身的私钥对第一协商参数、车辆i的标识和车辆i在车队中的编号进行签名操作，得到第一签名数据(称为方式2)。下文以方式2为例进行描述。
车辆i生成第一签名数据(以Ni表示)，示例性地，Ni＝Sigh{hash(yi||IDi||Ui)}，对Ni进行封装，得到第一协商消息(以Mi表示)，示例性地，Mi＝yi||IDi||Ui||Ni||Lcert(Ui)。
车队中的每一车辆通过上述方式生成自身的第一协商参数yi，以及第一协商消息Mi。i标识车辆i。
一种可能的情况，当车队中的至少两辆车辆生成的随机数相同时，该至少两辆车辆生成的第一协商参数yi也相同。
步骤507，车队中的每一车辆广播自身生成的第一协商消息，并接收来自车队中其他任一车辆广播的第一协商消息。
如图6所示，为车队进行第一轮广播的交互场景示意图。其中，第一轮广播的消息为各车辆生成的第一协商消息。
为了方便区分，将车辆1生成的第一协商消息以M1来表示，将车辆2生成的第一协商消息以M2来表示，将车辆3生成的第一协商消息以M3来表示，将车辆4生成的第一协商消息以M4来表示。图6中，车队的第一轮广播包括：车辆1广播M1，并接收M2，M3和M4。车辆2广播M2，并接收M1，M3和M4。车辆3广播M3，并接收M1，M2和M4。车辆4广播M4，并接收M1，M2和M3。
步骤508，车队中的每一车辆对接收到的来自其他车辆的第一协商消息进行验证，在验证通过后，生成第二协商参数。
下面以一个组员车辆(车辆2)对另一组员车辆(车辆1)的第一协商消息进行验证为例，对第一协商消息的验证流程进行描述，该流程可以包括：
(1)车辆2对第一协商消息包含的车辆1的证书进行验证，对于证书的验证方式请参见上述步骤505的具体描述，此处不再赘述。
(2)在车辆1的证书验证通过后，对第一协商消息包含的第一签名数据进行验证，对于第一签名数据的验证方式请参见上述步骤505的具体描述，此处不再赘述。
在第一协商消息验证通过后，车队中的每一车辆基于与自身在车辆中的编号相邻的车辆的第一协商参数生成第二协商参数。
下面仍基于BD协议，对组员车辆生成第一协商参数的流程进行描述，该流程可以包括：
(1)车辆i基于第二预设算法和自身的随机数ri，运算得到第二协商参数Xi。假设第二预设算法为上述公式2。
(2)，车辆i使用自身的私钥对第二协商参数Xi和车辆i在车队中的编号进行签名操作，得到第二签名数据(称为方式1)，可选的，车辆i还可以通过下列方式得到第二签名数据，示例性地，车辆i使用自身的私钥对第二协商参数Xi、车辆i的标识IDi和车辆i在车队中的编号Ui进行签名操作，得到第二签名数据(称为方式2)。下文以方式2为例 进行描述。
车辆i生成第二签名数据(以Ni＇表示，示例性地，Ni＇＝Sigh{hash(Xi||IDi||Ui)}，对Ni＇进行封装，得到第二协商消息(以Mi＇表示)，示例性地，Mi＇＝Xi||IDi||Ui||Ni＇||Ui||Lcert(Ui)。
车队中的每一车辆通过上述方式生成自身的第二协商参数Xi，以及第二协商消息Mi＇。
可选的，如果在步骤506中，若各车辆在接收到车队中其他任一车辆的第一协商消息后，保存其他任一车辆的证书，则在步骤507中，各车辆生成的第二协商消息可以不携带证书。如果若各车辆在接收到车队中其他车辆的第一协商消息后，不保存其他车辆的证书，则各车辆生成的第二协商消息需要携带自身的证书。
步骤509，车队中的每一车辆广播自身生成的第二协商消息，并接收来自车队中其他任一车辆广播的第二协商消息。
如图7所示，为车队进行第二轮广播的交互场景示意图。其中，第二轮广播的消息为各车辆生成的第二协商消息。
为了方便区分，将车辆1生成的第二协商消息以M1＇来表示，将车辆2生成的第二协商消息以M2＇来表示，将车辆3生成的第二协商消息以M3＇来表示，将车辆4生成的第一协商消息以M4＇来表示。图7中，车队的第二轮广播包括：车辆1广播M1＇，并接收M2＇，M3＇和M4＇。车辆2广播M2＇，并接收M1＇，M3＇和M4＇。车辆3广播M3＇，并接收M1＇，M2＇和M4＇。车辆4广播M4＇，并接收M1＇，M2＇和M4＇。
步骤510，车队中的每一车辆对获取到的其他任一车辆的第二协商消息进行验证，在验证通过后，使用获取到的其他任一车辆的第二协商消息生成组密钥。
下面以一个组员车辆(车辆2)对另一组员车辆(车辆1)的第二协商消息进行验证为例，对第二协商消息的验证流程进行描述，该流程可以包括：
(1)车辆2对第二协商消息包含的车辆1的证书进行验证，对于证书的验证方式请参见上述步骤506的具体描述，此处不再赘述。
可选的，在步骤506中，车辆2已对相邻编号的车辆(车辆1和车辆3)的证书进行了验证，则在步骤511，车辆2可以对车辆1和车辆3的证书进行重复验证，车辆2也可以不再对车辆1和车辆3的证书进行重复验证，本申请实施例对此不作限定。
(2)在车辆1的证书验证通过后，对第二协商消息包含的第二签名数据进行验证，对于第二签名数据的验证方式请参见上述步骤506的具体描述，此处不再赘述。
在第二协商消息验证通过后，车队中的每一车辆基于获取到的车队中其他车辆的第二协商参数各自生成组密钥。
下面仍基于BD协议，对车队中的各车辆生成组密钥的流程进行描述，该流程可以包括车辆i基于第三预设算法和自身的随机数ri，运算得到组密钥。假设第三预设算法为上述公式3。
步骤511，车队内的车辆使用组密钥与车队中任一其他车辆进行安全通信。
需要说明的是，上述流程步骤中，由领队车执行的操作也可以由RSU来执行，同样，该RSU具有在车队中的编号，例如，车队由RSU、车辆2、车辆3和车辆4组成，RSU的编号为1，车辆2的编号为2，车辆3的编号为3，车辆4的编号为4，RSU执行上述领队车的操作步骤，即该RSU参与组密钥协商流程中的计算及广播，具体参见图5所示的流程中由领队车执行的步骤，此处不再赘述。
【实施例三】单播
在实施例三中，将以图2所示的系统架构，车队中的车辆在协商组密钥流程中，通过两轮单播完成组密钥协商为例，对本申请实施例中的安全通信进行具体描述。
图8为本申请实施例提供的安全通信方法所对应的流程示意图。其中，步骤801～步骤806和步骤815与图5中的步骤501～步骤506和步骤511的执行步骤相同，此处不再赘述，以下仅对不同之处进行说明。
步骤807，车队中的车辆将各自生成的第一协商消息发送至同一指定终端设备。
应理解的是，该指定终端设备为车队中的车辆。示例性地，该指定终端设备可以是领队车，或指定编号的车辆，或指定行驶位置的车辆，本申请实施例对此不作限定。
下面以该指定终端设备为领队车为例，对步骤807进行具体描述。
车队中的组员车辆将各自生成的第一协商参数发送至领队车，举例来说，以图2为例，车辆1为领队车，车辆1、车辆2、车辆3和车辆4分别在步骤806生成各自的第一协商消息，在步骤807，车辆2以单播(点到点)的方式，将车辆2自身生成的第一协商消息发送至车辆1，同样，车辆3以单播(点到点)的方式，将车辆3自身生成的第一协商消息发送至车辆1，车辆4以单播(点到点)的方式，将车辆4自身生成的第一协商消息发送至车辆1。
步骤808，指定终端设备对接收到的来自车队中其他车辆的第一协商消息进行验证，在验证通过后，生成第一数据包，第一数据包包含车队中每一车辆的第一协商参数。
如前所示，以指定终端设备为领队车为例，领队车接收到车辆2、车辆3和车辆4对应的第一协商消息后，分别对各组员车辆的第一协商消息进行验证，验证流程包括：验证各车辆的证书，证书验证通过后，验证第一协商消息中的第一签名数据，具体验证方式可以参见上述步骤505的验证步骤，此处不再赘述。
在第一协商消息验证通过后，领队车获取各车辆的第一协商消息中的第一协商参数(yi)，并对车队中所有车辆的第一协商参数进行打包，生成第一数据包，示例性地(示例1)，第一数据包中的包含各车辆的第一协商参数和该车辆在车队中的编号，例如，第一数据包包括(车辆1的第一协商参数，1)、(车辆2的第一协商参数，2)、(车辆3的第一协商参数，3)和(车辆4的第一协商参数，4)。再示例性地(示例2)，第一数据包中的各第一协商参数按照车辆在车队中的编号进行排列，举例来说，第一数据包包括车辆1的第一协商参数、车辆2的第一协商参数、车辆3的第一协商参数和车辆4的第一协商参数。下面以示例2为例，描述后续流程。
需要说明的是，由于指定终端设备不需要发送自身的第一协商消息，因此，指定终端设备在步骤806可以仅生成第一协商参数。另外，若任一车辆的第一协商消息验证失败，则该指定终端设备丢弃该消息，退出组密钥协商流程。
示例性地，第一数据包的打包流程包括：基于预设摘要算法，对车队中按照编号排列的各车辆的第一协商参数yi进行摘要操作，得到对应的数字摘要，指定终端设备使用自身的私钥对该数字摘要进行签名操作，得到对应的签名数据1，并将车队中按照编号排列的所有车辆的第一协商参数和签名数据1进行封装，生成第一数据包。示例性地，第一数据包(以data1代称)data1＝y1||y2||y3||y4||sigh{hash(y1||y2||y3||y4)}||Lcert(指定终端设备)。其中，y1为车辆1的第一协商参数，y2为车辆2的第一协商参数，y3为车辆3的第一协商参数，y4为车辆4的第一协商参数。
步骤809，指定终端设备将第一数据包发送至车队中的其他任一车辆。
示例性地，指定终端设备可以广播第一数据包，对应的车队中的其他车辆接收该指定终端设备广播的第一数据包。再示例性地，指定终端设备还可以通过单播的方式，分别将第一数据包发送至每一组成车辆。
步骤810，车队中除指定终端设备之外的每一车辆接收指定终端设备发送的第一数据包，并对第一数据包进行验证，在第一数据包验证通过后，生成第二协商消息。
以图2为例，车辆1广播第一数据包，车辆2、车辆3和车辆4分别接收车辆1广播的第一数据包，车辆2、车辆3和车辆4分别对接收到的第一数据包进行验证。下面以一个车辆(车辆2)为例，对第一数据包的验证流程进行描述，该流程包括：
车辆2对车辆1的证书进行验证，在车辆1的证书验证通过后，对签名数据1进行验证。具体验证步骤可以参见上述步骤505的描述，此处不再赘述。
在第一数据包验证通过后，获取与自身编号相邻的车辆的第一协商参数，生成第二协商参数以及第二协商消息。具体生成流程，可以参见步骤508的描述，此处不再赘述。
车队中的每一车辆通过上述方式生成自身的第二协商参数，以及第二协商消息。需要说明的是，由于领队车不需要发送自身的第二协商消息，因此，领队车在步骤810可以仅生成第二协商参数。
步骤811，车队中的车辆将各自生成的第二协商消息发送至同一指定终端设备。
步骤812，指定终端设备对接收到的来自车队中其他车辆的第二协商消息进行验证，在验证通过后，生成第二数据包，第二数据包包含车队中每一车辆的第二协商参数。
对于每一个车辆的第二协商消息的验证方式可以参见步骤510的具体描述，此处不再赘述。
在每一车辆的第二协商消息验证通过后，领队车获取各车辆的第一协商消息中的第二协商参数(Xi)，并对车队中所有车辆的第二协商参数进行打包，生成第二数据包，其中，第二数据包中的各第一协商参数按照车辆在车队中的编号进行排列，示例性地，示例性地(示例3)，第二数据包中的包含各车辆的第二协商参数和该车辆在车队中的编号，例如，第一数据包包括(车辆1的第二协商参数，1)、(车辆2的第二协商参数，2)、(车辆3的第二协商参数，3)和(车辆4的第二协商参数，4)。再示例性地(示例4)，第二数据包中的各第二协商参数按照车辆在车队中的编号进行排列，举例来说，第一数据包包括车辆1的第二协商参数、车辆2的第二协商参数、车辆3的第二协商参数和车辆4的第二协商参数。下面以示例4为例，描述后续流程。
示例性地，第二数据包的打包流程包括：基于预设摘要算法，对车队中按照编号排列的各车辆的第二协商参数以Xi)进行摘要操作，得到对应的数字摘要，指定终端设备使用自身的私钥对该数字摘要进行签名操作，得到对应的签名数据2，并将车队中按照编号排列的各车辆的第二协商参数和签名数据2进行封装，生成第二数据包。示例性地，第二数据包(以data2代称)data2＝X1||X2||X3||X4||sigh{hash(X1||X2||X3||X4)}||Lcert(指定终端设备)。
步骤813，指定终端设备将第二数据包发送至车队中的其他任一车辆。
示例性地，指定终端设备可以广播第二数据包，对应的车队中的其他车辆接收该指定终端设备广播的第二数据包。再示例性地，指定终端设备还可以通过单播的方式，分别将第二数据包发送至每一组成车辆。
步骤814，车队中除指定终端设备之外的每一车辆接收指定终端设备发送的第二数据包，并对第二数据包进行验证，在第二数据包验证通过后，生成组密钥。
对于步骤814的执行方式，可以参见上述步骤810中，各车辆对第一数据包进行验证的执行步骤，此处不再赘述。
对于车队中各车辆各自生成组密钥的方式可以参见步骤810的执行步骤，此处不再赘述。
一种可实施的方式，上述流程步骤中，由指定终端设备执行的操作也可以由RSU来执行，同样，该RSU具有在车队中的编号，例如，车队由RSU、车辆2、车辆3和车辆4组成，RSU的编号为1，车辆2的编号为2，车辆3的编号为3，车辆4的编号为4，RSU执行上述指定终端设备的操作步骤，具体参见图8所示的流程中由指定终端设备执行的步骤，此处不再赘述。
【实施例四】RSU不具备在车队中的编号。
一种可实施的方式，RSU作为指定终端设备时，RSU还可以没有在车队中的编号，例如，车队由RSU、车辆2、车辆3和车辆4组成，车辆2的编号为1，车辆3的编号为2，车辆4的编号3，其中，该车队的编号仅为举例，并非限定车队的编号从1开始编制，本申请实施例中的编号为连续且不重复的正整数，例如，车辆2的编号为3，车辆3的编号为4，车辆4的编号为5，本申请实施例对此不作限定。
RSU作为指定终端设备时，RSU执行上述指定终端设备的操作步骤，不同之处在于，RSU不具备在车队的编号时，RSU不参与第一协商参数、第二协商参数的计算流程，仅用于为车队中的车辆作汇总和转发操作，即RSU接收车队中每一车辆的第一协商消息和第二协商消息，以及生成并发送第一数据包和第二数据包。
上述本申请提供的实施例中，分别从各个设备之间交互的角度对本申请实施例提供的方法进行了介绍。为了实现上述本申请实施例提供的方法中的各功能，第一终端、第二终端与网络设备可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。
本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
与上述构思相同，如图9所示，本申请实施例还提供一种装置900用于实现上述方法中第一车辆或第一终端设备的功能。例如，该装置可以为软件模块或者芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。该装置900可以包括：处理单元901和通信单元902。
本申请实施例中，通信单元也可以称为收发单元，可以包括发送单元和/或接收单元，分别用于执行上文方法实施例中第一车辆、第一终端设备或应用服务器发送和接收的步骤。
以下，结合图9至图10详细说明本申请实施例提供的通信装置。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。
在一种可能的设计中，该装置900可实现对应于上文方法实施例中的第一车辆或者第 一终端设备执行的步骤或者流程，下面分别进行描述。
示例性地，当该装置900实现前面的流程中第一车辆的功能时：
通信单元902，用于从第一终端设备接收第一消息，所述第一消息用于指示所述第一车辆在车队中的编号；发送第一协商消息，所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自第二车辆的第一协商消息；其中，所述第二车辆为所述车队中除所述第一车辆之外的其他任一车辆，所述第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
处理单元901，用于在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；
通信单元902，还用于发送第二协商消息，所述第二协商消息包括所述第二协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自所述第二车辆的第二协商消息；所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
处理单元901，还用于在所述第二车辆的证书验证通过后，根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥。
在一种可能的实施方式中，所述第二车辆的第一协商消息还包含第一签名数据；其中，所述第一签名数据是使用所述第二协商参数和所述第二车辆在所述车队的编号进行签名操作得到的。
在一种可能的实施方式中，所述处理单元901具体用于：在所述第二车辆的证书验证通过后，且所述第一签名数据验证通过后，根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数。
在一种可能的实施方式中，所述第二车辆的第二协商消息包括还包括第二签名数据；其中，所述第二签名数据是使用所述第二协商参数和所述第二车辆的编号进行签名操作得到的。
在一种可能的实施方式中，所述处理单元901具体用于：在所述第二车辆的证书验证通过后，且所述第二签名数据验证通过后，根据每个所述第二车辆的第二协商参数生成所述组密钥。
在一种可能的实施方式中，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
在一种可能的实施方式中，所述第一终端设备的证书包含所述第一终端设备的公钥；所述处理单元901具体用于：在所述第一终端设备的证书验证通过后，且所述第三签名数据证书验证通过后，根据所述车队的车辆信息，确定自身的车辆标识对应的所述编号。
在一种可能的实施方式中，所述处理单元901还用于：使用自身生成的第一随机数，基于第一预设算法运算得到第一协商参数。
在一种可能的实施方式中，所述处理单元901具体用于：使用自身生成的第一随机数 和所述第二车辆的第一协商参数，基于第二预设算法运算得到所述第二协商参数。
在一种可能的实施方式中，所述处理单元901具体用于：使用自身生成的第一随机数、所述第二车辆的第二协商参数和所述编号位于所述第一车辆在车队中的编号之后的第二车辆的第二协商参数，基于第三预设算法运算得到所述组密钥。
在一种可能的实施方式中，所述通信单元902还用于：向所述车队中的任一车辆发送数据之前，使用所述组密钥对需要交互的数据进行加密，并将所述加密后的数据发送至目标车辆；和/或所述第一车辆接收来自所述车队中的任一车辆的数据后，使用所述组密钥对接收到的所述数据进行解密。
在一种可能的实施方式中，所述通信装置为第一终端设备。
示例性地，当该装置900实现前面的流程中第一终端设备的功能时：
通信单元902，用于从应用服务器获取车队的车辆信息，所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队中的编号；向所述车队中每一车辆发送第一消息，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
在一种可能的实施方式中，通信单元902，还用于接收来自所述车队中的其他任一车辆的第一协商消息；将第一数据包发送至所述车队中的其他任一车辆，所述第一数据包包含所述车队中任一车辆的第一协商消息；和/或接收来自所述车队中的其他任一车辆的第二协商消息；将第二数据包发送至所述车队中的其他任一车辆，所述第二数据包包含所述车队中任一车辆的第二协商消息。
在一种可能的实施方式中，所述第一终端设备为所述车队中的任一编号的车辆，或所述第一终端设备为路侧设备RSU。
在一种可能的实施方式中，所述通信装置为应用服务器。
示例性地，当该装置900实现前面的流程中应用服务器的功能时：
通信单元902，向所述第一终端设备发送车队的车辆信息。
如图10所示为本申请实施例提供的装置1000，图10所示的装置可以为图10所示的装置的一种硬件电路的实现方式。该通信装置可适用于图3至图5、图8所示出的流程图中，执行上述方法实施例中第一车辆、第一终端设备或应用服务器的功能。为了便于说明，图10仅示出了该通信装置的主要部件。
图10所示的装置1000包括至少一个处理器1020，用于实现本申请实施例提供的图3至图5、图8中任一方法。
装置1000还可以包括至少一个存储器1030，用于存储程序指令和/或数据。存储器1030和处理器1020耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器1020可能和存储器1030协同操作。处理器1020可能执行存储器1030中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。
在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件 形式的指令完成。结合本申请实施例所公开的方法的步骤可以体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
应注意，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理电路(digital signal processor，DSP)、专用集成芯片(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
可以理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
装置1000还可以包括通信接口1010，用于通过传输介质和其它设备进行通信，从而用于装置1000中的装置可以和其它设备进行通信。在本申请实施例中，通信接口可以是收发器、电路、总线、模块或其它类型的通信接口。在本申请实施例中，通信接口为收发器时，收发器可以包括独立的接收器、独立的发射器；也可以集成收发功能的收发器、或者是接口电路。
装置1000还可以包括通信线路1040。其中，通信接口1010、处理器1020以及存储器1030可以通过通信线路1040相互连接；通信线路1040可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。所述通信线路1040可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
示例性地，当该装置1000实现前面的流程中第一车辆的功能时：
通信接口1010，用于从第一终端设备接收第一消息，所述第一消息用于指示所述第一车辆在车队中的编号；发送第一协商消息，所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自第二车辆的第一协商消息；其中，所述第二车辆为所述车队中除所述第一车辆之外的其他任一车辆，所述第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
处理器1020，用于在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；
通信接口1010，还用于发送第二协商消息，所述第二协商消息包括所述第二协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自所述第二车辆的第二协商消息；所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
处理器1020，还用于在所述第二车辆的证书验证通过后，根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥。
处理器1020和通信接口1010执行的其它方法可以参考图3至图5、图8所示的方法流程中的描述，这里不再赘述。
需要说明的是，在本申请实施例中，处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
在本申请实施例中，“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。其中，“多个”是指两个或两个以上。
在本申请实施例中，“示例的”一词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用示例的一词旨在以具体方式呈现概念。
可选地，本申请实施例提及“第一”、“第二”等序数词可以用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一信息和第二信息，只是为了区分不同的信令，而并不是表示这两种信息的内容、优先级、发送顺序或者重要程度等的不同。
在本申请实施例中，存储器可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
本申请实施例提供的方法中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，简称DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，简称DVD))、或者半导体介质(例如，SSD)等。
在本申请实施例中，在无逻辑矛盾的前提下，各实施例之间可以相互引用，例如方法实施例之间的方法和/或术语可以相互引用，例如装置实施例之间的功能和/或术语可以相互引用，例如装置实施例和方法实施例之间的功能和/或术语可以相互引用。
本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (20)

  1. 一种安全通信的方法，其特征在于，包括：
    第一车辆从第一终端设备接收第一消息，所述第一消息用于指示所述第一车辆在车队中的编号；
    所述第一车辆发送第一协商消息，所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；
    所述第一车辆接收来自第二车辆的第一协商消息；其中，所述第二车辆为所述车队中除所述第一车辆之外的其他车辆，所述第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
    在所述第二车辆中，编号与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，所述第一车辆根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；
    所述第一车辆发送第二协商消息，所述第二协商消息包括所述第二协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；
    所述第一车辆接收来自所述第二车辆的第二协商消息；所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
    在所述第二车辆的证书验证通过后，所述第一车辆根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥。
  2. 如权利要求1所述的方法，其特征在于，所述第二车辆的第一协商消息还包含第一签名数据；其中，所述第一签名数据是使用所述第二协商参数和所述第二车辆在所述车队的编号进行签名操作得到的。
  3. 如权利要求2所述的方法，其特征在于，所述在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，所述第一车辆根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数，包括：
    所述在所述第二车辆的证书验证通过后，且所述第一签名数据验证通过后，所述第一车辆根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数。
  4. 如权利要求1-3任一项所述的方法，其特征在于，所述第二车辆的第二协商消息包括还包括第二签名数据；其中，所述第二签名数据是使用所述第二协商参数和所述第二车辆的编号进行签名操作得到的。
  5. 如权利要求4所述的方法，其特征在于，所述在所述第二车辆的证书验证通过后，所述第一车辆根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥，包括：
    在所述第二车辆的证书验证通过后，且所述第二签名数据验证通过后，所述第一车辆根据每个所述第二车辆的第二协商参数生成所述组密钥。
  6. 如权利要求1-5任一项所述的方法，其特征在于，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；
    其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的 车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
  7. 如权利要求1-6任一项所述的方法，其特征在于，所述第一终端设备的证书包含所述第一终端设备的公钥；
    所述第一车辆接收第一消息之后，还包括：
    在所述第一终端设备的证书验证通过后，且所述第三签名数据证书验证通过后，所述第一车辆根据所述车队的车辆信息，确定自身的车辆标识对应的所述编号。
  8. 如权利要求1-7任一项所述的方法，其特征在于，还包括：
    所述第一车辆使用自身生成的第一随机数，基于第一预设算法运算得到第一协商参数。
  9. 如权利要求1-8任一项所述的方法，其特征在于，所述第一车辆根据所述第二车辆的第二协商参数确定第二协商参数，包括：
    所述第一车辆使用自身生成的第一随机数和所述第二车辆的第一协商参数，基于第二预设算法运算得到所述第二协商参数。
  10. 如权利要求1-9任一项所述的方法，其特征在于，所述第一车辆根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥，包括：
    所述第一车辆使用自身生成的第一随机数、所述第二车辆的第二协商参数和所述编号位于所述第一车辆在车队中的编号之后的第二车辆的第二协商参数，基于第三预设算法运算得到所述组密钥。
  11. 如权利要求1-10任一项所述的方法，其特征在于，还包括：
    所述第一车辆向所述车队中的任一车辆发送数据之前，使用所述组密钥对需要交互的数据进行加密，并将所述加密后的数据发送至目标车辆；和/或
    所述第一车辆接收来自所述车队中的任一车辆的数据后，使用所述组密钥对接收到的所述数据进行解密。
  12. 一种安全通信的方法，其特征在于，包括：
    第一终端设备从应用服务器获取车队的车辆信息，所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队中的编号；
    所述第一终端设备向所述车队中每一车辆发送第一消息，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；
    其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
  13. 如权利要求12所述的方法，其特征在于，还包括：
    所述第一终端设备接收来自所述车队中的其他任一车辆的第一协商消息；所述第一终端设备将第一数据包发送至所述车队中的其他任一车辆，所述第一数据包包含所述车队中任一车辆的第一协商消息；和/或
    所述第一终端设备接收来自所述车队中的其他任一车辆的第二协商消息；所述第一终 端设备将第二数据包发送至所述车队中的其他任一车辆，所述第二数据包包含所述车队中任一车辆的第二协商消息。
  14. 如权利要求12或13所述的方法，其特征在于，所述第一终端设备为所述车队中的任一编号的车辆，或所述第一终端设备为路侧设备RSU。
  15. 一种安全通信装置，其特征在于，包括：
    存储器，用于存储程序指令和数据；
    收发器，用于从第一终端设备接收第一消息，所述第一消息用于指示所述第一车辆在车队中的编号；发送第一协商消息，所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自第二车辆的第一协商消息；其中，所述第二车辆为所述车队中除所述第一车辆之外的其他车辆，所述第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
    处理器，用于在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；
    收发器，还用于发送第二协商消息，所述第二协商消息包括所述第二协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自所述第二车辆的第二协商消息；所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；
    处理器，还用于在所述第二车辆的证书验证通过后，根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥。
  16. 一种安全通信的第一终端设备，其特征在于，包括：
    存储器，用于存储程序指令和数据；
    收发器，用于从应用服务器获取车队的车辆信息，所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队中的编号；向所述车队中每一车辆发送第一消息，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的。
  17. 一种计算机程序，其特征在于，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1-11任一项所述的方法，或执行如权利要求12-14任一项所述的方法。
  18. 一种计算机存储介质，其特征在于，所述计算机存储介质中存储有计算机程序，当所述计算机程序被计算机执行时，使得所述计算机执行权利要求1-11任一项所述的方法，或执行如权利要求12-14任一项所述的方法。
  19. 一种芯片，其特征在于，所述芯片用于读取存储器中存储的计算机程序，执行如权利要求1-11任一项所述的方法，或执行如权利要求12-14任一项所述的方法。
  20. 一种安全通信系统，其特征在于，包括：应用服务器、安全通信装置和第一终端设备；
    所述应用服务器，用于向所述第一终端设备发送车队的车辆信息；
    所述第一终端设备，用于从应用服务器获取车队的车辆信息，所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队中的编号；向所述车队中每一车辆发送第一消息，所述第一消息包括协商请求字段、所述车队的车辆信息、第三签名数据和发送所述第一消息的第一设备的证书；其中，所述协商请求字段用于触发所述车队内的车辆发送第一协商消息；所述车队的车辆信息包括所述车队中每一车辆的车辆标识和所述车辆标识对应的所述车辆在所述车队的编号；所述第三签名数据为使用所述第一终端设备的私钥，对第三数字摘要进行加密得到的，所述第三数字摘要是使用所述协商请求字段、所述车队的车辆信息，基于所述预设摘要算法确定的；
    所述安全通信装置，用于从第一终端设备接收第一消息，所述第一消息用于指示所述第一车辆在车队中的编号；发送第一协商消息，所述第一协商消息包括所述第一车辆的第一协商参数、所述第一车辆在车队中的编号和所述第一车辆的证书；接收来自第二车辆的第一协商消息；其中，所述第二车辆为所述车队中除所述第一车辆之外的其他车辆，所述第二车辆的第一协商消息包括所述第二车辆的第一协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；在与所述第一车辆在车队中的编号相邻的车辆的证书验证通过后，根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；根据所述与所述第一车辆在车队中的编号相邻的车辆的第一协商参数确定第二协商参数；接收来自所述第二车辆的第二协商消息；所述第二车辆的第二协商消息包括所述第二车辆的第二协商参数、所述第二车辆在所述车队中的编号和所述第二车辆的证书；在所述第二车辆的证书验证通过后，根据每个所述第二车辆的第二协商参数生成与所述车队中任一车辆进行安全通信的组密钥。
PCT/CN2020/082614 2020-03-31 2020-03-31 一种安全通信的方法及装置 WO2021196043A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202080004876.7A CN112640504B (zh) 2020-03-31 2020-03-31 一种安全通信的方法及装置
JP2022558490A JP7464337B2 (ja) 2020-03-31 2020-03-31 安全な通信方法、装置、端末デバイス、コンピュータプログラム、コンピュータ記憶媒体、チップ、および通信システム
EP20928311.8A EP4117225A4 (en) 2020-03-31 2020-03-31 SECURE COMMUNICATION METHOD AND APPARATUS
PCT/CN2020/082614 WO2021196043A1 (zh) 2020-03-31 2020-03-31 一种安全通信的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/082614 WO2021196043A1 (zh) 2020-03-31 2020-03-31 一种安全通信的方法及装置

Publications (1)

Publication Number Publication Date
WO2021196043A1 true WO2021196043A1 (zh) 2021-10-07

Family

ID=75291256

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/082614 WO2021196043A1 (zh) 2020-03-31 2020-03-31 一种安全通信的方法及装置

Country Status (4)

Country Link
EP (1) EP4117225A4 (zh)
JP (1) JP7464337B2 (zh)
CN (1) CN112640504B (zh)
WO (1) WO2021196043A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113242121B (zh) * 2021-04-15 2023-07-25 哈尔滨工业大学 一种基于组合加密的安全通信方法
CN114040406B (zh) * 2021-10-27 2024-04-26 海信集团控股股份有限公司 一种车载设备的异常信息检测方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108632888A (zh) * 2017-03-24 2018-10-09 中兴通讯股份有限公司 一种车辆群组的建立、更新方法及其装置
CN109640325A (zh) * 2018-12-29 2019-04-16 西安邮电大学 基于可扩展式贡献组密钥协商的面向车队的安全管理方法
CN109963265A (zh) * 2017-12-26 2019-07-02 索尼公司 无线通信系统中的装置和方法、计算机可读存储介质
US20190306680A1 (en) * 2016-07-08 2019-10-03 Jaguar Land Rover Limited Vehicle communication system and method
US10440668B1 (en) * 2018-11-07 2019-10-08 Ford Global Technologies, Llc Vehicle platooning management and power control with LTE/5G V2X communications
CN110798812A (zh) * 2018-08-02 2020-02-14 华为技术有限公司 一种群组通信方法及装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3868313B2 (ja) 2002-03-08 2007-01-17 株式会社デンソークリエイト 鍵共有方法及び通信装置
JP5888189B2 (ja) 2012-08-30 2016-03-16 トヨタ自動車株式会社 車車間通信システム、車車間通信方法および車載端末
US10805086B2 (en) 2017-12-20 2020-10-13 Intel Corporation Methods and arrangements for vehicle-to-vehicle communications
EP3768554A4 (en) * 2018-03-22 2021-11-17 KOC Universitesi SECURE AUTONOMOUS ELECTRONIC DRAWBAR SUPPORTED BY COMMUNICATION IN VISIBLE LIGHT
DE102018214354A1 (de) * 2018-08-24 2020-02-27 Robert Bosch Gmbh Erstes fahrzeugseitiges Endgerät, Verfahren zum Betreiben des ersten Endgeräts, zweites fahrzeugseitiges Endgerät und Verfahren zum Betreiben des zweiten fahrzeugseitigen Endgeräts

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190306680A1 (en) * 2016-07-08 2019-10-03 Jaguar Land Rover Limited Vehicle communication system and method
CN108632888A (zh) * 2017-03-24 2018-10-09 中兴通讯股份有限公司 一种车辆群组的建立、更新方法及其装置
CN109963265A (zh) * 2017-12-26 2019-07-02 索尼公司 无线通信系统中的装置和方法、计算机可读存储介质
CN110798812A (zh) * 2018-08-02 2020-02-14 华为技术有限公司 一种群组通信方法及装置
US10440668B1 (en) * 2018-11-07 2019-10-08 Ford Global Technologies, Llc Vehicle platooning management and power control with LTE/5G V2X communications
CN109640325A (zh) * 2018-12-29 2019-04-16 西安邮电大学 基于可扩展式贡献组密钥协商的面向车队的安全管理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HUAWEI, HISILICON: "Editorial corrections for eV2X TR 33.836", 3GPP DRAFT; S3-193326-EDITORIAL CORRECTIONS FOR EV2X TR 33.836, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. TSG SA, no. Chongqing, China; 20191014 - 20191018, 7 October 2019 (2019-10-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP051796085 *
See also references of EP4117225A4 *

Also Published As

Publication number Publication date
CN112640504A (zh) 2021-04-09
CN112640504B (zh) 2021-12-14
EP4117225A1 (en) 2023-01-11
JP2023519907A (ja) 2023-05-15
JP7464337B2 (ja) 2024-04-09
EP4117225A4 (en) 2023-04-05

Similar Documents

Publication Publication Date Title
WO2020177768A1 (zh) 一种网络验证方法、装置及系统
CN109428875B (zh) 基于服务化架构的发现方法及装置
US20170180330A1 (en) Method and electronic device for vehicle remote control and a non-transitory computer readable storage medium
CN109951823A (zh) 用于车辆到车辆通信的方法和装置
JP2020517144A (ja) Ｖ２ｘ通信装置、及びそのデータ通信方法
CN115474198A (zh) 用于降低的v2x接收器处理负载的方法、网络元件和介质
CN111479244B (zh) 一种v2i车联网身份认证系统及方法
WO2018010474A1 (zh) 一种车联网终端之间安全通信的方法及装置
Wagan et al. Security framework for low latency VANET applications
JP6279821B2 (ja) ワイヤレス通信においてメッセージを認証すること
CN112449323B (zh) 一种通信方法、装置和系统
US11329805B2 (en) First vehicle-side terminal, method for operating the first terminal, second vehicle-side terminal and method for operating the second vehicle-side terminal
WO2021196043A1 (zh) 一种安全通信的方法及装置
CN112055330B (zh) 一种基于5g的v2x车联网安全通信系统及方法
CN108076016B (zh) 车载设备之间的认证方法及装置
CN110602698A (zh) 一种基于混沌映射的车联网完全会话密钥协商方法
WO2021120924A1 (zh) 一种证书申请方法及设备
US20230308875A1 (en) Wi-fi security authentication method and communication apparatus
CN114697122A (zh) 数据传输方法、装置、电子设备及存储介质
WO2021022406A1 (zh) 一种身份验证方法及装置
CN117254910B (zh) 车载自组网络下基于量子随机数的高效组密钥分发方法
CN113455032A (zh) 通信方法及装置
WO2023284658A1 (zh) 一种车辆通信的方法及装置
CN115885496B (zh) 一种通信方法及相关装置
CN112637839A (zh) 一种配网方法、装置、计算机设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20928311

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022558490

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020928311

Country of ref document: EP

Effective date: 20221007

NENP Non-entry into the national phase

Ref country code: DE