WO2021036252A1 - 一种通信、更新密钥的方法及装置 - Google Patents

一种通信、更新密钥的方法及装置 Download PDF

Info

Publication number
WO2021036252A1
WO2021036252A1 PCT/CN2020/081927 CN2020081927W WO2021036252A1 WO 2021036252 A1 WO2021036252 A1 WO 2021036252A1 CN 2020081927 W CN2020081927 W CN 2020081927W WO 2021036252 A1 WO2021036252 A1 WO 2021036252A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
vehicle
mounted device
domain
parameter
Prior art date
Application number
PCT/CN2020/081927
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 华为技术有限公司
Publication of WO2021036252A1 publication Critical patent/WO2021036252A1/zh

Links

Images

Classifications

    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • 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
    • 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

Definitions

  • the embodiments of the present application relate to the field of automatic driving technology, and in particular, to a method and device for communicating and updating keys.
  • Autonomous driving also known as unmanned driving, computer driving, etc.
  • unmanned driving is a technology that realizes unmanned driving through a computer.
  • Autonomous driving relies on the collaboration of artificial intelligence, visual computing, radar, monitoring devices, and global positioning systems to allow computers to operate motor vehicles automatically and safely without any human active operation.
  • the present application provides a method and device for communication and key update, which are used to ensure the security of communication between on-vehicle devices.
  • a communication method is provided, and the execution body of the method may be a vehicle-mounted device or a chip applied to the vehicle-mounted device. Take the vehicle-mounted equipment as the execution subject as an example for description.
  • the first in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device; the first in-vehicle device determines the second message according to the first key and the first message; the first in-vehicle device Send the second message to the second in-vehicle device.
  • the message of the vehicle-mounted device can be encrypted by the key to ensure the communication security of the vehicle-mounted device.
  • the first key is generated according to the first in-vehicle device, that is, different in-vehicle devices correspond to different keys. Compared with the method of using different keys for different types of messages, the number of keys can be reduced, which is convenient for encryption. Key management.
  • the first in-vehicle device is an intra-domain device or a domain control device, and the first in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device, specifically: The first in-vehicle device determines the first key according to the identifier of the first in-vehicle device and a total key, where the total key is a key corresponding to a gateway that manages the first in-vehicle device.
  • the first key satisfies the following conditions:
  • the first key KDF (total key, the identification of the first vehicle-mounted device), and the KDF represents a key derivation algorithm.
  • each vehicle-mounted device is generated according to its own vehicle-mounted device's identity.
  • the in-vehicle device uses its own assigned key to communicate. Because the number of on-board devices is much smaller than the number of CAN types. The above method can reduce the number of keys and facilitate key management.
  • the first in-vehicle device is an intra-domain device, and the first in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device, including: The device determines the first key according to the identity of the domain control device, the master key, and the identity of the first in-vehicle device.
  • the domain control device is used to manage the first in-vehicle device.
  • the key is the key corresponding to the gateway that manages the domain control device.
  • the first vehicle-mounted device determines the first key according to the identifier of the domain control device, the master key, and the identifier of the first vehicle-mounted device, including: the first vehicle-mounted device determines the first key according to the identification of the first vehicle-mounted device.
  • the identification of the domain control device and the total key determine a second key; the first vehicle-mounted device determines the first key according to the second key and the identification of the first vehicle-mounted device.
  • each vehicle-mounted device is generated according to its own vehicle-mounted device's identity.
  • the in-vehicle device uses its own assigned key to communicate. Because the number of on-board devices is much smaller than the number of CAN types. The above method can reduce the number of keys and facilitate key management.
  • a communication method is provided, and the execution subject of the method may be an in-vehicle device or a chip applied to the in-vehicle device.
  • an in-vehicle device is taken as an example of the execution subject.
  • the second in-vehicle device receives the second message sent by the first in-vehicle device; the second in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device; the second in-vehicle device determines the first key of the first in-vehicle device according to the A key and a second message determine the first message.
  • the message received by the vehicle-mounted device is encrypted to ensure the security of communication between different vehicle-mounted devices.
  • the first in-vehicle device is a domain control device or an intra-domain device
  • the second in-vehicle device determines the first key of the first in-vehicle device according to the identity of the first in-vehicle device , Including: the second vehicle-mounted device determines the first key according to the identifier of the first vehicle-mounted device and a total key, where the total key is a key corresponding to a gateway that manages the first vehicle-mounted device.
  • each vehicle-mounted device is generated according to its own vehicle-mounted device's identity.
  • the in-vehicle device uses its own assigned key to communicate. Because the number of on-board devices is much smaller than the number of CAN types. The above method can reduce the number of keys and facilitate key management.
  • the first in-vehicle device is an intra-domain device
  • the second in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device, including: a second in-vehicle device
  • the device determines the first key according to the identity of the domain control device, the master key, and the identity of the first in-vehicle device.
  • the domain control device is used to manage the first in-vehicle device.
  • the key is the key corresponding to the gateway that manages the domain control device.
  • the second vehicle-mounted device determines the first key according to the identity of the domain control device, the master key, and the identity of the first vehicle-mounted device, including: the second vehicle-mounted device determines the first key according to the identity of the first vehicle-mounted device.
  • the identification of the domain control device and the total key determine a second key; the second vehicle-mounted device determines the first key according to the second key and the identification of the first vehicle-mounted device.
  • each vehicle-mounted device is generated according to its own vehicle-mounted device's identity.
  • the in-vehicle device uses its own assigned key to communicate. Because the number of on-board devices is much smaller than the number of CAN types. The above method can reduce the number of keys and facilitate key management.
  • a method for updating a key is provided.
  • the execution subject of the method may be a vehicle-mounted device or a chip applied to the vehicle-mounted device.
  • an in-vehicle device is used as an example of execution.
  • the first vehicle-mounted device receives the first parameter sent by the second vehicle-mounted device; the first vehicle-mounted device determines the first key according to the first parameter; the first vehicle-mounted device updates the first vehicle-mounted device according to the first key The key of the device.
  • the above method can realize the real-time update of the key of the in-vehicle device to ensure communication security.
  • the first vehicle-mounted device determines the first key according to the first parameter, including: the first vehicle-mounted device determines the first key according to the second key, the first parameter, and the The identifier determines the first key, the second key is the initial key of the first vehicle-mounted device, or the second key is the pre-update key of the first vehicle-mounted device.
  • the first key satisfies the following conditions:
  • the first key KDF (the second key, the identification of the first vehicle-mounted device, the first parameter), and the KDF represents a key derivation algorithm.
  • a method for updating a key is provided.
  • the execution subject of the method may be a vehicle-mounted device or a chip applied to the vehicle-mounted device.
  • an in-vehicle device is used as an example of execution.
  • the second in-vehicle device receives the first parameter sent by the third in-vehicle device, the third in-vehicle device is a gateway that manages the second in-vehicle device, and the second in-vehicle device is a domain controller that manages the first in-vehicle device;
  • the in-vehicle device sends a first parameter to the first in-vehicle device, where the first parameter is used to update the key of the first in-vehicle device.
  • the above method can realize the real-time update of the key of the in-vehicle device to ensure communication security.
  • the first parameter is also used to update the key of the second vehicle-mounted device
  • the method further includes: the second vehicle-mounted device determines a third key according to the first parameter; The second in-vehicle device updates the key of the second in-vehicle device according to the third key.
  • the second in-vehicle device determines the third key according to the first parameter, including: the second in-vehicle device determines the third key according to the fourth key, the identification of the second in-vehicle device, and the first Parameter to determine the third key, the fourth key is the initial key of the second vehicle-mounted device, or the fourth key is the pre-update key of the second vehicle-mounted device.
  • the third key satisfies the following conditions:
  • the third key KDF (the fourth key, the identification of the second vehicle-mounted device, the first parameter), and the KDF represents a key derivation algorithm.
  • a method for updating a key is provided.
  • the execution subject of the method is an in-vehicle device or a chip applied to the in-vehicle device.
  • an in-vehicle device is taken as an example of execution.
  • the first in-vehicle device determines a first key based on the identifier of the second in-vehicle device and the first parameter, where the first key is the key to be updated for the second in-vehicle device, and the first in-vehicle device is for managing the second 2.
  • a gateway of a vehicle-mounted device, the second vehicle-mounted device is a domain control device or an intra-domain device; the first vehicle-mounted device sends the first key to the second vehicle-mounted device.
  • the first vehicle-mounted device determines the first key according to the identifier of the second vehicle-mounted device and the first parameter, including: the first vehicle-mounted device determines the first key according to the identifier of the second vehicle-mounted device, The total key and the first parameter determine the first key, and the total key is the key corresponding to the gateway that manages the first vehicle-mounted device.
  • the first key satisfies the following conditions:
  • the first key KDF (total key, identification of the second vehicle-mounted device, first parameter), and the KDF represents a key derivation algorithm.
  • the second in-vehicle device is a domain control device
  • the first in-vehicle device sends the first key to the second in-vehicle device, including: the first in-vehicle device directly sends the first key to the second in-vehicle device
  • the vehicle-mounted device sends the first key.
  • the second in-vehicle device is an intra-domain device
  • the first in-vehicle device sends the first key to the second in-vehicle device, including: the first in-vehicle device sends the first key to the third in-vehicle device A key
  • the third in-vehicle device is a domain controller that manages the second in-vehicle device, so that the third in-vehicle device forwards the first key to the second in-vehicle device.
  • a method for updating a key is provided.
  • the execution subject of the method is a vehicle-mounted device, or a chip applied to the vehicle-mounted device.
  • an in-vehicle device is taken as an example of execution.
  • the second in-vehicle device receives the first key sent by the first in-vehicle device, the first key is determined according to the identifier of the second in-vehicle device and the first parameter, and the first in-vehicle device is for managing the second in-vehicle device
  • the second in-vehicle device is a domain control device or an intra-domain device; the second in-vehicle device updates the key of the second in-vehicle device according to the first key.
  • the above-mentioned method can realize the update of the key of the vehicle-mounted device and ensure the communication security of the vehicle-mounted device.
  • the first key is determined based on the identification of the second vehicle-mounted device and the first parameter, specifically: the first key is based on the identification of the second vehicle-mounted device, As determined by the total key and the first parameter, the total key is the key of the gateway.
  • the first key satisfies the following conditions:
  • the first key KDF (total key, identification of the second vehicle-mounted device, first parameter), and the KDF represents a key derivation algorithm.
  • the second in-vehicle device is a domain control device, and the second in-vehicle device receives the first key sent by the first in-vehicle device, including: the second in-vehicle device directly receives the first in-vehicle device The first key sent by the device.
  • the second in-vehicle device is an intra-domain device, and the second in-vehicle device receives the first key sent by the first in-vehicle device, including: the second in-vehicle device receives the first key sent by the third in-vehicle device A key, the third in-vehicle device is a domain control device that manages the second in-vehicle device, and the first key is sent by the first in-vehicle device to the third in-vehicle device.
  • a communication device is provided.
  • the communication device has the function of realizing the behavior in the method embodiment of the above-mentioned first aspect.
  • the function can be realized by software, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device includes: a processing module configured to determine the first key of the first in-vehicle device according to the identifier of the first in-vehicle device, and determine the first key of the first in-vehicle device according to the first key and the first message The second message.
  • the transceiver module is used to send the second message to the second vehicle-mounted device.
  • These modules can perform the corresponding functions in the above-mentioned method examples of the first aspect. For details, please refer to the detailed description in the method examples, which will not be repeated here.
  • a communication device is provided, and the beneficial effects can be referred to the description of the second aspect and will not be repeated here.
  • the communication device has the function of realizing the behavior in the method embodiment of the second aspect described above.
  • the function can be realized by software, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device includes: a transceiver module, configured to receive the second message sent by the first vehicle-mounted device.
  • the processing module is configured to determine the first key of the first vehicle-mounted device according to the identifier of the first vehicle-mounted device, and determine the first message according to the first key and the second message.
  • a communication device is provided.
  • the communication device has the function of realizing the behavior in the method embodiment of the third aspect described above.
  • the function can be realized by software, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device includes: a transceiver module, configured to receive the first parameter sent by the second vehicle-mounted device.
  • the processing module is configured to determine the first key according to the first parameter, and update the key of the first vehicle-mounted device according to the first key.
  • a communication device is provided.
  • the communication device has the function of realizing the behavior in the method embodiment of the fourth aspect.
  • the function can be realized by software, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device includes: a transceiver module for receiving the first parameter sent by a third vehicle-mounted device, the third vehicle-mounted device is a gateway for managing the second vehicle-mounted device, and the second vehicle-mounted device is The controller that manages the first in-vehicle device.
  • the transceiver module is also used to send the first parameter to the first vehicle-mounted device, and the first parameter is used to update the key of the first vehicle-mounted device.
  • These modules can perform the corresponding functions in the above-mentioned method example of the fourth aspect. For details, please refer to the detailed description in the method example, which will not be repeated here.
  • a communication device is provided, and the beneficial effects can be referred to the description of the fifth aspect and will not be repeated here.
  • the communication device has the function of realizing the behavior in the method embodiment of the fifth aspect described above.
  • the function can be realized by software, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device includes: a processing module, configured to determine a first key according to an identifier of a second vehicle-mounted device and a first parameter, and the first key is the second vehicle-mounted device
  • the first in-vehicle device is a gateway for managing the second in-vehicle device, the second in-vehicle device is a domain control device or an intra-domain device; the transceiver module is used to send the The first key.
  • a communication device is provided.
  • the communication device has the function of realizing the behavior in the method embodiment of the sixth aspect described above.
  • the function can be realized by software, or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above-mentioned functions.
  • the communication device includes: a transceiver module, configured to receive a first key sent by a first vehicle-mounted device, and the first key is based on the identification of the second vehicle-mounted device and the first parameter.
  • the first in-vehicle device is a gateway for managing a second in-vehicle device, and the second in-vehicle device is a domain control device or an intra-domain device; the processing module is configured to update the second vehicle device according to the first key The key of the in-vehicle device.
  • These modules can perform the corresponding functions in the above-mentioned sixth aspect example. For details, please refer to the detailed description in the method example, which will not be repeated here.
  • a device in a thirteenth aspect, is provided, and the device may be the first vehicle-mounted device in the foregoing method embodiment, or a chip set in the first vehicle-mounted device.
  • the device includes a communication interface and a processor.
  • a memory may also be included. The memory is used to store a computer program or instruction, and the processor is coupled with the memory and a communication interface. When the processor executes the computer program or instruction, the device executes the method executed by the first vehicle-mounted device in the foregoing method embodiment.
  • a device in a fourteenth aspect, may be the second vehicle-mounted device in the foregoing method embodiment, or a chip set in the second vehicle-mounted device.
  • the device includes a communication interface processor.
  • a memory may also be included. The memory is used to store a computer program or instruction, and the processor is coupled with the memory and a communication interface. When the processor executes the computer program or instruction, the device executes the method executed by the second vehicle-mounted device in the foregoing method embodiment.
  • a computer program product includes: computer program code, which when the computer program code is running, causes the methods executed by the first vehicle-mounted device in the above aspects to be executed.
  • a computer program product comprising: computer program code, when the computer program code is executed, the method executed by the second vehicle-mounted device in the above aspects is executed.
  • the present application provides a chip system, which includes a processor, configured to implement the functions of the first vehicle-mounted device in the methods of the foregoing aspects.
  • the chip system further includes a memory for storing program instructions and/or data.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • the present application provides a chip system, which includes a processor, configured to implement the functions of the second vehicle-mounted device in the methods of the foregoing aspects.
  • the chip system further includes a memory for storing program instructions and/or data.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • this application provides a computer-readable storage medium that stores a computer program, and when the computer program is executed, the method executed by the first in-vehicle device in the above aspects is implemented.
  • the present application provides a computer-readable storage medium that stores a computer program, and when the computer program is executed, the method executed by the second in-vehicle device in the above aspects is implemented.
  • FIG. 1 is a network architecture applicable to the embodiments of this application.
  • Figure 2 is an E/E architecture applicable to the embodiments of this application.
  • Figure 3 is a key generation method provided by an embodiment of the application.
  • FIG. 4 is a flowchart of a communication method provided by an embodiment of this application.
  • FIG. 5 is a schematic diagram of protecting the first message according to an embodiment of the application.
  • Figure 6 is another key generation method provided by an embodiment of the application.
  • Fig. 7 is a schematic diagram of pre-keying an ECU according to an embodiment of the application.
  • FIG. 8 is a method for generating a key provided by an embodiment of the application.
  • FIG. 9 is a schematic diagram of pre-keying an ECU according to an embodiment of the application.
  • FIG. 10 is a flowchart of updating a key provided by an embodiment of the application.
  • FIG. 11 is another flowchart of updating a key provided by an embodiment of the application.
  • FIG. 12 is a schematic diagram of a communication device provided by an embodiment of this application.
  • FIG. 13 is another schematic diagram of a communication device provided by an embodiment of this application.
  • a network architecture to which the embodiment of this application is applicable includes: a terminal device 10 and an access network device 20.
  • the number of terminal devices 10 is two or more, and sidelink information can be transmitted between different terminal devices via sidelink (SL).
  • the side link information may include data and/or scheduling assistance (SA).
  • SA scheduling assistance
  • the side link information may also include side link feedback, and the side link feedback may include channel state information (CSI), hybrid automatic repeat request (HARQ), etc.
  • CSI channel state information
  • HARQ hybrid automatic repeat request
  • the HARQ may include a positive acknowledgement (acknowledgement, ACK) or a negative acknowledgement (negtive acknowledgement, NACK).
  • ACK positive acknowledgement
  • NACK negative acknowledgement
  • the foregoing data may also be referred to as data information
  • scheduling allocation may also be referred to as scheduling allocation information
  • side link feedback may also be referred to as side link feedback information, etc., which are not limited.
  • the side link transmission can be applied to a vehicle to X (V2X) scenario, and X can refer to any object.
  • IoV communication can include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and vehicle-to-vehicle (V2V). network, V2N) and so on.
  • the Internet of Vehicles may also be referred to as a cooperative-intelligent transport system (C-ITS).
  • side-link transmission may be applied to device-to-device (D2D) communication.
  • D2D may refer to direct communication between terminal devices through technologies such as wireless network, Bluetooth, or D2D transmission, etc., which is not limited.
  • Uu air interface can be understood as a universal UE to network interface (universal UE to network interface).
  • Uu air interface transmission includes downlink transmission and uplink transmission.
  • Downlink transmission refers to the access network device 20 sending information to the terminal device 10, and the downlink transmission information may be referred to as downlink information or downlink signal.
  • the downlink information or downlink signal may include one of a downlink data signal, a downlink control signal, a channel state information reference signal (CSI-RS), and a phase tracking reference signal (PTRS). Or more.
  • the channel used to transmit downlink information or downlink signals is called a downlink channel.
  • the downlink channel can include one or more of a physical downlink shared channel (PDSCH) and a physical downlink control channel (PDCCH) .
  • the PDCCH is used to carry downlink control information (DCI)
  • the PDSCH is used to carry downlink data (data)
  • the downlink data may also be referred to as downlink data information.
  • Uplink transmission refers to the terminal device 10 sending information to the access network device 20, and the uplink transmission information may be referred to as uplink information or uplink signal.
  • the uplink information or uplink signal may include one or more of uplink data signal, uplink data information, sounding reference signal (SRS), and so on.
  • SRS sounding reference signal
  • a channel used to transmit uplink information or uplink signals is called an uplink channel, and the uplink channel may include at least one of a physical uplink shared channel (PUSCH) and a physical uplink control channel (PUCCH).
  • PUSCH is used to carry uplink data.
  • the uplink data may also be referred to as uplink data information.
  • the PUCCH is used to carry uplink control information (UCI) fed back by the terminal device.
  • UCI may include channel state information (CSI), ACK and/or NACK, etc. fed back by the terminal device.
  • a server 30 may also be included.
  • the server 30 may be a core network device.
  • the terminal device 10 can be connected to the access network device 20 in a wireless manner, and the access network device 20 can be connected to the server 30 in a wired or wireless manner.
  • the server 30 and the access network device 20 may be independent physical devices.
  • the server 30 and the access network device 20 may be the same physical device, and all/part of the logical functions of the server 30 and the access network device 20 are integrated on the physical device.
  • the terminal device 10 can be referred to as a terminal for short. It is a device with wireless transceiver function.
  • the terminal device can be deployed on land, including indoor or outdoor, handheld or vehicle-mounted; or on the water. (Such as ships, etc.); it can also be deployed in the air (such as airplanes, balloons, and satellites, etc.).
  • the terminal device may be a mobile phone (mobile phone), a tablet computer (pad), a computer with wireless transceiver function, virtual reality (VR) terminal equipment, augmented reality (AR) terminal equipment, industrial control ( Wireless terminal equipment in industrial control, wireless terminal equipment in self-driving, wireless terminal equipment in remote medical, wireless terminal equipment in smart grid, transportation safety (transportation) Wireless terminal equipment in safety), wireless terminal equipment in a smart city (smart city), wireless terminal equipment in a smart home (smart home), and may also include user equipment (UE), etc.
  • UE user equipment
  • the terminal device can also be a cellular phone, a cordless phone, a session initiation protocol (session initiation protocol, SIP) phone, a wireless local loop (WLL) station, a personal digital assistant (personal digital assistant, PDA), with wireless communication Functional handheld devices, computing devices, or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in the 5th generation (5G) network in the future, or public land mobile communication networks that evolve in the future ( Public land mobile network (PLMN) terminal equipment, etc.
  • SIP session initiation protocol
  • WLL wireless local loop
  • PDA personal digital assistant
  • Terminal equipment can sometimes be called terminal equipment, user equipment (UE), access terminal equipment, vehicle terminal equipment, industrial control terminal equipment, UE unit, UE station, mobile station, mobile station, remote station, remote terminal Equipment, mobile equipment, UE terminal equipment, terminal equipment, wireless communication equipment, UE agent or UE device, etc.
  • the terminal device can also be fixed or mobile. The embodiment of the present application does not limit this.
  • the access network device 20 is a device that provides wireless communication functions for terminal devices.
  • the access network equipment includes, for example, but is not limited to: next-generation base stations (generation nodeB, gNB), evolved node B (evolved node B, eNB), radio network controller (RNC), node B ( node B, NB), base station controller (BSC), base transceiver station (BTS), home base station (for example, home evolved nodeB, or home node B, HNB), baseband unit (baseband unit) , BBU), transmitting and receiving point (TRP), transmitting point (TP), mobile switching center, etc.
  • generation nodeB generation nodeB, gNB
  • evolved node B evolved node B
  • RNC radio network controller
  • node B node B, NB
  • BSC base station controller
  • BTS base transceiver station
  • home base station for example, home evolved nodeB, or home node B, HNB
  • baseband unit baseband unit
  • BBU transmitting and
  • the access network equipment can also be a wireless controller, a centralized unit (CU), and/or a distributed unit (DU) in a cloud radio access network (cloud radio access network, CRAN) scenario, or a network
  • the equipment may be a relay station, an access point, a vehicle-mounted device, a terminal device, a wearable device, and a network device in a future 5G network or a network device in a future evolved PLMN network.
  • the terminal device can communicate with multiple access network devices of different technologies.
  • the terminal device can communicate with an access network device that supports long term evolution (LTE), or can communicate with an access network device that supports 5G. , It can also be dual-connected with LTE-supporting access network equipment and 5G-supporting access network equipment.
  • LTE long term evolution
  • 5G 5G-supporting access network equipment
  • the terminal device 10 may be a fixed location or a mobile device, which is not limited.
  • the network architecture shown in FIG. 1 may also include other network devices, such as wireless relay devices and wireless backhaul devices, which are not limited.
  • the number of terminal devices, access network devices, and servers is not limited.
  • an electrical/electronic (E/E) architecture can be adopted.
  • the architecture includes three levels, namely, the gateway electronic control unit. (electronic control unit, ECU), domain controller ECU, and domain ECU.
  • ECU electronic control unit
  • the domain controller ECU is used to manage the intra-domain ECUs in the corresponding domain.
  • the gateway ECU is used to manage the domain controller ECU.
  • 4 domains can be divided into vehicle control system domain, entertainment system domain, diagnosis system domain, and intelligent driving system domain.
  • Each domain corresponds to a domain controller ECU.
  • the above 4 domains correspond to 4 domain controller ECUs in total.
  • the gateway ECU is used to manage the four domain controller ECUs.
  • ECUs can communicate based on a control area network (controller area network, CAN) protocol, and CAN messages can be sent between different ECUs.
  • CAN controller area network
  • the key can be used to protect the CAN message.
  • Different types of CAN messages correspond to different keys. In the entire E/E architecture, there are many types of CAN messages, and the number of corresponding keys is also large, which makes management difficult.
  • FIG. 2 is only for schematic illustration, and is not intended to limit the embodiments of the present application.
  • the method provided in the embodiment of the present application can be used in the three-tier architecture shown in FIG. 2 as well as other two-tier or one-tier architectures, etc., which is not limited.
  • a key generation method is provided, which can be used to generate keys for different types of CAN messages.
  • the specific process is as follows: First, there is a master key in an E/E architecture, and the master key can also be called the root key. Using the total key, a CAN bus key can be generated. Using CAN bus keys, different types of CAN message keys can be generated. Since the type of CAN can be represented by CAN ID, for ease of description, in the following example, CAN ID is used to represent the type of CAN message.
  • the entire E/E architecture includes 4 CAN buses, namely CAN bus 1, CAN bus 2, CAN bus 3, and CAN bus 4.
  • the four CAN buses in FIG. 2 may have a corresponding relationship with the four domains in FIG. 1.
  • CAN bus 1 in Fig. 2 may correspond to the vehicle control system domain
  • CAN bus 2 may correspond to the entertainment system domain
  • CAN bus 3 may correspond to the diagnosis system domain
  • CAN bus 4 may correspond to the intelligent driving system domain.
  • KDF total key, CAN bus ID
  • KDF represents a key derivation algorithm
  • KDF can also be called a key derivation function.
  • the key of CAN bus 1 KDF (total key, CAN bus 1).
  • different CAN buses may include the same or different types of CAN messages. For example, referring to FIG. 3, four types of CAN messages can be included in the CAN bus 1. The IDs of the four types of CAN messages are A, B, C, and D respectively.
  • the CAN bus key can be used to generate keys for different types of CAN messages on the bus.
  • CAN ID key KDF (CAN bus key, CAN ID).
  • CAN bus 1 includes four types of CAN messages A, B, C, and D.
  • a communication method is provided.
  • the principle of the method is: different ECUs are assigned different keys. Because in the E/E architecture, the number of ECUs is much smaller than the number of CAN messages. By adopting the method of this application, the number of keys in the E/E architecture can be reduced, which is convenient for management.
  • ECU Electronic control unit
  • ECU also known as “driving computer”, “vehicle computer”, “car-specific microcomputer controller, etc.”
  • driving computer is one of the core components of modern vehicle electronics.
  • ECU can be composed of large-scale integrated circuits such as microprocessor, memory, input/output interface, analog-to-digital converter, shaping and driving.
  • the vehicle-mounted device may include one or more ECUs, and the ECU and the vehicle-mounted device are not distinguished from each other.
  • the gateway (gateway)
  • the gateway is the core part of the vehicle architecture.
  • the gateway can route network data such as CAN, LIN, MOST, and FlexRay in different networks.
  • the gateway can manage the domain control equipment and the equipment in the domain.
  • the gateway may include a gateway ECU, and the gateway and the gateway ECU are not distinguished from each other.
  • the vehicle electronics can be divided into several domains.
  • the power transmission domain the body electronics domain, and the auxiliary driving domain.
  • There is a domain control device in each domain which is used to manage the devices in the domain.
  • the domain control device may also be called a domain controller.
  • the domain control device includes the domain control ECU, and the domain control device and the domain control device ECU are not distinguished from each other.
  • the vehicle electronics can be divided into several domains.
  • the power transmission domain the body electronics domain, and the auxiliary driving domain.
  • Each domain may include a domain controller and multiple controlled devices, and the domain devices may specifically refer to controlled devices in each domain.
  • the intra-domain devices may include intra-domain ECUs, and intra-domain devices and intra-domain ECUs are not distinguished from each other.
  • first and second in the examples of this application are only used for the purpose of distinguishing description, and cannot be understood as indicating or implying relative importance, nor as indicating or implying order. .
  • first message and second message etc.
  • Multiple means two or more.
  • “And/or” describes the association relationship of the associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A alone exists, A and B exist at the same time, and B exists alone, where A, B can be singular or plural.
  • the character “/” generally indicates that the associated objects before and after are in an "or” relationship.
  • At least one item (a) refers to any combination of these items, including any combination of a single item (a) or a plurality of items (a).
  • at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.
  • the execution subject of the flow may be an ECU or a vehicle-mounted device, etc., which is not limited.
  • an in-vehicle device is used as the execution subject for description.
  • the vehicle-mounted equipment in the process shown in FIG. 4 may be specifically located inside the terminal device 10 in FIG. 1, or the vehicle-mounted equipment in the process shown in FIG. 4 may include one or more ECUs in the architecture shown in FIG. It can be a gateway ECU, a domain controller ECU, or an intra-domain ECU in FIG. 2 without limitation. It can be understood that the functions of the vehicle-mounted device may be implemented by the vehicle-mounted device, or implemented by supporting the vehicle-mounted device through other devices.
  • the specific process is:
  • the first in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device.
  • the first in-vehicle device may be a domain control device or an intra-domain device, and the first in-vehicle device may determine the first key according to the identity of the first in-vehicle device and the total key.
  • KDF total key, the identification of the first vehicle-mounted device
  • KDF represents the key derivation algorithm
  • the total key is the key corresponding to the gateway
  • the gateway can Manage the first in-vehicle equipment.
  • the identifier of the first vehicle-mounted device may also be referred to as the ID of the first vehicle-mounted device
  • the KDF may also be referred to as a key derivation function.
  • the first in-vehicle device may be a domain control device, and the first key of the first in-vehicle device may be determined according to the identification and the total key of the first in-vehicle device.
  • the process can be referred to the foregoing record, and will not be described here.
  • the first in-vehicle device may be an intra-domain device, and the process of determining the first key of the first in-vehicle device may be: determining the domain controller that manages the first in-vehicle device; The identification of the first key is determined.
  • the first vehicle-mounted device may first determine the second key according to the identity of the domain control device and the total key.
  • the first key is determined.
  • the first in-vehicle device determines the second message according to the first key and the first message.
  • the first in-vehicle device may generate a message authentication code (MAC) according to the first key; the first in-vehicle device determines a freshness value (freshness value).
  • the first in-vehicle device determines the second message according to the first message, the MAC, and the freshness value.
  • the payload of the first message may be composed of actual messages, and the payload of the second message may be composed of actual messages, MAC, and freshness value.
  • the fresh value and the authentication code may be truncated.
  • the payload of the second message may consist of the actual message, the truncated MAC, and the truncated fresh value.
  • truncation (or called configuration) can be started at the least significant bit (LSB) of the freshness value
  • MSB most significant bit
  • the first in-vehicle device sends a second message to the second in-vehicle device.
  • the process shown in FIG. 4 may further include: S404.
  • the second in-vehicle device determines the first key of the first in-vehicle device according to the identifier of the first in-vehicle device.
  • the corresponding relationship between the key and the in-vehicle device is stored in the second in-vehicle device.
  • the second in-vehicle device may determine the identity of the first in-vehicle device.
  • the first key corresponding to the identification of the first in-vehicle device is determined in the corresponding relationship between the key and the in-vehicle device.
  • the second in-vehicle device may determine the identity of the first in-vehicle device.
  • the second in-vehicle device may determine the first key according to the identification of the first in-vehicle device.
  • the process of determining the first key by the second in-vehicle device according to the identification of the first in-vehicle device is similar to the process of determining the first key by the first in-vehicle device according to the identification of the first in-vehicle device, and will not be repeated here.
  • the second in-vehicle device determines the first message according to the first key and the second message.
  • the payload of the second message may be composed of the actual message, MAC, and freshness value.
  • the second in-vehicle device may compare the freshness value in the second message with the freshness value stored locally. If the freshness value in the second message is higher than the freshness value stored locally, it is considered that the second message has not been tampered with.
  • the principle is: when the first in-vehicle device sends the first message, it can assign fresh values to different messages according to the time sequence. For example, according to the time sequence, the first messages sent by the first in-vehicle device are message A, message B, and message C, respectively.
  • the first in-vehicle device may be message A with a fresh value of 00, message B with a fresh value of 01, and message C with a fresh value of 10. Then, when the second in-vehicle device receives message A, it can save the fresh value 00 of message A.
  • message B When message B is received, it can first verify whether the freshness value 01 of message B is higher than the stored freshness value 00. If it is high, it proves that the currently received message B is fresh. Otherwise, it is considered that the currently received message B is not fresh, and someone illegally resends the transmitted message (for example, message A).
  • the above process is the process of replay attack. It can be seen that by adding a fresh value to the second message, replay attacks can be prevented.
  • the second in-vehicle device may also determine the first key according to the record in S404.
  • the second in-vehicle device calculates the MAC according to the first key.
  • the second in-vehicle device compares the MAC in the second message with the MAC calculated according to the first key in S404. If it is relatively successful, the second in-vehicle device considers the second message to be reliable, that is, the second message has not been tampered with.
  • the first in-vehicle device and the second in-vehicle device can communicate through the CAN protocol.
  • the first message in the above-mentioned FIG. 4 process can also be referred to as the first CAN message, and the second message can also be referred to as the second CAN message.
  • the process of "determining the second message based on the first key and the first message" in S402 can also be referred to as: protecting the first message according to the first key, and the protection may specifically be integrity protection And anti-replay attack.
  • each vehicle-mounted device is assigned a different key, and the key of each vehicle-mounted device is generated according to its own vehicle-mounted device identification.
  • the in-vehicle device uses its own assigned key to communicate. Because the number of on-board devices is much smaller than the number of CAN types. Compared with the method of allocating different keys for different types of CAN messages, the method of the embodiments of the present application can reduce the number of keys and facilitate key management.
  • a method for generating a key by which a key can be allocated to the first vehicle-mounted device in the process shown in FIG. 4 above.
  • the specific process may be: generating the first key of the first in-vehicle device according to the identification of the first in-vehicle device and the total key.
  • the first key of the first in-vehicle device may satisfy the following conditions:
  • the first key KDF (total key, the identification of the first vehicle-mounted device), KDF represents the key derivation algorithm.
  • the first in-vehicle device and the second in-vehicle device in the process shown in FIG. 4 may belong to the terminal 10 in the process shown in FIG. 1, that is, the terminal device 10 may include the first in-vehicle device and the second in-vehicle device. Car Equipment.
  • a master key can be preset, and other keys of the vehicle-mounted device can be derived by using the master key.
  • E/E architecture is adopted in the terminal device 10 (for example, FIG.
  • the gateway ECU is a typical E/E architecture
  • one E/E architecture corresponds to a master key
  • the master key can be preset to the gateway ECU.
  • the total key may also be referred to as the root key
  • the KDF may also be referred to as a key derivation function
  • the identification of the first vehicle-mounted device may also be referred to as the first vehicle-mounted device ID.
  • an in-vehicle device includes an ECU
  • the in-vehicle device and the ECU can be replaced with each other.
  • ECU is taken as an example for related description.
  • the terminal device includes 5 ECUs, namely the gateway ECU, the first ECU, the second EUC, the third ECU, and the fourth ECU.
  • the gateway ECU corresponds to the total key
  • the first ECU corresponds to the first key
  • the second ECU corresponds to the second key
  • the third ECU corresponds to the third key
  • the fourth ECU corresponds to the fourth key
  • the first key, the second key, the third key, and the fourth key can be derived by using the total key and the ID of the ECU.
  • the first ECU, the second ECU, the third ECU, and the fourth ECU may be domain control ECUs or intra-domain ECUs in the typical E/E architecture shown in FIG. 2 above, and are not limited.
  • the method of this example can be used to calculate the key of the domain control ECU in the E/E architecture and the key of the ECU in the domain.
  • the key of the domain controller ECU is calculated in the same way as the key of the ECU in the domain, and the only difference is that the ECU IDs taken by the two are different.
  • the above process can be described as: calculating the key of each ECU in the E/E architecture according to the total key and the ECU ID.
  • Gateway ECU Store a master key and the keys of all ECUs that interact with it with CAN messages. For example, if the gateway ECU has a CAN message interaction with the four domain controller ECUs shown in FIG. 7, then the gateway ECU may also store the keys of the above four domain controllers.
  • Domain controller ECU stores its own key and the key of the ECU with which it has CAN message interaction on the bus or other domain.
  • In-domain ECU stores its own key and keys of all ECUs on the bus or other domains that have CAN message interaction with it.
  • N ECUs are included, and the N ECUs include a domain controller ECU and an intra-domain ECU. Based on the ID of each ECU in the N ECUs, correspondingly, generating N keys is taken as an example for description, and is not a limitation of the present application.
  • a key generation method is provided, by which a key can be allocated to the first vehicle-mounted device in the process shown in FIG. 4, and the first vehicle-mounted device may be a domain controller device or an intra-domain device.
  • the process of generating the first key of the first in-vehicle device may be: determining the key of the first in-vehicle device according to the total key and the identity of the first in-vehicle device.
  • an in-vehicle device includes an ECU
  • the in-vehicle device and the ECU can be replaced with each other.
  • ECU is taken as an example for related description.
  • the terminal device includes one gateway ECU, two domain controllers EUC, and four EUCs in the domain as an example
  • the two domain controller ECUs mentioned above are the first domain controller ECU and the second domain controller ECU.
  • the four ECUs in the domain are the ECU in the first domain, the ECU in the second domain, the ECU in the third domain, and the ECU in the fourth domain.
  • the key of the gateway ECU is the master key
  • the key of the first domain controller ECU is the key of the first domain controller
  • the key of the second domain controller ECU is the key of the second domain controller.
  • the key of the ECU in the first domain is the key in the first domain
  • the key of the ECU in the second domain is the key in the second domain
  • the key of the ECU in the third domain is the key in the third domain
  • the key of the ECU in the fourth domain is the key in the fourth domain.
  • the key is the key in the fourth domain.
  • the first domain controller key and the second domain controller key may be generated first based on the total key.
  • a first domain key and a second domain key are generated.
  • the third domain key and the fourth domain key are generated.
  • ECU key in the domain KDF (domain controller ECU key, ECU ID in the domain).
  • Gateway ECU Stores the total key and the keys of all ECUs interacting with CAN messages.
  • Domain controller ECU stores its own corresponding domain controller ECU key, as well as the keys of all ECUs interacting with CAN messages on the bus or other domains.
  • Intra-domain ECU Stores its own corresponding intra-domain ECU keys, as well as the keys of all ECUs interacting with CAN messages on all buses or other domains.
  • the execution subject of the flow may be an ECU or a vehicle-mounted device, etc., which is not limited.
  • an in-vehicle device is used as the execution subject for description.
  • the in-vehicle equipment in the process shown in FIG. 10 may be installed inside the terminal device 10 in FIG. 1, or the in-vehicle equipment in the process shown in FIG. 10 may include one or more ECUs in the architecture shown in FIG. It can be a network element ECU, a domain controller ECU, or an intra-domain ECU in FIG. 2 without limitation. It is understandable that the functions of the on-board equipment can be realized by the on-board equipment, or through other devices to support the implementation of the on-board equipment.
  • the specific process is as follows:
  • the first in-vehicle device sends the first parameter to the second in-vehicle device
  • the first in-vehicle device is a gateway that manages the second in-vehicle device
  • the second in-vehicle device is a domain controller device.
  • the first parameter may also be referred to as: a random number, a specific function, or a pseudo-random number, etc.
  • a shared key between the first vehicle-mounted device and the second vehicle-mounted device may be used to encrypt and transmit the first parameter.
  • the second in-vehicle device sends the first parameter to the third in-vehicle device
  • the third in-vehicle device is an intra-domain device
  • the second in-vehicle device is used to manage the third in-vehicle device
  • the first parameter is used to update the secret of the third in-vehicle device key.
  • a shared key between the second in-vehicle device and the third in-vehicle device may be used to encrypt and transmit the first parameter.
  • the third in-vehicle device determines the first key according to the first parameter.
  • the first key may be generated based on the initial key/key before update of the second vehicle-mounted device, the third vehicle-mounted device identifier, and the first parameter, and the third vehicle-mounted device identifier may also be referred to as the third vehicle-mounted device ID.
  • the third in-vehicle device updates the key of the third in-vehicle device according to the first parameter.
  • the third vehicle-mounted device In addition to storing its own key, the third vehicle-mounted device also stores the keys of other vehicle-mounted devices with which it interacts with CAN messages. Optionally, the third in-vehicle device may also update its stored keys of other devices according to the first parameter. The update process is similar to the process of updating the third in-vehicle device's own key, and will not be repeated here.
  • the first parameter in FIG. 10 may also be used to update the key of the second vehicle-mounted device.
  • it may further include: the second in-vehicle device determines the second key according to the first parameter.
  • the second in-vehicle device updates the key of the second in-vehicle device according to the second key.
  • the second key may be generated according to the initial key/key before update of the second vehicle-mounted device, the identification of the second vehicle-mounted device, and the first parameter.
  • KDF initial key of the second vehicle-mounted device/key before update, the second vehicle-mounted device ID, the first parameter.
  • the second vehicle-mounted device can also update its stored keys of other vehicle-mounted devices according to the first parameter.
  • the first vehicle-mounted device ie, the gateway
  • the second vehicle-mounted device ie, the domain controller device
  • the third vehicle-mounted device ie, the In-domain devices
  • the execution subject of the flow may be an ECU or a vehicle-mounted device, etc., which is not limited.
  • an in-vehicle device is used as the execution subject for description.
  • the vehicle-mounted equipment in the process shown in FIG. 11 may be installed inside the terminal device 10 in FIG. 1, or the vehicle-mounted equipment in the process shown in FIG. 11 may include one or more ECUs in the architecture shown in FIG. It can be a network element ECU, a domain controller ECU, or an intra-domain ECU in FIG. 2 without limitation. It is understandable that the functions of the vehicle-mounted equipment can be realized by the vehicle-mounted equipment, or other devices support the realization of the vehicle-mounted equipment.
  • the specific process is as follows:
  • the first in-vehicle device determines a first key according to the identifier of the second in-vehicle device and the first parameter, where the first key is the key to be updated for the second in-vehicle device, and the first in-vehicle device is the management 2.
  • the second vehicle-mounted device is a domain controller device or an intra-domain device.
  • KDF total key, second vehicle-mounted device identification, first parameter
  • the identification can also be referred to as the second in-vehicle device ID
  • the first parameter can also be referred to as a random number, a specific function or a pseudo-random number, etc.
  • the first vehicle-mounted device may periodically or periodically generate the first parameter.
  • the first in-vehicle device sends the first key to the second in-vehicle device.
  • the first in-vehicle device may be a gateway
  • the second in-vehicle device may be a domain controller device
  • the first in-vehicle device may directly send the first key to the second in-vehicle device.
  • the first key is encrypted using a shared key between the first in-vehicle device and the second in-vehicle device.
  • the first in-vehicle device may be a gateway
  • the second in-vehicle device may be an intra-domain device
  • the first in-vehicle device may send the first key to the third in-vehicle device
  • the third in-vehicle device is the domain control that manages the second in-vehicle device
  • the first key is encrypted using the shared key between the first vehicle-mounted device and the third vehicle-mounted device.
  • the third in-vehicle device forwards the first key to the second in-vehicle device, and the first key is encrypted using the shared key between the second in-vehicle device and the third in-vehicle device.
  • the second in-vehicle device updates the key of the second in-vehicle device according to the first key.
  • the key update of the vehicle-mounted device can be implemented to ensure the communication security of the vehicle-mounted device.
  • the methods provided in the embodiments of the present application are introduced from the perspective of network equipment, terminal, and interaction between the network equipment and the terminal.
  • the network device and the terminal may include hardware structures and/or software modules, which are implemented in the form of hardware structures, software modules, or hardware structures plus software modules. Whether a certain function of 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.
  • an embodiment of the present application further provides an apparatus 1200, which includes a processing module 1201 and a transceiver module 1202.
  • the apparatus 1200 can be used to implement the functions of the vehicle-mounted equipment in the foregoing method, and the apparatus 1200 may be the vehicle-mounted equipment or a device in the vehicle-mounted equipment.
  • the device may be a chip system.
  • the chip system may be composed of chips, or may include chips and other discrete devices.
  • the apparatus 1200 is used to implement the function of the first vehicle-mounted device in the foregoing method.
  • the processing module 1201 is configured to determine the first key of the first in-vehicle device according to the identifier of the first in-vehicle device, and determine the second message according to the first key and the first message.
  • the transceiver module 1202 is used to send a second message to a second vehicle-mounted device.
  • the apparatus 1200 is used to implement the function of the second vehicle-mounted device in the foregoing method.
  • the transceiver module 1202 is used to receive the second message of the first vehicle-mounted device.
  • the processing module 1201 is configured to determine the first key of the first in-vehicle device according to the identifier of the first in-vehicle device, and determine the first message according to the first key and the second message.
  • the apparatus 1200 is used to implement the function of the first vehicle-mounted device.
  • the transceiver module 1202 is configured to receive the first parameter of the second vehicle-mounted device.
  • the processing module 1201 is configured to determine a first key according to the first parameter, and update the key of the first vehicle-mounted device according to the first key.
  • the apparatus 1200 is used to implement the function of the second in-vehicle device.
  • the transceiver module 1202 is configured to receive the first parameter sent by the third vehicle-mounted device, and send the first parameter to the first vehicle-mounted device.
  • the processing module 1201 is configured to process the first parameter, for example, the key of the second vehicle-mounted device can be updated according to the first parameter.
  • the apparatus 1200 is used to implement the function of the first vehicle-mounted device.
  • the processing module 1201 is configured to determine the first key according to the identifier of the second vehicle-mounted device and the first parameter.
  • the transceiver module 1202 is used to send the first key to the second vehicle-mounted device.
  • the apparatus 1200 is used to implement the function of the second in-vehicle device.
  • the transceiver module 1202 is configured to receive the first key sent by the first vehicle-mounted device.
  • the processing module 1201 is configured to update the key of the second vehicle-mounted device according to the first key.
  • the processing module 1201 and the transceiver module 1202 please refer to the record in the above method embodiment.
  • the division of modules in the embodiments of this application is illustrative, and it is only a logical function division. In actual implementation, there may be other division methods.
  • the functional modules in the various embodiments of this application can be integrated into one process. In the device, it can also exist alone physically, or two or more modules can be integrated into one module.
  • the above-mentioned integrated modules can be implemented in the form of hardware or software function modules.
  • an embodiment of the present application further provides an apparatus 1300.
  • the device 1300 may be used to implement the function of the first vehicle-mounted device in the foregoing method.
  • the device may be a vehicle-mounted device or a device in the vehicle-mounted device.
  • the apparatus 1300 includes at least one processor 1301, configured to implement the function of the first vehicle-mounted device in the foregoing method.
  • the processor 1301 may determine the first key according to the identifier of the first in-vehicle device, and determine the second message according to the first key and the first message.
  • the device 1300 also includes at least one memory 1302 for storing program instructions and/or data. The processor 1301 and the memory 1302 are coupled.
  • the coupling in the embodiments of the present application is an interval coupling or a communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the memory 1302 may also be located outside the apparatus 1300.
  • the processor 1301 may cooperate with the memory 1302 to operate.
  • the processor 1301 may execute program instructions stored in the memory 1302. At least one of the at least one memory may be included in the processor.
  • the apparatus 1300 may further include a communication interface 1303 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1300 can communicate with other devices.
  • the communication interface 1303 may be a transceiver, a circuit, a bus, a module, or another type of communication interface, and the other device may be a second vehicle-mounted device.
  • the processor 1301 uses the communication interface 1303 to send and receive data, which is used to implement the method in the embodiment shown in the flowchart of FIG. 4 above.
  • the communication interface 1303 may send a second message and the like to the second in-vehicle device.
  • the device is used to implement the function of the second vehicle-mounted device in the foregoing method.
  • the device may be a vehicle-mounted device or a device in the vehicle-mounted device.
  • the apparatus 1300 includes at least one processor 1301, configured to implement the function of the second vehicle-mounted device in the foregoing method.
  • the processor 1301 may determine the first key according to the identifier of the first in-vehicle device, and determine the first message according to the first key and the second message.
  • the device 1300 also includes at least one memory 1302 for storing program instructions and/or data. The processor 1301 and the memory 1302 are coupled.
  • the coupling in the embodiments of the present application is an interval coupling or a communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the memory 1302 may also be located outside the apparatus 1300.
  • the processor 1301 may cooperate with the memory 1302 to operate.
  • the processor 1301 may execute program instructions stored in the memory 1302.
  • At least one of the at least one memory 1302 may be included in the processor 1301.
  • the apparatus 1300 may further include a communication interface 1303 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1300 can communicate with other devices.
  • the communication interface 1303 may be a transceiver, a circuit, a bus, a module, or another type of communication interface, and the other device may be a first vehicle-mounted device.
  • the processor 1301 uses the communication interface 1303 to send and receive data, which is used to implement the method in the embodiment shown in the flowchart of FIG. 4 above.
  • the communication interface 1303 may receive the second message sent by the first in-vehicle device and the like.
  • the device is used to implement the function of the first vehicle-mounted device in the foregoing method.
  • the device may be a vehicle-mounted device or a device in the vehicle-mounted device.
  • the apparatus 1300 includes at least one processor 1301, configured to implement the function of the second vehicle-mounted device in the foregoing method.
  • the processor 1301 may determine the first key according to the first parameter, and update the key of the first vehicle-mounted device according to the first key.
  • the device 1300 also includes at least one memory 1302 for storing program instructions and/or data. The processor 1301 and the memory 1302 are coupled.
  • the coupling in the embodiments of the present application is an interval coupling or a communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the memory 1302 may also be located outside the apparatus 1300.
  • the processor 1301 may cooperate with the memory 1302 to operate.
  • the processor 1301 may execute program instructions stored in the memory 1302.
  • At least one of the at least one memory 1302 may be included in the processor 1301.
  • the apparatus 1300 may further include a communication interface 1303 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1300 can communicate with other devices.
  • the communication interface 1303 may be a transceiver, a circuit, a bus, a module, or another type of communication interface, and the other device may be a first vehicle-mounted device.
  • the processor 1301 uses the communication interface 1303 to send and receive data, which is used to implement the method in the embodiment shown in the flowchart of FIG. 4 above.
  • the communication interface 1303 may receive the first parameter and the like sent by the second in-vehicle device.
  • the device is used to implement the function of the second vehicle-mounted device in the foregoing method.
  • the device may be a vehicle-mounted device or a device in the vehicle-mounted device.
  • the apparatus 1300 includes at least one processor 1301, configured to implement the function of the second vehicle-mounted device in the foregoing method.
  • the processor 1301 may update the key of the second in-vehicle device and the like according to the first parameter.
  • the device 1300 also includes at least one memory 1302 for storing program instructions and/or data.
  • the processor 1301 and the memory 1302 are coupled.
  • the coupling in the embodiments of the present application is an interval coupling or a communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the memory 1302 may also be located outside the apparatus 1300.
  • the processor 1301 may cooperate with the memory 1302 to operate.
  • the processor 1301 may execute program instructions stored in the memory 1302.
  • At least one of the at least one memory 1302 may be included in the processor 1301.
  • the apparatus 1300 may further include a communication interface 1303 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1300 can communicate with other devices.
  • the communication interface 1303 may be a transceiver, a circuit, a bus, a module, or another type of communication interface, and the other device may be a first vehicle-mounted device.
  • the processor 1301 uses the communication interface 1303 to send and receive data, and is used to implement the method in the embodiment shown in the flow of FIG. 10 above.
  • the communication interface 1303 may receive the first parameter and the like sent by the third in-vehicle device.
  • the device is used to implement the function of the first vehicle-mounted device in the foregoing method.
  • the device may be a vehicle-mounted device or a device in the vehicle-mounted device.
  • the apparatus 1300 includes at least one processor 1301, configured to implement the function of the first vehicle-mounted device in the foregoing method.
  • the processor 1301 may determine the first key according to the identifier of the second in-vehicle device and the first parameter.
  • the device 1300 also includes at least one memory 1302 for storing program instructions and/or data. The processor 1301 and the memory 1302 are coupled.
  • the coupling in the embodiments of the present application is an interval coupling or a communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the memory 1302 may also be located outside the apparatus 1300.
  • the processor 1301 may cooperate with the memory 1302 to operate.
  • the processor 1301 may execute program instructions stored in the memory 1302.
  • At least one of the at least one memory 1302 may be included in the processor 1301.
  • the apparatus 1300 may further include a communication interface 1303 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1300 can communicate with other devices.
  • the communication interface 1303 may be a transceiver, a circuit, a bus, a module, or another type of communication interface, and the other device may be a first vehicle-mounted device.
  • the processor 1301 uses the communication interface 1303 to send and receive data, which is used to implement the method in the embodiment shown in the flowchart of FIG. 4 above.
  • the communication interface 1303 may send the first key and the like to the second in-vehicle device.
  • the device is used to implement the function of the second vehicle-mounted device in the foregoing method.
  • the device may be a vehicle-mounted device or a device in the vehicle-mounted device.
  • the apparatus 1300 includes at least one processor 1301, configured to implement the function of the second vehicle-mounted device in the foregoing method.
  • the processor 1301 may update the key of the second in-vehicle device and the like according to the first key.
  • the device 1300 also includes at least one memory 1302 for storing program instructions and/or data.
  • the processor 1301 and the memory 1302 are coupled.
  • the coupling in the embodiments of the present application is an interval coupling or a communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules.
  • the memory 1302 may also be located outside the apparatus 1300.
  • the processor 1301 may cooperate with the memory 1302 to operate.
  • the processor 1301 can execute program instructions stored in the memory 1302.
  • At least one of the at least one memory 1302 may be included in the processor 1301.
  • the apparatus 1300 may further include a communication interface 1303 for communicating with other devices through a transmission medium, so that the apparatus used in the apparatus 1300 can communicate with other devices.
  • the communication interface 1303 may be a transceiver, a circuit, a bus, a module, or another type of communication interface, and the other device may be a first vehicle-mounted device.
  • the processor 1301 uses the communication interface 1303 to send and receive data, which is used to implement the method in the embodiment shown in the flowchart of FIG. 4 above.
  • the communication interface 1303 may receive the first key and the like sent by the first vehicle-mounted device.
  • the embodiment of the present application does not limit the connection medium between the aforementioned communication interface 1303, the processor 1301, and the memory 1302.
  • the memory 1302, the processor 1301, and the communication interface 1303 are connected by a bus 1304 in FIG. 13.
  • the bus is represented by a thick line in FIG. 13, and the connection mode between other components is only for schematic illustration. , Is not limited.
  • the bus can be divided into an address bus, a data bus, a control bus, and so on. For ease of representation, only one thick line is used in FIG. 13, but it does not mean that there is only one bus or one type of bus.
  • the present application also provides a chip system, which includes a processor, and is configured to implement the function of the first vehicle-mounted device in the above method.
  • the chip system further includes a memory for storing program instructions and/or data.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • the present application also provides a chip system including a processor for implementing the function of the second vehicle-mounted device in the above method.
  • the chip system further includes a memory for storing program instructions and/or data.
  • the chip system can be composed of chips, and can also include chips and other discrete devices.
  • the present application also provides a system, which includes the first vehicle-mounted device and the second vehicle-mounted device described in the foregoing embodiment.
  • 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 device, a discrete gate or transistor logic device, or a discrete hardware component, which may implement or Perform 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 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.
  • 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 (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 to this.
  • the memory in the embodiments 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, 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

本申请提供一种通信、更新密钥的方法及装置，通信方法包括：第一车载设备根据第一车载设备的标识，确定第一车载设备的第一密钥；第一车载设备根据第一密钥和第一消息，确定第二消息；第一车载设备向第二车载设备发送第二消息。可见，在本申请实施例中，车载设备可利用密钥对发送的消息进行加密，保障车载设备间的通信安全。

Description

一种通信、更新密钥的方法及装置
相关申请的交叉引用
本申请要求在2019年08月30日提交中国专利局、申请号为201910819103.3、申请名称为“一种通信、更新密钥的方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及自动驾驶技术领域，尤其涉及一种通信、更新密钥的方法及装置。
背景技术
自动驾驶，又称为无人驾驶、电脑驾驶等，是一种通过计算机实现无人驾驶的技术。自动驾驶依靠人工智能、视觉计算、雷达、监控装置和全球定位系统协同合作，让计算机可以在没有任何人类主动的操作下，自动安全地操作机动车辆。
目前，在自动驾驶领域中，车辆终端内设置有车载设备，不同车载设备间经常有通信的需求。如何保障车载设备间的通信安全是当前的研究热点。
发明内容
本申请提供一种通信、更新密钥的方法及装置，用以保障车载设备间的通信安全。
第一方面，提供一种通信方法，该方法的执行主体可以是车载设备，也可以是应用于车载设备中的芯片。以车载设备为执行主体为例进行描述。第一车载设备根据第一车载设备的标识，确定所述第一车载设备的第一密钥；第一车载设备根据所述第一密钥和第一消息，确定第二消息；第一车载设备向第二车载设备发送所述第二消息。上述方式，可通过密钥对车载设备的消息进行加密，保障车载设备的通信安全。第一密钥是根据第一车载设备生成的，也即不同的车载设备对应于不同的密钥，相对于，不同类型的消息进行不同密钥的方式，可减少密钥的数量，便于对密钥管理。
在一种可能的设计中，所述第一车载设备为域内设备或域控制设备，第一车载设备根据第一车载设备的标识，确定所述第一车载设备的第一密钥，具体为：第一车载设备根据所述第一车载设备的标识和总密钥，确定所述第一密钥，所述总密钥为管理所述第一车载设备的网关所对应的密钥。
在一种可能的设计中，所述第一密钥满足以下条件：
所述第一密钥＝KDF(总密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法。
通过上述描述可以看出。每个车载设备的密钥是根据自己车载设备的标识生成的。相应的，车载设备采用自己分配的密钥进行通信。由于车载设备的数量远远小于CAN类型的数量。上述方式，可减小密钥的数量，便于对密钥管理。
在一种可能的设计中，所述第一车载设备为域内设备，所述第一车载设备根据第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：第一车载设备根据域控制设备 的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，所述域控制设备用于对所述第一车载设备进行管理，所述总密钥为管理所述域控制设备的网关所对应的密钥。
在一种可能的设计中，所述第一车载设备根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，包括：第一车载设备根据所述域控制设备的标识和所述总密钥，确定第二密钥；第一车载设备根据所述第二密钥和所述第一车载设备的标识，确定所述第一密钥。
在一种可能的设计中，所述第一密钥满足以下条件：所述第一密钥＝KDF(第二密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法；
所述第二密钥满足以下条件：所述第二密钥＝KDF(总密钥，域控制设备的标识)。
通过上述描述可以看出。每个车载设备的密钥是根据自己车载设备的标识生成的。相应的，车载设备采用自己分配的密钥进行通信。由于车载设备的数量远远小于CAN类型的数量。上述方式，可减小密钥的数量，便于对密钥管理。
第二方面，提供一种通信方法，该方法的执行主体可以是车载设备，也可以是应用于车载设备中的芯片。在以下描述中以车载设备为执行主体为例，进行描述。第二车载设备接收第一车载设备发送的第二消息；第二车载设备根据所述第一车载设备的标识，确定所述第一车载设备的第一密钥；第二车载设备根据所述第一密钥和第二消息，确定第一消息。上述方法，车载设备所接收的消息是经过加密的，保障不同车载设备间的通信安全。
在一种可能的设计中，所述第一车载设备为域控制设备或域内设备，所述第二车载设备根据所述第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：第二车载设备根据所述第一车载设备的标识和总密钥，确定所述第一密钥，所述总密钥为管理所述第一车载设备的网关所对应的密钥。
在一种可能的设计中，所述第一密钥满足以下条件：所述第一密钥＝KDF(总密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法。
通过上述描述可以看出。每个车载设备的密钥是根据自己车载设备的标识生成的。相应的，车载设备采用自己分配的密钥进行通信。由于车载设备的数量远远小于CAN类型的数量。上述方式，可减小密钥的数量，便于对密钥管理。
在一种可能的设计中，所述第一车载设备为域内设备，所述第二车载设备根据第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：第二车载设备根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，所述域控制设备用于对所述第一车载设备进行管理，所述总密钥为管理所述域控制设备的网关所对应的密钥。
在一种可能的设计中，所述第二车载设备根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，包括：第二车载设备根据所述域控制设备的标识和所述总密钥，确定第二密钥；第二车载设备根据所述第二密钥和所述第一车载设备的标识，确定所述第一密钥。
在一种可能的设计中，所述第一密钥满足以下条件：所述第一密钥＝KDF(第二密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法；
所述第二密钥满足以下条件：所述第二密钥＝KDF(总密钥，域控制设备的标识)。
通过上述描述可以看出。每个车载设备的密钥是根据自己车载设备的标识生成的。相应的，车载设备采用自己分配的密钥进行通信。由于车载设备的数量远远小于CAN类型的数量。上述方式，可减小密钥的数量，便于对密钥管理。
第三方面，提供一种更新密钥的方法，该方法的执行主体可以为车载设备，也可以为应用于车载设备中的芯片。在以下描述中以车载设备为执行主体为例进行说明。第一车载设备接收第二车载设备发送的第一参数；第一车载设备根据所述第一参数，确定第一密钥；第一车载设备根据所述第一密钥，更新所述第一车载设备的密钥。上述方式，可实现对车载设备密钥的实时更新，保证通信安全。
在一种可能的设计中，所述第一车载设备根据所述第一参数，确定第一密钥，包括：第一车载设备根据第二密钥、第一参数和所述第一车载设备的标识，确定所述第一密钥，所述第二密钥为所述第一车载设备的初始密钥，或者，所述第二密钥为所述第一车载设备的更新前密钥。
在一种可能的设计中，所述第一密钥满足以下条件：
所述第一密钥＝KDF(第二密钥，第一车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
第四方面，提供一种更新密钥的方法，该方法的执行主体可以为车载设备，也可以为应用于车载设备中的芯片。在以下描述中以车载设备为执行主体为例进行说明。第二车载设备接收第三车载设备发送的第一参数，所述第三车载设备为管理第二车载设备的网关，所述第二车载设备为管理第一车载设备的域控制器，；第二车载设备向所述第一车载设备发送第一参数，所述第一参数用于更新所述第一车载设备的密钥。上述方式，可实现对车载设备密钥的实时更新，保证通信安全。
在一种可能的设计中，所述第一参数还用于更新所述第二车载设备的密钥，所述方法还包括：第二车载设备根据所述第一参数，确定第三密钥；第二车载设备根据所述第三密钥，更新所述第二车载设备的密钥。
在一种可能的设计中，所述第二车载设备根据所述第一参数，确定第三密钥，包括：第二车载设备根据第四密钥、所述第二车载设备的标识和第一参数，确定所述第三密钥，所述第四密钥为所述第二车载设备的初始密钥，或者，所述第四密钥为所述第二车载设备的更新前密钥。
在一种可能的设计中，所述第三密钥满足以下条件：
所述第三密钥＝KDF(第四密钥，第二车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
第五方面，提供一种更新密钥的方法，该方法的执行主体为车载设备，也可以为应用于车载设备中的芯片。在以下描述中以车载设备为执行主体为例进行描述。第一车载设备根据第二车载设备的标识和第一参数，确定第一密钥，所述第一密钥为所述第二车载设备的待更新密钥，第一车载设备为管理所述第二车载设备的网关，所述第二车载设备为域控制设备或域内设备；第一车载设备向所述第二车载设备发送所述第一密钥。上述方式，可实现对车载设备密钥的更新，保障车载设备的通信安全。
在一种可能的设计中，所述第一车载设备根据所述第二车载设备的标识和第一参数，确定第一密钥，包括：第一车载设备根据所述第二车载设备的标识、总密钥和第一参数，确定第一密钥，所述总密钥为管理所述第一车载设备的网关所对应的密钥。
在一种可能的设计中，所述第一密钥满足以下条件：
所述第一密钥＝KDF(总密钥，第二车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
在一种可能的设计中，所述第二车载设备为域控制设备，第一车载设备向所述第二车载设备发送所述第一密钥，包括：第一车载设备直接向所述第二车载设备发送所述第一密钥。
在一种可能的设计中，所述第二车载设备为域内设备，第一车载设备向所述第二车载设备发送所述第一密钥，包括：第一车载设备向第三车载设备发送第一密钥，所述第三车载设备为管理所述第二车载设备的域控制器，以使得所述第三车载设备将所述第一密钥转发至所述第二车载设备。
第六方面，提供一种更新密钥的方法，该方法的执行主体为车载设备，也可以为应用于车载设备中的芯片。在以下描述中以车载设备为执行主体为例进行描述。第二车载设备接收第一车载设备发送的第一密钥，所述第一密钥是根据第二车载设备的标识和第一参数所确定的，所述第一车载设备为管理第二车载设备的网关，所述第二车载设备为域控制设备或域内设备；第二车载设备根据所述第一密钥，更新所述第二车载设备的密钥。上述方式，可实现对车载设备密钥的更新，保障车载设备的通信安全。
在一种可能的设计中，所述第一密钥是根据第二车载设备的标识和第一参数所确定的，具体为：所述第一密钥是根据所述第二车载设备的标识、总密钥和第一参数所确定的，所述总密钥为所述网关的密钥。
在一种可能的设计中，所述第一密钥满足以下条件：
所述第一密钥＝KDF(总密钥，第二车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
在一种可能的设计中，所述第二车载设备为域控制设备，所述第二车载设备接收第一车载设备发送的第一密钥，包括：第二车载设备直接接收所述第一车载设备发送的第一密钥。
在一种可能的设计中，所述第二车载设备为域内设备，所述第二车载设备接收第一车载设备发送的第一密钥，包括：第二车载设备接收第三车载设备发送的第一密钥，所述第三车载设备为管理所述第二车载设备的域控制设备，所述第一密钥为所述第一车载设备发送给所述第三车载设备的。
第七方面，提供一种通信装置，有益效果可参见第一方面的描述此处不再赘述。所述通信装置具有实现上述第一方面的方法实施例中行为的功能。所述功能可通过软件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一种可能的设计中，所述通信装置包括：处理模块，用于根据第一车载设备的标识，确定第一车载设备的第一密钥，以及根据第一密钥和第一消息，确定第二消息。收发模块，用于向第二车载设备发送第二消息。这些模块可以执行上述第一方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不再赘述。
第八方面，提供一种通信装置，有益效果可参见第二方面的描述此处不再赘述。所述通信装置具有实现上述第二方面的方法实施例中行为的功能。所述功能可通过软件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一种可能的设计中，所述通信装置包括：收发模块，用于接收第一车载设备发送的第二消息。处理模块，用于根据第一车载设备的标识，确定第一车载设备的第一密钥，根据第一密钥和第二消息，确定第一消息。这些模块可以执行上述第二方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不再赘述。
第九方面，提供一种通信装置，有益效果可参见第三方面的描述此处不再赘述。所述通信装置具有实现上述第三方面的方法实施例中行为的功能。所述功能可通过软件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一种可能的设计中，所述通信装置包括：收发模块，用于接收第二车载设备发送的第一参数。处理模块，用于根据第一参数，确定第一密钥，以及根据第一密钥，更新第一车载设备的密钥。这些模块可以执行上述第三方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不再赘述。
第十方面，提供一种通信装置，有益效果可参见第四方面的描述此处不再赘述。所述通信装置具有实现上述第四方面的方法实施例中行为的功能。所述功能可通过软件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一种可能的设计中，所述通信装置包括：收发模块，用于接收第三车载设备发送的第一参数，所述第三车载设备为管理第二车载设备的网关，第二车载设备为管理第一车载设备的控制器。收发模块，还用于向第一车载设备发送第一参数，第一参数用于更新第一车载设备的密钥。这些模块可以执行上述第四方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不再赘述。
第十一方面，提供一种通信装置，有益效果可参见第五方面的描述此处不再赘述。所述通信装置具有实现上述第五方面的方法实施例中行为的功能。所述功能可通过软件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一种可能的设计中，所述通信装置包括：处理模块，用于根据第二车载设备的标识和第一参数，确定第一密钥，所述第一密钥为所述第二车载设备的待更新密钥，第一车载设备为管理所述第二车载设备的网关，所述第二车载设备为域控制设备或域内设备；收发模块，用于向所述第二车载设备发送所述第一密钥。这些模块可以执行上述第五方面方法示例中的相应功能，具体参见方法示例中的详细描述，此处不再赘述。
第十二方面，提供一种通信装置，有益效果可参见第六方面的描述此处不再赘述。所述通信装置具有实现上述第六方面的方法实施例中行为的功能。所述功能可通过软件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。在一种可能的设计中，所述通信装置包括：收发模块，用于接收第一车载设备发送的第一密钥，所述第一密钥是根据第二车载设备的标识和第一参数所确定的，所述第一车载设备为管理第二车载设备的网关，所述第二车载设备为域控制设备或域内设备；处理模块，用于根据所述第一密钥，更新所述第二车载设备的密钥。这些模块可以执行上述第六方面示例中的相应功能，具体参见方法示例中的详细描述，此处不再赘述。
第十三方面，提供一种装置，该装置可以为上述方法实施例中的第一车载设备，或者为设置在第一车载设备中的芯片。该装置包括通信接口和处理器。可选的，还可包括存储器。其中，该存储器用于存储计算机程序或指令，处理器与存储器、通信接口耦合，当处理器执行所述计算机程序或指令时，使装置执行上述方法实施例中由第一车载设备执行的方法。
第十四方面，提供一种装置，该装置可以为上述方法实施例中的第二车载设备，或者为设置在第二车载设备中的芯片。该装置包括通信接口处理器。可选的，还可包括存储器。其中，该存储器用于存储计算机程序或指令，处理器与存储器、通信接口耦合，当处理器执行所述计算机程序或指令时，使装置执行上述方法实施例中由第二车载设备执行的方法。
第十五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码并运行时，使得上述各方面中由第一车载设备执行的方法被执行。
第十六方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码被运行时，使得上述各方面中由第二车载设备执行的方法被执行。
第十七方面，本申请提供了一种芯片系统，该芯片系统包括处理器，用于实现上述各方面的方法中第一车载设备的功能。在一种可能的设计中，所述芯片系统还包括存储器，用于保存程序指令和/或数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十八方面，本申请提供了一种芯片系统，该芯片系统包括处理器，用于实现上述各方面的方法中第二车载设备的功能。在一种可能的设计中，所述芯片系统还包括存储器，用于保存程序指令和/或数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
第十九方面，本申请提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序被运行时，实现上述各方面中由第一车载设备执行的方法。
第二十方面，本申请提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，当该计算机程序被运行时，实现上述各方面中由第二车载设备执行的方法。
附图说明
图1为本申请实施例可适用的一种网络架构；
图2为本申请实施例适用的一种E/E架构；
图3为本申请实施例提供的一种密钥生成方法；
图4为本申请实施例提供的通信方法的一流程图；
图5为本申请实施例提供的对第一消息保护的示意图；
图6为本申请实施例提供的另一种密钥生成方法；
图7为本申请实施例提供的对ECU预置密钥的一示意图；
图8为本申请实施例提供的一种密钥生成方法；
图9为本申请实施例提供的对ECU预置密钥的一示意图；
图10为本申请实施例提供的更新密钥的一流程图；
图11为本申请实施例提供的更新密钥的另一流程图；
图12为本申请实施例提供的通信装置的一示意图；
图13为本申请实施例提供的通信装置的另一示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行介绍。
如图1所示，为本申请实施例适用的一种网络架构，包括：终端设备10和接入网设备20。
其中，终端设备10的数量为两个或两个以上，且不同终端设备之间可通过旁链路 (sidelink，SL)传输旁链路信息。所述旁链路信息可包括数据(data)和/或调度分配(scheduling assigment，SA)。可选的，旁链路信息还可包括旁链路反馈，所述旁链路反馈可以包括信道状态信息(channel state information，CSI)，混合自动重传请求(hybrid automatic repeat request，HARQ)等中的至少一种信息。所述HARQ可以包括肯定确认(acknowledgement，ACK)或否定确认(negtive acknowledgement，NACK)。可以理解的是，上述数据也可称为数据信息、调度分配也可称为调度分配信息、旁链路反馈也可称为旁链路反馈信息等，不作限定。
需要说明的是，旁链路传输可应用于车联网(vehicle to X，V2X)场景，X可以指任意的对象。比如，车联网通信可包括车与车(vehicle to vehicle,V2V)、车与路侧基础设施(vehicle to infrastructure,V2I)、车与行人(vehicle to pedestrian，V2P)以及车与应用服务器(vehicle to network，V2N)等。所述车联网还可称为协作智能交通系统(cooperative-intelligent transport system,C-ITS)。或者，旁链路传输可应用于设备到设备(device to device，D2D)通信中，D2D可以是指借助无线网络、蓝牙或D2D传输等技术实现终端设备间的直接通信等，不作限定。
进一步的，终端设备10与接入网设备20之间可通过Uu空口进行通信。Uu空口可以理解为通用的UE和网络之间的接口(universal UE to network interface)。Uu空口的传输包括下行传输和上行传输。下行传输指接入网设备20向终端设备10发送信息，下行传输的信息可以称为下行信息或下行信号。其中，下行信息或下行信号中可包括下行数据信号、下行控制信号、信道状态信息参考信号(channel state information reference signal，CSI-RS)，相位跟踪参考信号(phase tracking reference signal，PTRS)中的一个或多个。用于传输下行信息或下行信号的信道称为下行信道，下行信道可以包括物理下行数据信道(physical downlink shared channel，PDSCH)和物理下行控制信道(physical downlink control channel，PDCCH)中的一个或多个。所述PDCCH用于承载下行控制信息(downlink control information，DCI)，PDSCH用于承载下行数据(data)，下行数据也可称为下行数据信息。上行传输指终端设备10向接入网设备20发送信息，上行传输的信息可以称为上行信息或上行信号。其中，上行信息或上行信号中可包括上行数据信号、上行数据信息、探测参考信号(sounding reference signal，SRS)等中的一个或多个。用于传输上行信息或上行信号的信道称为上行信道，上行信道可以包括物理上行数据信道(physical uplink shared channel，PUSCH)和物理上行控制信道(physical uplink control channel，PUCCH)中至少一种信道。PUSCH用于承载上行数据。其中，上行数据也可以称为上行数据信息。PUCCH用于承载终端设备反馈的上行控制信息(uplink control information，UCI)，比如UCI中可以包括终端设备反馈的信道状态信息(channel state information，CSI)、ACK和/或NACK等。
可选的，在图1所示的架构中，还可包括服务器30。例如，所述服务器30可为核心网设备。其中，终端设备10可通过无线的方式与接入网设备20相连，接入网设备20可通过有线或无线的方式与服务器30相连。服务器30与接入网设备20可以是独立的物理设备。或者，服务器30与接入网设备20可以是相同的物理设备，该物理设备上集成有服务器30与接入网设备20的全部/部分逻辑功能。
在图1所示的架构中，终端设备10可以简称为终端，是一种具有无线收发功能的设备，终端设备可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。所述终端设备可以是手机 (mobile phone)、平板电脑(pad)、带无线收发功能的电脑、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、工业控制(industrial control)中的无线终端设备、无人驾驶(self driving)中的无线终端设备、远程医疗(remote medical)中的无线终端设备、智能电网(smart grid)中的无线终端设备、运输安全(transportation safety)中的无线终端设备、智慧城市(smart city)中的无线终端设备、智慧家庭(smart home)中的无线终端设备，以及还可以包括用户设备(user equipment，UE)等。终端设备还可以是蜂窝电话、无绳电话、会话启动协议(session initiation protocol，SIP)电话、无线本地环路(wireless local loop，WLL)站、个人数字助理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，未来第五代(the 5th generation，5G)网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network，PLMN)中的终端设备等。终端设备有时也可以称为终端设备、用户设备(user equipment，UE)、接入终端设备、车载终端设备、工业控制终端设备、UE单元、UE站、移动站、移动台、远方站、远程终端设备、移动设备、UE终端设备、终端设备、无线通信设备、UE代理或UE装置等。终端设备也可以是固定的或者移动的。本申请实施例对此并不限定。
在图1所示的架构中，接入网设备20，是一种为终端设备提供无线通信功能的设备。接入网设备例如包括但不限于：5G中的下一代基站(generation nodeB，gNB)、演进型节点B(evolved node B，eNB)、无线网络控制器(radio network controller，RNC)、节点B(node B，NB)、基站控制器(base station controller，BSC)、基站收发台(base transceiver station，BTS)、家庭基站(例如，home evolved nodeB，或home node B，HNB)、基带单元(baseband unit，BBU)、收发点(transmitting and receiving point，TRP)、发射点(transmitting point，TP)、移动交换中心等。接入网设备还可以是云无线接入网络(cloud radio access network，CRAN)场景下的无线控制器、集中单元(centralized unit，CU)，和/或分布单元(distributed unit,DU)，或者网络设备可以为中继站、接入点、车载设备、终端设备、可穿戴设备以及未来5G网络中的网络设备或者未来演进的PLMN网络中的网络设备等。终端设备可以与不同技术的多个接入网设备进行通信，例如，终端设备可以与支持长期演进(long term evolution，LTE)的接入网设备通信，也可以与支持5G的接入网设备通信，还可以与支持LTE的接入网设备以及支持5G的接入网设备的双连接。本申请实施例并不限定。
需要说明的是，在图1所示的网络架构中，终端设备10可以是固定位置的，也可以是移动的，不作限定。图1所示的网络架构中，还可包括其它网络设备，比如无线中继设备和无线回传设备等，不作限定。图1所示的架构中，对终端设备、接入网设备和服务器的数量不作限定。
在本申请实施例中，如图2所示，针对图1中的终端设备10，可采用电子电气(electrical/electronic，E/E)架构，该架构包括三个层级，分别为网关电子控制单元(electronic control unit，ECU)、域控制器ECU和域内ECU。其中，根据功能不同，可划分为不同的域，每个域有一个域控制器ECU。所述域控制器ECU用于管理对应域内的域内ECU。网关ECU用于对域控制器ECU进行管理。例如，参照图1所示，根据功能不同，可划分4个域，分别为整车控制系统域、娱乐系统域、诊断系统域以及智能驾驶系统域。每个域对应于一个域控制器ECU。上述4个域，总共对应于4个域控制器ECU。网关ECU用于对 所述4个域控制器ECU进行管理。
其中，在图1所示的架构中，ECU之间可基于控制区域网络(controller area network，CAN)协议进行通信，不同ECU之间可发送CAN消息。为了保护CAN消息的完整性以及防重放攻击，可利用密钥对CAN消息进行保护。不同类型的CAN消息对应于不同的密钥。在整个E/E架构中，CAN消息的类型较多，相应的密钥的数量也较多，管理困难。
可以理解的是，图2所示架构，仅为示意性说明，并不作为对本申请实施例的限定。比如，本申请实施例所提供的方法，除可利用于上述图2所示的三层架构外，还可利用于其它两层或一层架构中等，不作限定。
如图3所示，提供一种密钥生成方法，利用该方法可为不同类型的CAN消息生成密钥。具体的过程如下：首先一个E/E架构中有一个总密钥，总密钥还可称为根密钥。利用总密钥，可生成CAN总线密钥。利用CAN总线密钥，可生成不同类型的CAN消息密钥。由于CAN的类型可利用CAN ID表示，为了便于描述，在以下示例中，用CAN ID表示CAN消息的类型。
例如，在本申请实施例中，仍可参照图2，整个E/E架构中，包括4个CAN总线，分别为CAN总线1、CAN总线2、CAN总线3以及CAN总线4。可选的，图2中的4个CAN总线可与图1中的4个域存在对应关系。比如，图2中的CAN总线1可对应于整车控制系统域，CAN总线2可对应于娱乐系统域，CAN总线3可对应于诊断系统域，CAN总线4可对应于智能驾驶系统域等。
其中，利用总密钥，可生成CAN总线密钥。具体的，可满足以下算法：CAN总线ID密钥＝KDF(总密钥，CAN总线ID)，KDF表示密钥衍生算法，KDF还可称为密钥推导函数(key derivation function)。例如，CAN总线1的密钥＝KDF(总密钥，CAN总线1)。进一步的，在不同的CAN总线下可包括相同或不同类型的CAN消息。例如，参照图3所示，在CAN总线1下可包括四种类型的CAN消息。四种类型的CAN消息的ID分别为A、B、C、D。在本示例中，可利用CAN总线密钥，生成该总线下不同类型CAN消息的密钥。具体的，可满足以下算法：CAN ID密钥＝KDF(CAN总线密钥，CAN ID)。比如，仍沿用上述举例，CAN总线1下包括A、B、C、D四种类型的CAN消息。CAN A密钥可满足以下算法：CAN A密钥＝KDF(CAN总线1，CAN A)。
通过上述记载可以看出，在上述示例中，不同类型的CAN消息，对应于不同的密钥。而E/E架构中，存在大量的CAN消息，相应的，也就存在大量的密钥，较难管理。
基于上述，提供一种通信方法，该方法的原理为：为不同的ECU，分配不同的密钥。由于在E/E架构中，ECU的数量远远小于CAN消息的数量。采用本申请的方法，可减少E/E架构中密钥的数量，便于管理。
下面对本申请实施例中所使用到的一些通信名词或术语进行解释说明，该通信名词或术语也作为发明内容的一部分。
一、电子控制单元(electronic control unit，ECU)
ECU，还可称为“行车电脑”，“车载电脑”，“汽车专用微机控制器等”，是现代车辆电子的核心元件之一。ECU可由微处理器、存储器、输入/输出接口、模数转换器、整形以及驱动等大规模集成电路组成。在本申请实施例中，车载设备内可包括一个或多个ECU， ECU与车载设备间不作相互区分。
二、网关(gateway)
网关是车辆架构中的核心部分，其作为整车网络的数据交互枢纽，可将CAN、LIN、MOST、FlexRay等网络数据在不同网络中进行路由。网关可对域控制设备和域内设备等进行管理。在本申请实施例中，网关内可包括网关ECU，网关与网关ECU不作相互区分。
三、域控制设备
根据车辆电子各部分的功能不同，可将车辆电子划分为几个域。比如，动力传动域、车身电子域以及辅助驾驶域等。每个域内设有一个域控制设备，用于对该域内的域内设备进行管理。域控制设备也可称为域控制器。在本申请实施例中，域控制设备内包括域控制ECU，域控制设备与域控制设备ECU不作相互区分。
四、域内设备
根据车辆电子各部分的功能不同，可将车辆电子划分为几个域。比如，动力传动域、车身电子域以及辅助驾驶域等。每个域内可包括一个域控制器和多个被控制设备，所述域内设备可具体指每个域内的被控制设备等。在本申请实施例中，域内设备中可包括域内ECU，域内设备与域内ECU不作相互区分。
需要说明的是，本申请实施例中的“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。比如，“第一消息”和“第二消息”等。“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，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可以是单个，也可以是多个。
如图4所示，提供一种通信方法的流程，该流程的执行主体可为ECU或车载设备等，不作限定。在本申请实施例中，以车载设备为执行主体进行说明。图4所示流程中的车载设备可具体位为图1中终端设备10的内部，或者，图4所示流程中的车载设备可包括图2所示架构中一个或多个ECU，所述ECU可为图2中的网关ECU、域控制器ECU或域内ECU等，不作限定。可以理解的是，车载设备的功能可以通过车载设备来实现，或者通过其它装置支持车载设备实现。该流程具体为：
S401.第一车载设备根据第一车载设备的标识，确定第一车载设备的第一密钥。
一示例中，第一车载设备可为域控制设备或域内设备，第一车载设备可根据第一车载设备的标识和总密钥，确定第一密钥。例如，第一密钥可满足以下条件：第一密钥＝KDF(总密钥，第一车载设备的标识)，KDF表示密钥衍生算法，总密钥为网关所对应的密钥，网关可对第一车载设备进行管理。可选的，第一车载设备的标识还可称为第一车载设备的ID，KDF还可称为密钥推导函数(key derivation function)。
一示例中，第一车载设备可为域控制设备，第一车载设备的第一密钥可根据第一车载设备的标识和总密钥确定，过程可参见上述记载，在此不再说明。第一车载设备可为域内设备，第一车载设备的第一密钥的确定过程可为：确定管理第一车载设备的域控制器；根据域控制器的标识、总密钥和第一车载设备的标识，确定第一密钥。示例的，第一车载设 备可首先根据域控制设备的标识和总密钥，确定第二密钥。根据第二密钥和第一车载设备的标识，确定第一密钥。例如，第一密钥可满足以下条件：所述第一密钥＝KDF(第二密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法。第二密钥可满足以下条件：所述第二密钥＝KDF(总密钥，域控制设备的标识)。
S402.第一车载设备根据第一密钥和第一消息，确定第二消息。
示例的，第一车载设备可根据第一密钥，生成消息认证码(message authentication code，MAC)；第一车载设备确定新鲜值(freshness value)。第一车载设备根据第一消息、MAC和新鲜值，确定第二消息。上述第一消息的有效负荷可由实际报文组成，第二消息的有效负荷可由实际的报文、MAC和新鲜值组成。可选的，为了缩短新鲜值、MAC所占用第二消息的长度，可将新鲜值和认证码截断。第二消息的有效负荷可由实际的报文、截断的MAC和截断的新鲜值组成。一种示例中，如图5所示，可在新鲜值的最低位(least significant bit，LSB)开始截断(或称为配置)，可在MAC的最高位(most significant bit，MSB)开始截断(或配置)。
S403.第一车载设备向第二车载设备发送第二消息。
可选的，上述图4所示的流程，还可包括：S404.第二车载设备根据第一车载设备的标识，确定第一车载设备的第一密钥。
一示例中，第二车载设备中存储有密钥与车载设备的对应关系。第二车载设备在接收到第二消息后，可确定第一车载设备的标识。根据第一车载设备的标识，在密钥与车载设备的对应关系中，确定第一车载设备的标识所对应的第一密钥。另一示例中，第二车载设备在接收到第二消息后，可确定第一车载设备的标识。第二车载设备可根据第一车载设备的标识，确定第一密钥。第二车载设备根据第一车载设备的标识，确定第一密钥的过程，与第一车载设备根据第一车载设备的标识，确定第一密钥的过程相似，在此不再赘述。
S405.第二车载设备根据第一密钥和第二消息，确定第一消息。
在本申请实施例中，第二消息的有效负荷可由实际的报文、MAC和新鲜值组成。第二车载设备在接收到第二消息后，第二车载设备可比较第二消息中的新鲜值与本地保存的新鲜值。若第二消息中的新鲜值比本地保存的新鲜值高，则认为第二消息未被篡改。原理为：第一车载设备在发送第一消息时，可按照时序为不同的消息分配新鲜值。比如，按照时序，第一车载设备发送的第一消息，分别为消息A、消息B和消息C。第一车载设备可为消息A，分配新鲜值00，为消息B，分配新鲜值01，为消息C，分配新鲜值10。那么，第二车载设备接收到消息A时，可保存消息A的新鲜值00。在接收到消息B时，可首先验证消息B的新鲜值01是否比保存的新鲜值00高。如果高，证明当前接收的消息B是新鲜的。否则，认为当前接收的消息B是不新鲜的，有人非法的将已经传输过的消息(例如消息A)重新发送了一遍，上述过程即重放攻击的过程。可见，通过在第二消息中添加新鲜值，可防止重放攻击。
在本申请实施例中，第二车载设备在接收到第二消息后，还可根据上述S404中的记载，确定第一密钥。第二车载设备根据第一密钥，计算MAC。第二车载设备比较第二消息中的MAC与上述S404中根据第一密钥计算出的MAC。如果比较成功的话，第二车载设备认为第二消息是可靠性的，即第二消息是没有被篡改过的。
需要说明的是，在上述图4所示的流程中，第一车载设备与第二车载设备之间可通过CAN协议进行通信。上述图4流程中的第一消息还可称为第一CAN消息，第二消息还可 称为第二CAN消息。上述S402中的“根据第一密钥和第一消息，确定第二消息”的过程，还可称为：根据第一密钥，对第一消息进行保护，所述保护可具体为完整性保护和防重放攻击。关于如何进行完整性保护和防重放攻击，可参见S402和S405中的记载，在此不再说明。
由上可见，在本申请实施例中，为每个车载设备分配不同的密钥，每个车载设备的密钥是根据自己的车载设备标识所生成的。相应的，车载设备采用自己分配的密钥进行通信。由于车载设备的数量远远小于CAN类型的数量。本申请实施例的方法，相对于为不同类型的CAN消息分配不同密钥的方式相比，可减少密钥的数量，便于对密钥管理。
示例一
在本示例中，提供一种密钥生成方法，利用该方法可为上述图4所示流程中的第一车载设备分配密钥。具体的过程可为：根据第一车载设备的标识和总密钥，生成第一车载设备的第一密钥。比如，第一车载设备的第一密钥可满足以下条件：
第一密钥＝KDF(总密钥，第一车载设备的标识)，KDF表示密钥衍生算法。在本申请实施例中，上述图4所示流程中的第一车载设备和第二车载设备可归属于图1所示流程中的终端10，即终端设备10可包括第一车载设备和第二车载设备。终端设备10在出厂时，可预设总密钥，利用该总密钥，可衍生出车载设备的其它密钥。或者，当在终端设备10采用E/E架构时(例如，图2为一种典型的E/E架构)，一个E/E架构对应于一个总密钥，该总密钥可预设到网关ECU中。可选的，总密钥还可称为根密钥，KDF还可称为密钥推导函数(key derivation function)，第一车载设备的标识还可称为第一车载设备ID等。
由于在典型的情况下，一个车载设备内包括一个ECU，因此车载设备和ECU间可相互替换。为了便于描述，以下示例中，以ECU为例，进行相关的描述。
例如，在本申请实施例中，以“终端设备内包括5个ECU，分别为网关ECU、第一ECU、第二EUC、第三ECU和第四ECU，网关ECU对应于总密钥，第一ECU对应于第一密钥，第二ECU对应于第二密钥，第三ECU对应于第三密钥，第四ECU对应于第四密钥”为例，详细说明本申请的过程。在本申请实施例中，如图6所示，利用总密钥和ECU的ID，可衍生出第一密钥、第二密钥、第三密钥和第四密钥。比如，第一密钥＝KDF(总密钥，第一ECU ID)，第二密钥＝KDF(总密钥，第二ECU ID)，第三密钥＝KDF(总密钥，第三ECU IDF)，第四密钥＝KDF(总密钥，第四ECU)等。第一ECU、第二ECU、第三ECU和第四ECU可为上述图2所示的典型E/E架构中的，域控制ECU或域内ECU等，不作限定。
示例的，在本申请实施例中，如图7所示，利用本示例的方法，可计算E/E架构中域控制ECU的密钥和域内ECU的密钥。其中，域控制器ECU的密钥与域内ECU的密钥的计算方式相同，区别仅为两者所取的ECU ID不同。比如，域控制器ECU的密钥＝KDF(总密钥，域控制器ECU ID)；域内ECU密钥＝KDF(总密钥，域内ECU ID)。或者，上述过程可以描述为：根据总密钥以及ECU ID，计算E/E架构中每个ECU的密钥。其中，每个ECU的密钥可满足以下条件：ECU密钥＝KDF(总密钥，ECU ID)，所述ECU中包括域控制器ECU和域内ECU等。在获得E/E架构中，每个ECU的密钥后，按照以下方式预置密钥：
网关ECU：存一把总密钥，以及存有所有与其有CAN消息交互的ECU的密钥。比如， 网关ECU与图7所示的四个域控制器ECU有CAN消息交互，则所述网关ECU中还可存有上述四个域控制器的密钥。
域控制器ECU：存储有自己的密钥，以及所在总线或其它域上与其有CAN消息交互的ECU的密钥。
域内ECU：存储有自己的密钥，以及所有总线或其它域上与其有CAN消息交互的ECU的密钥。
可以理解的是，在图7中，是以E/E架构中，除网关ECU外，包括N个ECU，所述N个ECU中包括域控制器ECU和域内ECU。根据N个ECU中每个ECU的ID，相应的，生成N个密钥为例进行说明的，并不作为对本申请的限定。
通过上述记载可以看出，在本示例中，是为每个ECU分配一密钥。由于一条CAN总线上，ECU数量较少，和基于CAN ID分配密钥的方式相比。采用本示例的方法，管理密钥的数量将大幅降低。
示例二
在本示例中，提供一种密钥生成方法，利用该方法可为上述图4所示流程中的第一车载设备分配密钥，第一车载设备可为域控制器设备或域内设备。具体的，当第一车载设备为域控制器时，第一车载设备的第一密钥的生成过程可为：根据总密钥和第一车载设备的标识，确定第一车载设备的密钥。当第一车载设备为域内设备时，第一车载设备的第一密钥的生成过程可为：确定第一车载设备所归属的域控制器设备，所述域控制器设备用于对第一车载设备进行管理。根据域控制器的标识和总密钥，生成第二密钥。比如，第二密钥可满足以下条件：第二密钥＝KDF(总密钥，域控制器标识)，域控制器标识还可称为域控制器ID。根据第二密钥和第一车载设备标识，生成第一车载设备的第一密钥。比如，第一车载设备的第一密钥满足以下条件：第一密钥＝KDF(第二密钥，第一车载设备标识)，第一车载设备标识还可称为第一车载设备ID等。
由于在典型的情况下，一个车载设备内包括一个ECU，因此车载设备和ECU间可相互替换。为了便于描述，在以下示例中，以ECU为例，进行相关的描述。
例如，在本申请实施例中，以“终端设备内包括一个网关ECU、两个域控制器EUC以及4个域内EUC为例”，详细说明本申请的过程。上述两个域控制器ECU，分别为第一域控制器ECU和第二域控制器ECU。4个域内ECU分别为第一域内ECU、第二域内ECU、第三域内ECU以及第四域内ECU。如图8所示，网关ECU的密钥为总密钥，第一域控制器ECU的密钥为第一域控制器密钥，第二域控制器ECU的密钥为第二域控制器密钥，第一域内ECU的密钥为第一域内密钥，第二域内ECU的密钥为第二域内密钥，第三域内ECU的密钥为第三域内密钥，第四域内ECU的密钥为第四域内密钥。
在本申请实施例中，可首先根据总密钥，生成第一域控制器密钥和第二域控制器密钥。比如，第一域控制器密钥满足以下条件：第一域控制器密钥＝KDF(总密钥，第一域控制器标识)，第一域控制器标识还可称为第一域控制器ID。第二域控制器密钥满足以下条件：第二域控制器密钥＝KDF(总密钥，第二域控制器标识)，第二域控制器标识还可称为第二域控制器ID。或者，上述过程，还可描述为：域控制器ECU密钥＝KDF(总密钥，域控制器ID)。
根据第一域控制器密钥和域内设备标识，生成第一域内密钥和第二域内密钥。比如， 第一域内密钥满足：第一域内密钥＝KDF(第一域控制器密钥，第一域内设备标识)，第一域内设备标识还可称为第一域内设备ID。第二域内密钥满足：第二域内密钥＝KDF(第一域控制器密钥，第二域内设备标识)，第二域内设备标识还可称为第二域内设备ID。根据第二域控制器密钥和域内设备标识，生成第三域内密钥和第四域内密钥，上述过程与生成第一域内密钥和第二域内密钥的过程相似，不再赘述。或者，上述过程，还可描述为：域内ECU密钥＝KDF(域控制器ECU密钥，域内ECU ID)。
最后，将生成的密钥，预置于各ECU中。如图9所示，具体的预置过程如下：
网关ECU：存储有总密钥，以及有CAN消息交互的所有ECU的密钥。
域控制器ECU：存储有自己对应的域控制器ECU密钥，以及所在总线或其他域上有CAN消息交互的所有ECU的密钥。
域内ECU：存储有自己对应的域内ECU密钥，以及所有总线或其它域上有CAN消息交互的所有ECU的密钥。
需要说明的是，在图9中的“密钥生成架构图”中，是以“存在两个域控制器，每个域控制器存在两个域内设备”为例进行说明的，并不作为对本申请的限定。实际上“密钥生成架构图中的域控制器ECU以及域内ECU”的数量，是与“E/E架构中，域控制器ECU和域内ECU”的数量相匹配的。
通过以上记载可以看出，在本示例中，是为每个ECU分配一密钥。由于一条CAN总线上，ECU数量较少，和基于CAN ID分配密钥的方式相比。采用本示例的方法，管理密钥的数量将大幅降低。
如图10所示，提供一种通信方法的流程，该流程的执行主体可为ECU或车载设备等，不作限定。在本申请实施例中，以车载设备为执行主体进行说明。图10所示流程中的车载设备可设置于图1中终端设备10的内部，或者，图10所示流程中的车载设备可包括图2所示架构中的一个或多个ECU，所述ECU可为图2中的网元ECU、域控制器ECU或域内ECU等，不作限定。可以理解的是，车载设备的功能可以通过车载设备来实现，或者通过其它装置支持车载设备实现，该流程具体为：
S1001.第一车载设备向第二车载设备发送第一参数，第一车载设备为管理第二车载设备的网关，第二车载设备为域控制器设备。可选的，第一参数还可称为：随机数、特定函数、或伪随机数等。可选的，在S1001可采用第一车载设备间与第二车载设备间的共享密钥对第一参数进行加密传输。
S1002.第二车载设备向第三车载设备发送第一参数，第三车载设备为域内设备，第二车载设备用于对第三车载设备进行管理，第一参数用于更新第三车载设备的密钥。可选的，在S1002中可采用第二车载设备与第三车载设备间的共享密钥对第一参数进行加密传输。
S1003.第三车载设备根据第一参数，确定第一密钥。
示例的，第一密钥可根据第二车载设备的初始密钥/更新前密钥、第三车载设备标识以及第一参数生成的，第三车载设备标识还可称为第三车载设备ID。比如，第一密钥可满足以下条件：第一密钥＝KDF(第三车载设备的初始密钥/更新前密钥，第三车载设备ID，第一参数)。
S1004.第三车载设备根据第一参数，更新第三车载设备的密钥。
由于第三车载设备除存储有自己的密钥外，还存储有与其有CAN消息交互的其它车 载设备的密钥。可选的，第三车载设备还可根据第一参数，更新其存储的其它设备的密钥，更新过程，与更新第三车载设备自己密钥的过程相似，在此不再赘述。
可选的，上述图10中的第一参数还可用于更新第二车载设备的密钥。上述图10所示的流程中，还可包括：第二车载设备根据第一参数，确定第二密钥。第二车载设备根据第二密钥，更新第二车载设备的密钥。示例的，第二密钥可根据第二车载设备的初始密钥/更新前密钥、第二车载设备的标识和第一参数生成的。比如，第二密钥可满足以下条件：第二密钥＝KDF(第二车载设备的初始密钥/更新前密钥，第二车载设备ID，第一参数)。同理，第二车载设备除更新自己的密钥外，还可根据第一参数，更新其存储的其它车载设备的密钥。
在本申请实施例中，第一车载设备(即网关)，可周期性或定期产生第一参数，且发送第一参数给第二车载设备(即域控制器设备)和第三车载设备(即域内设备)，用于更新第二车载设备和第三车载设备的密钥，从而实现对车载设备密钥的实时更新，保证通信安全。
如图11所示，提供一种通信方法的流程，该流程的执行主体可为ECU或车载设备等，不作限定。在本申请实施例中，以车载设备为执行主体进行说明。图11所示流程中的车载设备可设置于图1中终端设备10的内部，或者，图11所示流程中的车载设备可包括图2所示架构中的一个或多个ECU，所述ECU可为图2中的网元ECU、域控制器ECU或域内ECU等，不作限定。可以理解的是，车载设备的功能可以通过车载设备来实现，或者其它装置支持车载设备实现，该流程具体为：
S1101.第一车载设备根据第二车载设备的标识和第一参数，确定第一密钥，所述第一密钥为第二车载设备的待更新密钥，所述第一车载设备为管理第二车载设备的网关，第二车载设备为域控制器设备或域内设备。
示例的，第一密钥可满足以下条件：第一密钥＝KDF(总密钥，第二车载设备标识，第一参数)，总密钥为第一车载设备的密钥，第二车载设备标识还可称为第二车载设备ID，第一参数还可称为随机数，特定函数或伪随机数等。可选的，第一车载设备可周期性或定期产生第一参数。
S1102.第一车载设备向第二车载设备发送第一密钥。
示例的，第一车载设备可为网关，第二车载设备可为域控制器设备，第一车载设备可直接将第一密钥发送至第二车载设备。可选的，第一密钥采用第一车载设备和第二车载设备间的其享密钥进行加密。示例的，第一车载设备可为网关，第二车载设备可为域内设备，第一车载设备可将第一密钥发送至第三车载设备，第三车载设备为管理第二车载设备的域控制器，第一密钥采用第一车载设备和第三车载设备间的共享密钥进行加密。第三车载设备将第一密钥转发给第二车载设备，第一密钥采用第二车载设备和第三车载设备间的共享密钥进行加密。
S1103.第二车载设备根据第一密钥，更新第二车载设备的密钥。
由上可见，在本申请实施例中，可实现对车载设备的密钥更新，保障车载设备的通信安全。
上述本申请提供的实施例中，分别从网络设备、终端、以及网络设备和终端之间交互的角度对本申请实施例提供的方法进行了介绍。为了实现上述本申请实施例提供的方法中 的各功能，网络设备和终端可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。
与上述构思相同，如图12所示，本申请实施例还提供一种装置1200，该装置1200包括处理模块1201和收发模块1202。其中，装置1200可用实现上述方法中车载设备的功能，装置1200可以是车载设备，也可以是车载设备中的装置。其中，该装置可以为芯片系统。在本申请实施例中，芯片系统可以由芯片构成，也可以包括芯片和其他分立器件。
示例的，装置1200用于实现上述方法中第一车载设备的功能。处理模块1201，用于根据第一车载设备的标识，确定第一车载设备的第一密钥，以及根据第一密钥和第一消息，确定第二消息。收发模块1202，用于向第二车载设备发送第二消息。
示例的，装置1200用于实现上述方法中第二车载设备的功能。收发模块1202，用于接收第一车载设备的第二消息。处理模块1201，用于根据第一车载设备的标识，确定第一车载设备的第一密钥，以及，根据第一密钥和第二消息，确定第一消息。
在上述示例中，关于处理模块1201和收发模块1202的具体功能，可参见上述方法实施例中图4流程中的记载，在此不再说明。
示例的，装置1200用于实现第一车载设备的功能。收发模块1202，用于接收第二车载设备的第一参数。处理模块1201，用于根据第一参数，确定第一密钥，以及根据第一密钥，更新第一车载设备的密钥。
示例的，装置1200用于实现第二车载设备的功能。收发模块1202，用于接收第三车载设备发送的第一参数，以及向第一车载设备发送第一参数。处理模块1201，用于对第一参数进行处理，例如，可根据第一参数，更新第二车载设备的密钥等。
在上述示例中，关于处理模块1201和收发模块1202的具体功能，可参见上述方法实施例中图10流程中的记载，在此不再说明。
示例的，装置1200用于实现第一车载设备的功能。处理模块1201，用于根据第二车载设备的标识和第一参数，确定第一密钥。收发模块1202，用于向第二车载设备发送第一密钥。
示例的，装置1200用于实现第二车载设备的功能。收发模块1202，用于接收第一车载设备发送的第一密钥。处理模块1201，用于根据第一密钥，更新第二车载设备的密钥。
在上述示例中，关于处理模块1201和收发模块1202的具体功能，可参见上述方法实施例中图11流程中的记载，在此不再说明。
关于处理模块1201、收发模块1202的具体执行过程，可参见上方法实施例中的记载。本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
与上述构思相同，如图13所示，本申请实施例还提供一种装置1300。
示例的，装置1300可以用于实现上述方法中第一车载设备的功能，该装置可以是车 载设备，也可以是车载设备中的装置。装置1300包括至少一个处理器1301，用于实现上述方法中第一车载设备的功能。示例的，处理器1301可根据第一车载设备的标识，确定第一密钥，以及根据第一密钥和第一消息，确定第二消息。具体的过程，可参见上述图4所示流程中的记载，在此不再说明。装置1300还包括至少一个存储器1302，用于存储程序指令和/或数据。处理器1301和存储器1302耦合。本申请实施例中的耦合是装置、单元或模块之间的间隔耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。作为另一种实现，存储器1302还可位于装置1300之外。处理器1301可以和存储器1302协同操作。处理器1301可以执行存储器1302中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。装置1300还可以包括通信接口1303，用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。示例的，通信接口1303可以是收发器、电路、总线、模块或其它类型的通信接口，该其它设备可以是第二车载设备。处理器1301利用通信接口1303收发数据，用于实现上述图4流程所示实施例中的方法。示例的，通信接口1303可向第二车载设备发送第二消息等。
示例的，装置用于实现上述方法中第二车载设备的功能，该装置可以是车载设备，也可以是车载设备中的装置。装置1300包括至少一个处理器1301，用于实现上述方法中第二车载设备的功能。示例的，处理器1301可根据第一车载设备的标识，确定第一密钥，以及根据第一密钥和第二消息，确定第一消息。具体的过程，可参见上述图4所示流程中的记载，在此不再说明。装置1300还包括至少一个存储器1302，用于存储程序指令和/或数据。处理器1301和存储器1302耦合。本申请实施例中的耦合是装置、单元或模块之间的间隔耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。作为另一种实现，存储器1302还可位于装置1300之外。处理器1301可以和存储器1302协同操作。处理器1301可以执行存储器1302中存储的程序指令。所述至少一个存储器1302中的至少一个可以包括于处理器1301中。装置1300还可以包括通信接口1303，用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。示例的，通信接口1303可以是收发器、电路、总线、模块或其它类型的通信接口，该其它设备可以是第一车载设备。处理器1301利用通信接口1303收发数据，用于实现上述图4流程所示实施例中的方法。示例的，通信接口1303可接收第一车载设备发送的第二消息等。
示例的，装置用于实现上述方法中第一车载设备的功能，该装置可以是车载设备，也可以是车载设备中的装置。装置1300包括至少一个处理器1301，用于实现上述方法中第二车载设备的功能。示例的，处理器1301可根据第一参数，确定第一密钥，以及根据第一密钥，更新第一车载设备的密钥等。具体的过程，可参见上述图10所示流程中的记载，在此不再说明。装置1300还包括至少一个存储器1302，用于存储程序指令和/或数据。处理器1301和存储器1302耦合。本申请实施例中的耦合是装置、单元或模块之间的间隔耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。作为另一种实现，存储器1302还可位于装置1300之外。处理器1301可以和存储器1302协同操作。处理器1301可以执行存储器1302中存储的程序指令。所述至少一个存储器1302中的至少一个可以包括于处理器1301中。装置1300还可以包括通信接口1303，用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。 示例的，通信接口1303可以是收发器、电路、总线、模块或其它类型的通信接口，该其它设备可以是第一车载设备。处理器1301利用通信接口1303收发数据，用于实现上述图4流程所示实施例中的方法。示例的，通信接口1303可接收第二车载设备发送的第一参数等。
示例的，装置用于实现上述方法中第二车载设备的功能，该装置可以是车载设备，也可以是车载设备中的装置。装置1300包括至少一个处理器1301，用于实现上述方法中第二车载设备的功能。示例的，处理器1301可根据第一参数，更新第二车载设备的密钥等。具体的过程，可参见上述图10所示流程中的记载，在此不再说明。装置1300还包括至少一个存储器1302，用于存储程序指令和/或数据。处理器1301和存储器1302耦合。本申请实施例中的耦合是装置、单元或模块之间的间隔耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。作为另一种实现，存储器1302还可位于装置1300之外。处理器1301可以和存储器1302协同操作。处理器1301可以执行存储器1302中存储的程序指令。所述至少一个存储器1302中的至少一个可以包括于处理器1301中。装置1300还可以包括通信接口1303，用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。示例的，通信接口1303可以是收发器、电路、总线、模块或其它类型的通信接口，该其它设备可以是第一车载设备。处理器1301利用通信接口1303收发数据，用于实现上述图10流程所示实施例中的方法。示例的，通信接口1303可接收第三车载设备发送的第一参数等。
示例的，装置用于实现上述方法中第一车载设备的功能，该装置可以是车载设备，也可以是车载设备中的装置。装置1300包括至少一个处理器1301，用于实现上述方法中第一车载设备的功能。示例的，处理器1301可根据第二车载设备的标识和第一参数，确定第一密钥。具体的过程，可参见上述图11所示流程中的记载，在此不再说明。装置1300还包括至少一个存储器1302，用于存储程序指令和/或数据。处理器1301和存储器1302耦合。本申请实施例中的耦合是装置、单元或模块之间的间隔耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。作为另一种实现，存储器1302还可位于装置1300之外。处理器1301可以和存储器1302协同操作。处理器1301可以执行存储器1302中存储的程序指令。所述至少一个存储器1302中的至少一个可以包括于处理器1301中。装置1300还可以包括通信接口1303，用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。示例的，通信接口1303可以是收发器、电路、总线、模块或其它类型的通信接口，该其它设备可以是第一车载设备。处理器1301利用通信接口1303收发数据，用于实现上述图4流程所示实施例中的方法。示例的，通信接口1303可向第二车载设备发送第一密钥等。
示例的，装置用于实现上述方法中第二车载设备的功能，该装置可以是车载设备，也可以是车载设备中的装置。装置1300包括至少一个处理器1301，用于实现上述方法中第二车载设备的功能。示例的，处理器1301可根据第一密钥，更新第二车载设备的密钥等。具体的过程，可参见上述图11所示流程中的记载，在此不再说明。装置1300还包括至少一个存储器1302，用于存储程序指令和/或数据。处理器1301和存储器1302耦合。本申请实施例中的耦合是装置、单元或模块之间的间隔耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。作为另一种实现，存储器1302还可位于装置1300之外。处理器1301可以和存储器1302协同操作。处理器1301可以执行 存储器1302中存储的程序指令。所述至少一个存储器1302中的至少一个可以包括于处理器1301中。装置1300还可以包括通信接口1303，用于通过传输介质和其它设备进行通信，从而用于装置1300中的装置可以和其它设备进行通信。示例的，通信接口1303可以是收发器、电路、总线、模块或其它类型的通信接口，该其它设备可以是第一车载设备。处理器1301利用通信接口1303收发数据，用于实现上述图4流程所示实施例中的方法。示例的，通信接口1303可接收第一车载设备发送的第一密钥等。
本申请实施例中不限定上述通信接口1303、处理器1301以及存储器1302之间的连接介质。本申请实施例在图13中以存储器1302、处理器1301以及通信接口1303之间通过总线1304连接，总线在图13中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为了便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
本申请还提供了一种芯片系统，该芯片系统包括处理器，用于实现上述方法中第一车载设备的功能。示例的，所述芯片系统还包括存储器，用于保存程序指令和/或数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
本申请还提供了一种芯片系统，该芯片系统包括处理器，用于实现上述方法中第二车载设备的功能。示例的，所述芯片系统还包括存储器，用于保存程序指令和/或数据。该芯片系统，可以由芯片构成，也可以包括芯片和其他分立器件。
本申请还提供一种系统，该系统包括上述实施例中所记载的第一车载设备和第二车载设备。
在本申请实施例中，处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
在本申请实施例中，存储器可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
本申请实施例提供的方法中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，简称DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机可以存取的任何可用介质或者是包含一个或多个 可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，简称DVD))、或者半导体介质(例如,SSD)等。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (32)

  1. 一种通信方法，其特征在于，包括:
    根据第一车载设备的标识，确定所述第一车载设备的第一密钥；
    根据所述第一密钥和第一消息，确定第二消息；
    向第二车载设备发送所述第二消息。
  2. 如权利要求1所述的方法，其特征在于，所述第一车载设备为域内设备或域控制设备，所述根据第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：
    根据所述第一车载设备的标识和总密钥，确定所述第一密钥，所述总密钥为管理所述第一车载设备的网关所对应的密钥。
  3. 如权利要求2所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(总密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法。
  4. 如权利要求1所述的方法，其特征在于，所述第一车载设备为域内设备，所述根据第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：
    根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，所述域控制设备用于对所述第一车载设备进行管理，所述总密钥为管理所述域控制设备的网关所对应的密钥。
  5. 如权利要求4所述的方法，其特征在于，所述根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，包括：
    根据所述域控制设备的标识和所述总密钥，确定第二密钥；
    根据所述第二密钥和所述第一车载设备的标识，确定所述第一密钥。
  6. 如权利要求5所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(第二密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法；
    所述第二密钥满足以下条件：
    所述第二密钥＝KDF(总密钥，域控制设备的标识)。
  7. 一种通信方法，其特征在于，包括：
    接收第一车载设备发送的第二消息；
    根据所述第一车载设备的标识，确定所述第一车载设备的第一密钥；
    根据所述第一密钥和第二消息，确定第一消息。
  8. 如权利要求7所述的方法，其特征在于，所述第一车载设备为域控制设备或域内设备，所述根据所述第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：
    根据所述第一车载设备的标识和总密钥，确定所述第一密钥，所述总密钥为管理所述第一车载设备的网关所对应的密钥。
  9. 如权利要求8所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(总密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法。
  10. 如权利要求7所述的方法，其特征在于，所述第一车载设备为域内设备，所述根据第一车载设备的标识，确定所述第一车载设备的第一密钥，包括：
    根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，所述域控制设备用于对所述第一车载设备进行管理，所述总密钥为管理所述域控制设备的网关所对应的密钥。
  11. 如权利要求10所述的方法，其特征在于，所述根据域控制设备的标识、总密钥和所述第一车载设备的标识，确定所述第一密钥，包括：
    根据所述域控制设备的标识和所述总密钥，确定第二密钥；
    根据所述第二密钥和所述第一车载设备的标识，确定所述第一密钥。
  12. 如权利要求11所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(第二密钥，第一车载设备的标识)，所述KDF表示密钥衍生算法；
    所述第二密钥满足以下条件：
    所述第二密钥＝KDF(总密钥，域控制设备的标识)。
  13. 一种更新密钥的方法，其特征在于，包括：
    接收第二车载设备发送的第一参数；
    根据所述第一参数，确定第一密钥；
    根据所述第一密钥，更新所述第一车载设备的密钥。
  14. 如权利要求13所述的方法，其特征在于，所述第一车载设备根据所述第一参数，确定第一密钥，包括：
    根据第二密钥、第一参数和所述第一车载设备的标识，确定所述第一密钥，所述第二密钥为所述第一车载设备的初始密钥，或者，所述第二密钥为所述第一车载设备的更新前密钥。
  15. 如权利要求14所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(第二密钥，第一车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
  16. 一种更新密钥的方法，其特征在于，包括：
    接收第三车载设备发送的第一参数，所述第三车载设备为管理第二车载设备的网关，所述第二车载设备为管理第一车载设备的域控制器，；
    向所述第一车载设备发送第一参数，所述第一参数用于更新所述第一车载设备的密钥。
  17. 如权利要求16所述的方法，其特征在于，所述第一参数还用于更新所述第二车载设备的密钥，所述方法还包括：
    根据所述第一参数，确定第三密钥；
    根据所述第三密钥，更新所述第二车载设备的密钥。
  18. 如权利要求17所述的方法，其特征在于，所述根据所述第一参数，确定第三密钥，包括：
    根据第四密钥、所述第二车载设备的标识和第一参数，确定所述第三密钥，所述第四密钥为所述第二车载设备的初始密钥，或者，所述第四密钥为所述第二车载设备的更新前密钥。
  19. 如权利要求18所述的方法，其特征在于，所述第三密钥满足以下条件：
    所述第三密钥＝KDF(第四密钥，第二车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
  20. 一种更新密钥的方法，其特征在于，包括：
    根据第二车载设备的标识和第一参数，确定第一密钥，所述第一密钥为所述第二车载设备的待更新密钥，第一车载设备为管理所述第二车载设备的网关，所述第二车载设备为域控制设备或域内设备；
    向所述第二车载设备发送所述第一密钥。
  21. 如权利要求20所述的方法，其特征在于，所述根据所述第二车载设备的标识和第一参数，确定第一密钥，包括：
    根据所述第二车载设备的标识、总密钥和第一参数，确定第一密钥，所述总密钥为管理所述第一车载设备的网关所对应的密钥。
  22. 如权利要求21所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(总密钥，第二车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
  23. 如权利要求20至22任一项所述的方法，其特征在于，所述第二车载设备为域控制设备，向所述第二车载设备发送所述第一密钥，包括：
    直接向所述第二车载设备发送所述第一密钥。
  24. 如权利要求20至23任一项所述的方法，其特征在于，所述第二车载设备为域内设备，向所述第二车载设备发送所述第一密钥，包括：
    向第三车载设备发送第一密钥，所述第三车载设备为管理所述第二车载设备的域控制器，以使得所述第三车载设备将所述第一密钥转发至所述第二车载设备。
  25. 一种更新密钥的方法，其特征在于，包括：
    接收第一车载设备发送的第一密钥，所述第一密钥是根据第二车载设备的标识和第一参数所确定的，所述第一车载设备为管理第二车载设备的网关，所述第二车载设备为域控制设备或域内设备；
    根据所述第一密钥，更新所述第二车载设备的密钥。
  26. 如权利要求25所述的方法，其特征在于，所述第一密钥是根据第二车载设备的标识和第一参数所确定的，具体为：
    所述第一密钥是根据所述第二车载设备的标识、总密钥和第一参数所确定的，所述总密钥为所述网关的密钥。
  27. 如权利要求26所述的方法，其特征在于，所述第一密钥满足以下条件：
    所述第一密钥＝KDF(总密钥，第二车载设备的标识，第一参数)，所述KDF表示密钥衍生算法。
  28. 如权利要求25至27任一项所述的方法，其特征在于，所述第二车载设备为域控制设备，所述接收第一车载设备发送的第一密钥，包括：
    直接接收所述第一车载设备发送的第一密钥。
  29. 如权利要求25至27任一项所述的方法，其特征在于，所述第二车载设备为域内设备，所述接收第一车载设备发送的第一密钥，包括：
    接收第三车载设备发送的第一密钥，所述第三车载设备为管理所述第二车载设备的域控制设备，所述第一密钥为所述第一车载设备发送给所述第三车载设备的。
  30. 一种装置，其特征在于，用于实现权利要求1至29任一项所述的方法。
  31. 一种装置，其特征在于，包括处理器和存储器，所述存储器中存储有指令，所述处理器执行所述指令时，使得所述装置执行权利要求1至29任一项所述的方法。
  32. 一种计算机可读存储介质，其特征在于，包括指令，当其在计算机上运行时，使得所述计算机执行权利要求1至29任一项所述的方法。
PCT/CN2020/081927 2019-08-30 2020-03-28 一种通信、更新密钥的方法及装置 WO2021036252A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910819103.3A CN112449326A (zh) 2019-08-30 2019-08-30 一种通信、更新密钥的方法及装置
CN201910819103.3 2019-08-30

Publications (1)

Publication Number Publication Date
WO2021036252A1 true WO2021036252A1 (zh) 2021-03-04

Family

ID=74685443

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/081927 WO2021036252A1 (zh) 2019-08-30 2020-03-28 一种通信、更新密钥的方法及装置

Country Status (2)

Country Link
CN (1) CN112449326A (zh)
WO (1) WO2021036252A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113170291B (zh) * 2021-03-09 2023-07-11 华为技术有限公司 安全通信的方法和装置
CN113098860B (zh) * 2021-03-30 2023-04-07 三一汽车起重机械有限公司 一种can总线加密方法、装置、工程机械和存储介质
CN115225672B (zh) * 2022-07-14 2024-07-26 蔚来汽车科技(安徽)有限公司 端到端的数据传输方法、设备和介质
WO2024036435A1 (zh) * 2022-08-15 2024-02-22 华为技术有限公司 通信方法、装置和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106533655A (zh) * 2016-10-27 2017-03-22 江苏大学 一种车内网ecu安全通信的方法
CN108965218A (zh) * 2017-05-25 2018-12-07 华为技术有限公司 一种控制器区域网总线安全通信方法、装置及系统
CN108989024A (zh) * 2018-06-29 2018-12-11 百度在线网络技术（北京）有限公司 控制在车辆中电子控制单元间通信的方法、装置、设备、存储介质以及相应车辆
WO2019017844A1 (en) * 2017-07-20 2019-01-24 Huawei International Pte. Ltd. SYSTEM AND METHOD FOR MANAGING SECURE COMMUNICATIONS BETWEEN MODULES IN A CONTROL AREA NETWORK
US20190173862A1 (en) * 2016-08-03 2019-06-06 Lg Electronics Inc. Vehicle and method for controlling same

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190173862A1 (en) * 2016-08-03 2019-06-06 Lg Electronics Inc. Vehicle and method for controlling same
CN106533655A (zh) * 2016-10-27 2017-03-22 江苏大学 一种车内网ecu安全通信的方法
CN108965218A (zh) * 2017-05-25 2018-12-07 华为技术有限公司 一种控制器区域网总线安全通信方法、装置及系统
WO2019017844A1 (en) * 2017-07-20 2019-01-24 Huawei International Pte. Ltd. SYSTEM AND METHOD FOR MANAGING SECURE COMMUNICATIONS BETWEEN MODULES IN A CONTROL AREA NETWORK
CN108989024A (zh) * 2018-06-29 2018-12-11 百度在线网络技术（北京）有限公司 控制在车辆中电子控制单元间通信的方法、装置、设备、存储介质以及相应车辆

Also Published As

Publication number Publication date
CN112449326A (zh) 2021-03-05

Similar Documents

Publication Publication Date Title
WO2021036252A1 (zh) 一种通信、更新密钥的方法及装置
TWI716803B (zh) 一種進行混合自動重送請求回饋的方法和終端
US11812496B2 (en) User group session management method and apparatus
WO2020048512A1 (zh) 通信方法和装置
US10790995B2 (en) Oracle authentication using multiple memory PUFs
US20210258291A1 (en) Data messaging service with distributed ledger control
WO2020047806A1 (zh) 反馈信息传输方法、装置、设备及系统
EP3386252A1 (en) Resource requesting method, device, network side node and system
CN103988480A (zh) 用于认证的系统和方法
JP2022126821A (ja) コアネットワーク装置、通信端末、コアネットワーク装置の方法、プログラム、及び通信端末の方法
JP2021516489A (ja) 一時識別子を送信するための方法およびシステム
WO2021051974A1 (zh) 一种空口信息的安全保护方法及装置
CN116569576A (zh) 用于移动边缘计算网络的基于密钥的认证
WO2019096171A1 (zh) 一种请求恢复连接的方法及装置
WO2019196668A1 (zh) 一种信息发送方法、密钥生成方法以及装置
CN112601222B (zh) 一种空口信息的安全保护方法及装置
WO2021132087A1 (ja) Ａｍｆノード及びその方法
WO2021134381A1 (zh) 本地通信的方法、装置和系统
WO2022104740A1 (zh) 一种非公共网络签约信息更新方法及装置
WO2022147838A1 (zh) 无线通信的方法和装置
WO2023072271A1 (zh) 管理安全上下文的方法和装置
WO2024175001A1 (zh) 一种上行控制信息uci生成方法及通信装置
WO2023072275A1 (zh) 通信方法、装置及系统
WO2023065778A1 (zh) 中继通信的方法和装置
WO2023098209A1 (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: 20858876

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20858876

Country of ref document: EP

Kind code of ref document: A1