WO2024036435A1 - 通信方法、装置和系统 - Google Patents

通信方法、装置和系统 Download PDF

Info

Publication number
WO2024036435A1
WO2024036435A1 PCT/CN2022/112474 CN2022112474W WO2024036435A1 WO 2024036435 A1 WO2024036435 A1 WO 2024036435A1 CN 2022112474 W CN2022112474 W CN 2022112474W WO 2024036435 A1 WO2024036435 A1 WO 2024036435A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
key
public key
random number
information
Prior art date
Application number
PCT/CN2022/112474
Other languages
English (en)
French (fr)
Inventor
雅思敏雷哈娜
马建忠
付天福
魏卓
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2022/112474 priority Critical patent/WO2024036435A1/zh
Priority to PCT/CN2022/135195 priority patent/WO2024036805A1/zh
Priority to PCT/CN2023/091790 priority patent/WO2024037048A1/zh
Publication of WO2024036435A1 publication Critical patent/WO2024036435A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • 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]

Definitions

  • the present application relates to the field of security, and more specifically, to a communication method, device and system.
  • ECU Electronic control units
  • ECM electronic control modules
  • On-board control units need to communicate with each other for vehicle operation.
  • the communication content includes key operations that affect vehicle safety, and manipulation of the communication content may lead to serious consequences, in the worst case depriving the life of the user in the vehicle or other users. Therefore, it is often necessary to inject encryption keys into two vehicle-mounted control units that require communication, so that both communicating parties can encrypt the communication content.
  • the above communication method is not secure enough.
  • This application provides a communication method and device that can improve communication security between communication nodes.
  • a communication method is provided.
  • the method can be executed by a control unit or control module in a vehicle; or it can also be executed by a chip or circuit of a control unit or control module for a vehicle. This application does not cover this. limited.
  • the method may include: the first node receiving a first message from the first device, the first message including second node information, the second node information being used to indicate the second node; the first node receiving the first message according to the second node information.
  • the second node is determined; the first node generates a security key with the second node; the first node communicates with the second node according to the security key.
  • the first node receives a first message from the first device, the first message includes second node information, the second node information is used to indicate the second node and communicate with the second node .
  • the first node receives the first message sent by the first device via one or more devices. For example, the first node receives the first message sent by the first device via the electrical inspection device.
  • the first node and the second node may be nodes in the first terminal.
  • the first terminal may be a vehicle or other terminal equipment.
  • the first node can know which second nodes it needs to communicate with through the first message.
  • the first node can be a zone controller (ZC), a telecommunications unit (TCU), an in-vehicle infotainment (IVI), or an advanced driving assistance system (advanced driving assistant system, ADAS) and other devices equipped with safety hardware;
  • the second node can be ZC, TCU, IVI, ADAS and other devices equipped with safety hardware in the above embodiment, or it can also be electric power steering (electric power steering) , EPS), electric parking brake (electric parking brake, EPB) and other equipment with safety hardware.
  • the first node and the second node may be connected through an Ethernet cable, or may also be connected through a controller area network-flexible data (CAN-FD) cable.
  • CAN-FD controller area network-flexible data
  • the first node may be a layer 0 device
  • the second node may be a layer 0 device or a layer 1 device.
  • the first message may also include identification information of the first terminal.
  • the identification information of the first terminal may be a vehicle identification number (VIN), or may be other capable information.
  • VIN vehicle identification number
  • Information indicating the identity of the first terminal is not specifically limited in this application.
  • first node and the second node may also be other components in the terminal device that require communication.
  • the first message may be a signed trust credential
  • the signed trust credential may be in the form of a table, or may be a file, or may be in other forms. This is the case in the embodiments of this application. No specific limitation is made.
  • the first device can be an OEM PKI server, or it can also be a computing platform in the first terminal, such as a vehicle domain controller (VDC), a mobile data center (MDC) ), at least one of the chassis domain controller (chassis domain controller, CDC); or it can also be other trusted devices, such as vehicle control server ICAS1, intelligent driving server ICAS2, infotainment server ICAS3, body domain controller , BDC), special equipment system (special equipment system, SAS), media graphics unit (media graphics unit, MGU), body super core (BSC), ADAS super core (ADAS super core), cockpit super core (cockpit super core, CSC) etc.
  • VDC vehicle domain controller
  • MDC mobile data center
  • CDC chassis domain controller
  • other trusted devices such as vehicle control server ICAS1, intelligent driving server ICAS2, infotainment server ICAS3, body domain controller , BDC), special equipment system (special equipment system, SAS), media graphics unit (media graphics unit, MGU), body super core (BSC), ADAS super core (ADAS super core),
  • the first node may be a node that replaces the original first node, and/or the second node may be a node that replaces the original second node.
  • the first node may also be a node prepared to replace the original first node, and/or the second node may also be a node prepared to replace the original second node.
  • the first node can establish a mutual "trust relationship" with the second node based on the first message containing the second node information. Further, the first node can verify the legitimacy of the identity of the second node through the first message, and after passing the verification, negotiate with the second node to share the security key. Further, a shared security key may be used between the first node and the second node to generate a session key for each communication. When the business requires secure communication, use the session key to encrypt the communication content and establish secure communication, which helps ensure the confidentiality and integrity of the communication data.
  • the first node generates a security key with the second node, including: storing in the second node the information indicating that the first node When the first node information is obtained, the first node generates a security key according to the second node information, and the security key is used for session encryption between the first node and the second node.
  • the first node information is used to indicate that the second node communicates with the first node, and/or the first node information includes public key information of the first node.
  • the first node generates a security key based on the second node information can be understood to mean that the first node confirms that there is a communication requirement with the second node based on the second node information. Further, The first node generates a random number, receives the temporary public key sent by the second node, and then generates the security key based on the temporary public key and the random number generated by itself. The temporary public key sent by the second node is generated by the second node based on the random number generated by itself.
  • the second node generates the same security key as the security key generated by the first node based on the public key information of the first node.
  • the method for the first node and the second node to generate the security key may be the Diffie-Hellman key exchange protocol, or it may be other pre-shared key calculation technology, which is not specifically limited in this application.
  • the security key may be stored in secure hardware of the first node to avoid unauthorized access or tampering.
  • the first node can also use standard TLS solutions to verify the identity of the second node and calculate the security key.
  • TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA can be used for this purpose.
  • the first node and the second node negotiate a security key based on the first message and the other party's public key information, and communicate based on the security key, which greatly improves the negotiation performance of the secure connection. It can also reduce the risk of security key leakage and reduce the complexity of security key management.
  • the method further includes: the first node generating a first random number; the first node generating a security key with the second node, including: The first node generates the security key based on the first random number and the second node information.
  • the first node before the first node generates the first random number, the first node confirms that there is a communication requirement between the first node and the second node based on the first message (or second node information), and then generates the second random number for the second node.
  • a random number such as v1.
  • the first node generates the security key according to the random numbers v1 and G ⁇ s1.
  • the second node does not know which nodes it needs to communicate with.
  • the second node is a layer 1 device that does not save the information of the first node.
  • the first node generates a first public key based on a first random number, such as G ⁇ v1. It should be understood that, correspondingly, the second node generates the same security key as the security key generated by the first node based on the first public key G ⁇ v1 and its own private key s1.
  • the security key may be stored in secure hardware of the first node to avoid unauthorized access or tampering.
  • the layer 0 device and the layer 1 device negotiate a security key based on the first message and the other party's public key information, and communicate based on the security key, which greatly improves the negotiation performance of the secure connection.
  • the method further includes: the first node generates a second random number; the first node generates a first public key according to the first random number; The first node sends the second random number and the first public key to the second node; the first node receives the first encrypted value, the first encrypted value is encrypted by the second node according to the first security key The second random number is obtained, the first security key is generated based on the secret key of the second node and the first public key; the first node decrypts the first encrypted value based on the security key; When decryption of the first encrypted value is successful, the first node stores the security key.
  • the second random number may be a Nonce value, or may be other random numbers, which is not specifically limited in this application.
  • the identity authentication of the second node is completed.
  • the second node can be considered to be the legal node indicated by the first message.
  • the second node can also use the above method to authenticate the identity of the first node, and after successful authentication, store the security key.
  • performing identity authentication on the second node can further ensure communication security.
  • the method further includes: the first node generates a third random number; the first node generates a second public key according to the third random number; The first node sends the first signature generated based on the first node's private key and the second public key to the second node; the first node receives the second signature, and the second signature is a pair of the second node's After the first signature is successfully verified, it is generated based on the private key of the second node and the third public key.
  • the third public key is generated based on the fourth random number generated by the second node; the third public key is generated based on the fourth random number generated by the second node; A node verifies the second signature based on the second node information; the first node generates a security key with the second node, including: when the verification of the second signature is successful, the first node verifies the second signature based on the second node information.
  • the three-key public key and the third random number generate the secure key.
  • the second node stores the first node information.
  • the first node information includes the public key information of the first node.
  • the second node can store the first node information according to the first signature and the first node information.
  • the four random numbers calculate the same security key as the security key generated by the first node based on the third public key and the third random number.
  • a method for generating a security key between the layer 1 device and the layer 0 device is provided when the layer 1 device stores the public key information of the layer 0 device, which helps to ensure that the layer 1 device and the layer 0 device Communication between devices is secure.
  • the first node receives, from the first device, third node information indicating a third node and indicating the second node and the third node Information that needs to be communicated; the first node generates a fifth random number; the first node generates a fourth public key based on the fifth random number and the second node information; the first node generates a fourth public key based on the fifth random number and the second node information.
  • the third node information generates a fifth public key; the first node sends the fifth public key to the second node; the first node sends the fourth public key to the third node.
  • the third node information and the information indicating that the second node and the third node need to communicate may be included in the first message; or the third node information and the information indicating that the second node needs to communicate
  • the information that needs to be communicated with the third node can also be sent separately from the first message, which is not specifically limited in the embodiment of the present application.
  • the second node and the third node may both be layer 1 devices in the first terminal.
  • the second node and the third node cannot know which layer 1 devices they can communicate with, they need to use the first node to assist the second node and the third node in generating the security keys required for communication between them.
  • the second node can generate a security key based on its own private key and the fifth public key; the third node can generate a security key based on its own private key and the fourth public key.
  • the security generated by the two nodes is The keys are the same.
  • the first node can assist other nodes to generate the security keys required for communication without the need for external key injection, so that the key is closed in the first terminal, which can greatly reduce the risk of key leakage and reduce key management. the complexity.
  • the method before the first node receives the first message, the method further includes: the first node sending the signature public key of the first node to the second device, the The first node's signing public key is used to generate the first message.
  • the second device may be an OEM TSP, or may be other nodes or devices of the OEM that are capable of generating trust credentials.
  • the second device may be an electrical inspection device.
  • the signature public key of the first node is signed by the OEM PKI server and forwarded by the OEM TSP, then the OEM TSP saves the signature public key of the first node. At this time, the first node does not need to submit the signature public key to the OEM TSP. The OEM TSP sends the first node’s signature public key (via the electrical inspection equipment).
  • the first signature certificate is issued by the equipment manufacturer, then the OEM TSP does not save the first node's signature public key of the first node. At this time, the first node needs to report to the OEM TSP (via the electrical inspection equipment ) sends the signature public key of the first node, so that OEMTSP generates the first message based on the signature public key of the first node.
  • the second node information includes public key information of the second node.
  • the public key information of the second node includes at least one of the following: the public key signature certificate of the second node; the identity of the public key signature certificate of the second node Identification number ID; the hash value of the public key of the second node and the identity information of the second node.
  • the overhead required for storing the public key information can be reduced.
  • the method further includes: the first node receiving service information of the second node from the first device, the service information of the second node being used to indicate the Services in the second node that the first node can access.
  • the second node supports service A, service B, service C and service D, but the second node only allows the first node to access service A and service B, then the service information of the second node may include service A and service B. Information about service B to instruct the first node to access its service A and service B. It should be understood that in the above situation, the first node cannot access service C and service D of the second node.
  • the above services A to D may be respectively: air conditioning service, door control service, brake control service and steering control service.
  • the service information of the second node may be included in the first message.
  • the service information of the second node and the signed trust certificate can be sent separately.
  • more fine-grained access control can be constructed based on the communication between the first node and the second node, so that the first node can only access part of the services of the second node.
  • it can ensure that the third node The content of the remaining services of the second node will not be leaked, further improving communication security.
  • the security key includes at least one of the following: a pre-shared key, a diagnostic key, a secure vehicle communication SecOC key, and other application keys.
  • pre-shared keys, diagnostic keys, secure vehicle communication SecOC keys, other application keys, etc. are all generated based on the second node information, without the need for external "filling" keys, making the security encryption
  • the key can form a closed loop inside the first terminal, which facilitates key management and reduces the risk of key leakage.
  • the method further includes: the first node generates a trust token; the first node sends the trust token to a fourth node; the first node generates a third Six random numbers; the first node generates a second security key based on the trust token and the sixth random number; the first node sends the second security key encrypted by the trust token to the fourth node to The fourth node decrypts the trust token stored in advance to obtain the second security key.
  • the second security key is used for session encryption between the first node and the fourth node.
  • the sixth random number may be a Nonce value, or may be other random numbers.
  • the fourth node may be a layer 2 device, or may be other devices without security hardware.
  • the first node can generate the security key required for communication between the fourth node and the fourth node without the need for "filling" of external keys, preventing external connections from threatening the security of the first terminal.
  • the method before the first node sends the trust token to the fourth node, the method further includes: the first node based on the authentication code SN of the fourth node, At least one of the physical fingerprint, authentication chip, and security chip authenticates the fourth node; the first node sends the trust token to the fourth node, including: when the authentication is successful, the first node sends the trust token to the fourth node. Send this trust token.
  • identity authentication of the fourth node can further ensure communication security.
  • the method further includes: the first node performs identity authentication on the fourth node based on the second security key; when the identity authentication passes, the third node A node deletes the trust token.
  • deleting the trust token can prevent external intruders from stealing the trust token and causing security threats.
  • a communication method may include: a second device receiving a first message sent by a first device, the first message including second node information, and the second node information being used to indicate the second node; the second device sends the first message to the first node.
  • the second device may be an OEM TSP, or other nodes or devices of the OEM that can generate trust credentials; or the second device may also be an electrical inspection device.
  • the second device when the second device is an OEM device such as an OEM TSP, the second device can directly receive the first message sent by the first device, and further, the second device sends the first message to the electrical inspection device. , the electrical inspection equipment sends the first message to the first node.
  • the second device when the second device is an OEM device such as an OEM TSP, the second device can directly receive the first message sent by the first device, and further, the second device sends the first message to the electrical inspection device. , the electrical inspection equipment sends the first message to the first node.
  • the second device when the second device is an electrical inspection device, the second device can receive the first message sent by the first device through OEM equipment such as OEM TSP, and further, the second device directly sends the message to the first node.
  • OEM equipment such as OEM TSP
  • the second device directly sends the message to the first node. The first news.
  • the second device directly receives the first message sent by the first device, and directly sends the first message to the first node.
  • the OEM or electrical inspection equipment sends a first message containing the information of the second node to the first node, so that a "trust relationship" is established between the first node and the second node, which is helpful for the first node and the second node.
  • the second node generates a session key based on the first message. Furthermore, when the business requires secure communication, using session keys for communication helps ensure the confidentiality and integrity of communication data.
  • the method before the second device receives the first message sent by the first device, the method further includes: the second device determines the first message according to the communication list and the signature of the second node.
  • the public key generates a second message, and the communication list is used to indicate that the first node and the second node need to communicate; the second device sends the second message to the first device.
  • this method may be performed by the OEM TSP, or may also be performed by other nodes or devices of the OEM that are capable of generating trust credentials.
  • the communication list may be in the form of a list, or may be in the form of a matrix.
  • the communication list is used to indicate the communication relationship between nodes in the first terminal.
  • the communication list may also be in other forms, and this application does not cover this. Specific limitations.
  • the second message may be an unsigned trust credential.
  • the trust credential may be a whitelist of other nodes communicating with the first node, and the trust credential includes public key information of other nodes communicating with the first node.
  • the OEM device can generate the second message, so that the first device signs the second message to generate the first message, which helps to establish "trust” between the nodes in the first terminal based on the first message. relation".
  • the second device is an electrical detection device, and the method further includes: the second device receiving the signature public key of the first node sent by the third device; The second device sends the signature public key of the first node to the first node.
  • the first device and the third device may be the same device, for example, both are OEM PKI servers; or the first device and the third device may be different devices, for example, the first device is an OEM PKI server, and the third device is the equipment vendor server.
  • the third device when the third device is different from the first device, before the electrical inspection device receives the first message sent by the first device, it needs to obtain the signature public key of the first node from the first node.
  • the electrical inspection equipment sends the signature public key of the first node to the first node to facilitate the subsequent generation and use of the first message based on the signature public key of the first node.
  • a communication method may include: a first device receiving a second message sent by a second device; the first device signing the second message to generate a first message; The first node sends the first message.
  • the first device generates a signature trust table by signing the trust table, so that the signature trust table cannot be easily changed by other devices, which helps to further improve communication security.
  • a communication method is provided, which method can be executed by a control unit or control module in a vehicle (or other terminal); or, it can also be performed by a control unit or control module for a vehicle (or other terminal). Chip or circuit execution, this application does not limit this.
  • the method may include: the second node receives a first public key, the first public key is generated by the first node according to a first message, the first message includes second node information, and the second node information is Instructing the second node; the second node generates a security key based on the first public key, and the security key is used for session encryption between the first node and the second node; or, the security key The key is used to encrypt the session between the second node and the third node.
  • the second node may be a layer 1 device.
  • the third node may be a layer 1 device that has communication requirements with the second node.
  • the session key between the second node and the third node is generated by the first node
  • the first public key is generated by the first node according to the first message
  • the The first public key is generated by the first node based on the first random number and the public key of the third node on the premise that the first node determines that the second node and the third node need to communicate based on the first message.
  • the second node generates a security key based on the first public key may mean: the second node generates a security key based on the first public key and the private key of the second node. It should be understood that in the above case, this security key is used for session encryption between the second node and the third node.
  • the second node when the second node does not save the first node information, "the second node generates a security key based on the first public key. ", may be: the second node generates a security key based on the first public key and the private key of the second node; or, when the second node saves the first node information, "the second node generates a security key based on the first public key and the private key of the second node; "The first public key generates a second security key” may also be: the second node generates a security key based on the first public key and a random number generated by the second node based on the second signature trust certificate. It should be understood that in the above case, this second security key is used for session encryption between the first node and the second node.
  • the second node can generate a security key based on the first public key sent by the first node.
  • the security key can be used to generate a session key required for communication with the first node or the third node.
  • the key eliminates the need for external "filling" of the key, which helps to improve the security of the internal key of the first terminal.
  • the first public key is a public key signed using the private key of the first node
  • the method further includes: the second node according to The first message determines the public key of the first node; the second node verifies the first public key according to the public key of the first node; the second node generates a fifth random number; the second node verifies the first public key according to the first node's public key.
  • the first public key generating a security key includes: when the verification is successful, the second node generates a security key based on the first public key and the fifth random number.
  • the first public key may be the first signature in the above-mentioned first aspect.
  • the second node and the first node can negotiate a security key based on the first message and the other party's public key information, and communicate using the security key, which greatly improves the negotiation performance of the secure connection. It can also reduce the risk of security key leakage and reduce the complexity of security key management.
  • a first node in a fifth aspect, includes: a transceiver unit configured to receive a first message from a first device.
  • the first message includes second node information, and the second node information is used to indicate The second node;
  • a processing unit configured to determine the second node according to the second node information; generate a security key with the second node; and communicate with the second node according to the security key.
  • the processing unit is specifically configured to: when the second node stores first node information indicating the first node, the first node performs the processing according to the first node information.
  • the two-node information generates a security key, which is used for session encryption between the first node and the second node.
  • the processing unit is further configured to: generate a first random number; and generate the security key according to the first random number and the second node information.
  • the processing unit is further configured to generate a second random number; generate a first public key according to the first random number; and the transceiver unit is further configured to provide the first public key to the first random number.
  • the second node sends the second random number and the first public key; receives a first encrypted value, the first encrypted value is obtained by the second node encrypting the second random number according to the first security key, and the second node A security key is generated based on the secret key of the second node and the first public key; the processing unit is also used to decrypt the first encrypted value based on the security key; in the first encrypted value When decryption is successful, the security key is stored.
  • the processing unit is further configured to: generate a third random number; generate a second public key based on the third random number; the transceiver unit is further configured to provide the The second node sends the first signature generated based on the private key of the first node and the public key of the second key; receives the second signature, which is generated based on the second node's successful verification of the first signature.
  • the private key of the second node and the third public key are generated according to the fourth random number generated by the second node; the processing unit is also used to generate the third public key according to the fourth random number generated by the second node;
  • the information verifies the second signature; when the verification of the second signature is successful, the first node generates the security key based on the third public key and the third random number.
  • the transceiver unit is further configured to: receive third node information indicating a third node from the first device and indicating the second node and the Information that the third node needs to communicate; the processing unit is also used to generate a fifth random number; generate a fourth public key according to the fifth random number and the second node information; according to the fifth random number and the third The node information generates a fifth public key; the transceiver unit is also used to send the fifth public key to the second node; and send the fourth public key to the third node.
  • the transceiver unit is further configured to: before receiving the first message, send the signature public key of the first node to the second device, the signature of the first node The public key is used to generate this first message.
  • the second node information includes public key information of the second node.
  • the public key information of the second node includes at least one of the following: the public key signature certificate of the second node; the identity of the public key signature certificate of the second node Identification number ID; the hash value of the public key of the second node and the identity information of the second node.
  • the transceiver unit is further configured to: receive service information of the second node from the first device, where the service information of the second node is used to indicate the first Services in this second node that the node can access.
  • the security key includes at least one of the following: a pre-shared key, a diagnostic key, a secure vehicle communication SecOC key, and other application keys.
  • the processing unit is also used to: generate a trust token; the transceiver unit is also used to send the trust token to the fourth node; the processing unit is also used to: Generate a sixth random number; generate a second security key according to the trust token and the sixth random number; the transceiver unit is also used to send the second security key encrypted by the trust token to the fourth node to The fourth node decrypts the trust token stored in advance to obtain the second security key.
  • the second security key is used for session encryption between the first node and the fourth node.
  • the processing unit is also configured to: before the transceiver unit sends the trust token to the fourth node, according to the authentication code SN, physical fingerprint, At least one of the authentication chip and the security chip authenticates the fourth node; the transceiver unit is specifically used to send the trust token to the fourth node when the authentication is successful.
  • the processing unit is also configured to: perform identity authentication on the fourth node based on the second security key; and delete the trust token when the identity authentication is passed. Card.
  • a second device in a sixth aspect, includes: a transceiver unit configured to receive a first message sent by the first device, the first message including second node information, and the second node information is used to Instruct the second node; send the first message to the first node.
  • the second device further includes a processing unit, configured to: before the transceiver unit receives the first message sent by the first device, according to the communication list and the second The signature public key of the node generates a second message, and the communication list is used to indicate that the first node and the second node need to communicate; the transceiver unit is also used to send the second message to the first device.
  • a processing unit configured to: before the transceiver unit receives the first message sent by the first device, according to the communication list and the second The signature public key of the node generates a second message, and the communication list is used to indicate that the first node and the second node need to communicate; the transceiver unit is also used to send the second message to the first device.
  • the transceiver unit when the second device is an electrical inspection device, the transceiver unit is further configured to: receive the signature public key of the first node sent by the third device; The first node sends the first node's signature public key.
  • a first device in a seventh aspect, includes: a transceiver unit for receiving a second message sent by a second device; a processing unit for signing the second message to generate a first message; The transceiver unit is also used to send the first message to the first node.
  • a second node including: a transceiver unit configured to receive a first public key, the first public key being generated by the first node according to the first message, the The first message includes second node information, the second node information is used to indicate the second node; a processing unit is used to generate a security key based on the first public key, the security key is used for the first node session encryption between the second node and the second node; or, the security key is used for session encryption between the second node and the third node.
  • the first public key is a public key signed using the private key of the first node
  • the processing unit is further configured to: according to the first node A message determines the public key of the first node; verifies the first public key according to the public key of the first node; generates a fifth random number; when the verification is successful, based on the first public key and the third public key Five random numbers generate a secure key.
  • a ninth aspect provides a communication device.
  • the device includes: a memory for storing a program; a processor for executing the program stored in the memory.
  • the processor is configured to execute the first aspect. Or the method in any possible implementation manner of the fourth aspect.
  • a communication device in a tenth aspect, includes: a memory for storing a program; a processor for executing the program stored in the memory.
  • the processor When the program stored in the memory is executed, the processor is configured to execute the second aspect. Or any method in the possible implementation of the third aspect.
  • a communication system in an eleventh aspect, includes a first node in any possible implementation manner of the above-mentioned fifth aspect, and a second node in any possible implementation manner of the above-mentioned eighth aspect.
  • the first node generates a first random number, and generates a security key based on the first random number and second node information, wherein the second node The information is used to indicate the second node; the first node generates a first public key according to the first random number; the first node sends the first public key to the second node; the second node receives the first public key, generate a first security key based on the private key of the second node and the first public key, and encrypt the second random number based on the first security key to obtain the first encryption value; the second node sends the first encrypted value to the first node; the first node receives the first encrypted value and decrypts the first encrypted value according to the security key, and the first node When the first encrypted value is decrypted successfully, the first node stores the security key.
  • the second node stores the first security key after generating the first security key.
  • the first node may use the security key to encrypt the first random number to generate a second encrypted value and send it to the second node. Further, after successfully decrypting the second encrypted value according to the first security key, the second node stores the first security key.
  • the first node generates a third random number and generates a second public key based on the third random number; the first node provides the The second node sends a first signature generated based on the first node's private key and the second public key; the second node receives the first signature, generates a fourth random number, and generates a fourth random number based on the fourth random number.
  • Three-key public key when the first signature is successfully verified, the second node generates a second signature based on the second node's private key and the third key public key, and sends the second signature to the first node.
  • the second node generates a third security key based on the fourth random number and the second public key; the first node receives the second signature and verifies the second signature based on the second node information.
  • the fourth security key is generated based on the third public key and the third random number.
  • the third security key is the same as the fourth security key.
  • the third security key is the same security key as the security key "generated by the first node based on the third public key and the third random number" in the first aspect.
  • the system further includes the first device of the eighth aspect, the second node includes a first device and a second device; the first node Receive, from the first device, first device information for indicating a first device, second device information for indicating a second device, and information for indicating that the first device and the second device need to communicate; the first The node generates a fifth random number; the first node generates a fourth public key based on the fifth random number and the first device information; the first node generates a fifth random number based on the fifth random number and the second device information.
  • the first node sends the fifth public key to the first device; the first node sends the fourth public key to the second device; the first device receives the fifth public key
  • the second device receives the fourth public key and generates a fifth security key based on the private key of the first device and the fifth public key; the second device receives the fourth public key and generates a fifth security key based on the private key of the second device. and the fourth public key to generate a sixth security key.
  • a twelfth aspect provides a vehicle, which includes the first node in any possible implementation of the fifth aspect and/or the second node in any possible implementation of the eighth aspect.
  • the vehicle (sometimes referred to as a vehicle) in this application is a vehicle in a broad sense, which can be a means of transportation (such as a car, a truck, a motorcycle, a train, an airplane, a ship, etc.), an industrial vehicle (such as a forklift, Trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawn mowers, harvesters, etc.), amusement equipment, toy vehicles, etc.
  • This application does not limit the type of vehicles. .
  • a terminal device in a thirteenth aspect, includes the second device in any possible implementation manner of the sixth aspect and/or the first device in any possible implementation manner of the seventh aspect.
  • a computer program product includes: computer program code.
  • the computer program code When the computer program code is run on a computer, it causes the computer to execute any one of the possibilities of the first to fourth aspects. Methods in the implementation.
  • the above computer program code may be stored in whole or in part on the first storage medium, where the first storage medium may be packaged together with the processor, or may be packaged separately from the processor. This is not the case in the embodiments of this application. Specific limitations.
  • a computer-readable medium stores program code.
  • the computer program code When the computer program code is run on a computer, it causes the computer to execute any one of the first to fourth aspects. Methods in possible implementations.
  • a chip in a sixteenth aspect, includes a processor for calling a computer program or computer instructions stored in a memory, so that the processor executes any one of the above possible implementations of the first to fifth aspects. method within the method.
  • the processor is coupled with the memory through an interface.
  • the chip system further includes a memory, and a computer program or computer instructions are stored in the memory.
  • Figure 1 is a schematic functional block diagram of a vehicle provided by an embodiment of the present application.
  • Figure 2 is a schematic diagram of a communication system architecture provided by an embodiment of the present application.
  • Figure 3 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 4 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 5 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 6 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 7 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 8 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 9 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 10 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 11 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 12 is a schematic diagram of an application scenario of a communication method provided by an embodiment of the present application.
  • Figure 13 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 14 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 15 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 16 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 17 is a schematic flow chart of a communication method provided by an embodiment of the present application.
  • Figure 18 is a schematic block diagram of a communication device provided by an embodiment of the present application.
  • Figure 19 is another schematic block diagram of a communication device provided by an embodiment of the present application.
  • Prefixes such as “first” and “second” are used in the embodiments of this application only to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects.
  • the use of ordinal words and other prefixes used to distinguish the described objects does not limit the described objects.
  • Words constitute redundant restrictions.
  • plural means two or more.
  • FIG. 1 is a functional block diagram of a vehicle 100 provided by an embodiment of the present application.
  • the vehicle 100 may include a perception system 120 , a display device 130 , and a computing platform 150 , where the perception system 120 may include several types of sensors that sense information about the environment surrounding the vehicle 100 .
  • the sensing system 120 may include a positioning system.
  • the positioning system may be a global positioning system (GPS), a Beidou system or other positioning systems, an inertial measurement unit (IMU), a lidar, a millimeter One or more of wave radar, ultrasonic radar and camera device.
  • GPS global positioning system
  • IMU inertial measurement unit
  • lidar a millimeter One or more of wave radar, ultrasonic radar and camera device.
  • the computing platform 150 may include processors 151 to 15n (n is a positive integer).
  • the processor is a circuit with signal processing capabilities.
  • the processor may be a circuit with instruction reading and execution capabilities.
  • CPU central processing unit
  • microprocessor microprocessor
  • GPU graphics processing unit
  • DSP digital signal processor
  • the processor can realize certain functions through the logical relationship of the hardware circuit. The logical relationship of the hardware circuit is fixed or can be reconstructed.
  • the processor is an application-specific integrated circuit (application-specific integrated circuit).
  • Hardware circuits implemented by ASIC or programmable logic device (PLD), such as field programmable gate array (FPGA).
  • PLD programmable logic device
  • FPGA field programmable gate array
  • the process of the processor loading the configuration file and realizing the hardware circuit configuration can be understood as the process of the processor loading instructions to realize the functions of some or all of the above units.
  • it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing Unit (deep learning processing unit, DPU), etc.
  • the computing platform 150 may also include a memory, which is used to store instructions. Some or all of the processors 151 to 15n may call instructions in the memory and execute the instructions to implement corresponding functions.
  • the vehicle 100 may include ADAS that utilizes a variety of sensors in the perception system 120 (including but not limited to: lidar, millimeter wave radar, cameras, ultrasonic sensors, global positioning systems, inertial measurement units) to obtain information from around the vehicle, and Analyze and process the acquired information to achieve functions such as obstacle perception, target recognition, vehicle positioning, path planning, driver monitoring/reminder, etc., thereby improving the safety, automation and comfort of vehicle driving.
  • sensors in the perception system 120 including but not limited to: lidar, millimeter wave radar, cameras, ultrasonic sensors, global positioning systems, inertial measurement units
  • FIG. 2 shows a schematic diagram of a communication system architecture provided by an embodiment of the present application.
  • the vehicle communication network 200 includes layer 0 devices, layer 1 devices, and layer 2 devices.
  • layer 0 devices include ZC, TCU, IVI, ADAS, etc., which are connected to each other through Ethernet cables.
  • Layer 0 devices usually have secure hardware, such as hardware security module (HSM), trusted platform module (TPM), etc., which enable layer 0 devices to generate security keys and perform public key encryption operations.
  • the generated "security keys” include, but are not limited to, pre-shared keys (PSK), diagnostic keys, secure onboard communication (SecOC) keys, and other application keys. .
  • Layer 1 devices are typically connected to each other via CAN-FD cables, and to layer 0 devices via CAN-FD.
  • Layer 1 equipment includes EPS, EPB, and can also include CDC, etc.
  • Layer 1 may have security hardware such as HSM, TPM, etc.
  • CAN-FD protocol allows the transmission of 64 bytes of data in the controller area network (CAN) frame data portion, which is much smaller than the payload of the Ethernet frame.
  • Layer 2 devices are resource-constrained ECU devices with no security hardware and are connected to each other via a low-bandwidth CAN bus.
  • examples of layer 2 devices may include CAN ECUs, sensors, actuators, etc.
  • ECUs connected via non-Ethernet do not have standard TLS cipher suites available to implement transport layer security (TLS)-based security.
  • TLS transport layer security
  • devices with security hardware but connected through the CAN bus can still perform lightweight public key operations and can be regarded as layer 1 devices in the embodiment of this application.
  • Devices that do not have security hardware but are connected through CAN-FD are still considered resource-limited Layer 2 devices in this embodiment because they cannot perform public key operations.
  • "public key operation” may include an operation of autonomously generating a public-private key pair.
  • this application divides vehicle-mounted devices into three categories based on their connection types and processing capabilities, namely layer 0 devices, layer 1 devices, and layer 2 devices.
  • layer 0 devices the connection types and processing capabilities
  • layer 1 devices the connection types and processing capabilities
  • layer 2 devices the connection types and processing capabilities
  • corresponding solutions are proposed for each layer to establish secure communication between various vehicle-mounted devices.
  • Each layer 0 device establishes a "trust relationship" with other layer 0 devices mentioned above through a trust table that contains information about other layer 0 devices it communicates with. Furthermore, the public key encryption technology based on the signature certificate establishes a device authentication mechanism and trusted communication between layer 0 devices, so that a "trust ring" is formed between all layer 0 devices, in which any one from the trust ring Devices can further assist other devices in the trust ring to authenticate and communicate securely.
  • Secure communication of layer 1 devices Based on the trust table of layer 0 devices, establish a "trust relationship" between layer 0 devices and layer 1 devices, as well as layer 1 devices and layer 1 devices, and establish trust relationships between these devices based on the above trust relationships. Establish secure communications.
  • Layer 0 devices verify trust relationships with Layer 2 devices and use symmetric key cryptographic operations to establish secure communications with Layer 2 devices.
  • ECUs with secure hardware are capable of performing public key cryptographic operations (for example, elliptic curve cryptography (ECC)), secure key generation and storage, etc.
  • ECC elliptic curve cryptography
  • Figure 3 shows a schematic flow chart of a communication method provided by the embodiment of the present application. More specifically, Figure 3 shows a method for generating keys and signature certificates in layer 0 devices.
  • the embodiment of the present application uses 0 Take the zone controller ZC1 in the layer device as an example for explanation.
  • the method can include:
  • the electrical inspection equipment activates the public/private key generation.
  • the generated public key/private key pair of the layer 0 device is activated.
  • ZC1 generates the first public key and the first private key.
  • first public key and the first private key form a key pair.
  • ZC1 will generate its private key/public key pair within the secure hardware and send the first public key (eg PK_ZC1) to the electrical inspection device, while keeping the first private key within its own secure hardware. It should be understood that no third party can obtain or tamper with private keys stored securely in secure hardware.
  • the electrical inspection equipment sends the first public key to the public key infrastructure (public key infrastructure, PKI) server.
  • public key infrastructure public key infrastructure, PKI
  • the electrical inspection equipment and the PKI server can be connected through wireless communication, such as the Internet or the Internet of Things, which is not specifically limited in the embodiment of the present application.
  • S305 The PKI server signs the first public key and generates a first signature certificate containing the first public key.
  • the PKI server uses its own private key to sign the first public key of ZC1 to generate a signing certificate (for example, CERT_PK_ZC1). It should be understood that this certificate contains ZC1's public key.
  • S306 The PKI server sends the first signature certificate to the electrical inspection equipment.
  • the electrical inspection equipment sends the first signature certificate to ZC1.
  • the on-board equipment supplier (such as the supplier of ZC1) can perform the steps performed by the electrical inspection equipment or PKI server shown in Figure 3 during equipment production.
  • the electrical inspection equipment can be the supplier For electrical inspection equipment, further, the supplier's PKI server will sign the first signing certificate.
  • the method described in Figure 3 can also be performed by the vehicle manufacturer (original equipment manufacturer, OEM).
  • the electrical inspection equipment will be the OEM's electrical inspection equipment, and the OEM's PKI server will sign the first A signed certificate.
  • the method shown in Figure 3 can be used to generate a private key/public key pair and obtain the signature certificate of the public key.
  • Figure 4 shows a schematic flow chart of a communication method provided by an embodiment of the present application. More specifically, Figure 4 shows a method for generating a trust table between layer 0 devices. The method may include:
  • the OEM electrical inspection equipment requests a certificate from the layer 0 equipment.
  • the OEM electrical inspection device can be connected to multiple layer 0 devices respectively, and request a signature certificate from each layer 0 device (such as ZC1, ZC2, and ZC3) respectively.
  • the layer 0 device sends the signature certificate to the OEM electrical inspection equipment.
  • each layer 0 device sends its signature certificate to the OEM electrical inspection device.
  • layer 0 devices include ZC1, ZC2, and ZC3, ZC1, ZC2, and ZC3 will send their signature certificates to the electrical inspection equipment respectively.
  • ZC1 sends the signature certificate CERT_PK_ZC1 to the OEM electrical inspection equipment
  • ZC2 sends the signature certificate CERT_PK_ZC2 to the OEM electrical inspection equipment
  • ZC3 sends the signature certificate CERT_PK_ZC3 to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends the signature certificate to the OEM.
  • the electrical inspection equipment sends all signed certificates to the OEM.
  • the OEM electrical inspection equipment may send all signature certificates to the OEM at once, or may send them in batches, for example, one or more signature certificates at a time, which is not specifically limited in the embodiment of this application.
  • the OEM verifies the signature certificate and generates a trust table for each layer 0 device based on the signature certificate.
  • the OEM maintains a communication matrix that contains information indicating which vehicle-mounted device has communication requirements with another vehicle-mounted device. It should be noted that the existence of communication requirements between device 1 and device 2 may mean that there may be signaling interactions between device 1 and device 2 during vehicle operation. In the specific implementation process, device 1 and device 2 do not necessarily communicate or have signaling interactions.
  • the OEM creates a trust table for each layer 0 device based on the communication matrix and signing certificate. For example, the OEM knows that there are communication requirements between ZC1, ZC2, and ZC3 based on the communication matrix. Therefore, ZC1's trust table will contain the public key information and VIN of ZC2 and ZC3, which should be understood to be globally unique for each vehicle.
  • the information of ZC2 and ZC3 may be the signature certificate IDs of ZC2 and ZC3, for example, the signature certificate ID CertID_ZC2 corresponding to the signature certificate of ZC2 (CERT_PK_ZC2) and the signature certificate ID CertID_ZC3 corresponding to the signature certificate of ZC3 (CERT_PK_ZC3).
  • ZC2's trust table will have ZC1's signing certificate ID, as well as any other layer 0 devices that need to communicate during vehicle operation (such as ZC4).
  • the trust tables of ZC1 and ZC2 are shown in Table 1 and Table 2 respectively.
  • the information of ZC2 and ZC3 may include the public key hashes of ZC2 and ZC3, that is, the public key hashes of ZC2 and ZC3 are listed in the trust table of ZC1.
  • the information of ZC2 and ZC3 may include the signature certificates of ZC2 and ZC3, that is, the trust table of ZC1 includes the signature certificates of ZC2 and ZC3.
  • a device trust table may also include the authentication code (serial number, SN) of the device that needs to communicate with it.
  • the trust table of ZC1 may also include the SN code of ZC2 and the SN code of ZC3.
  • ZC2’s trust table can also include the SN code of ZC1 and the SN code of ZC4.
  • the OEM will prepare a trust table for each layer 0 device of the vehicle and send the trust table for each layer 0 device to the OEM PKI server.
  • the OEM may send all the trust tables to the OEM PKI server at once, or may send them in batches, for example, one or more trust tables at a time, which is not specifically limited in the embodiments of this application.
  • the OEM PKI server uses its own private key to sign each trust table, generating multiple signed trust tables. It should be understood that one signature trust table corresponds to one layer 0 device.
  • the OEM PKI server can send its public key to each layer 0 device via the OEM and OEM electrical inspection equipment, so that the layer 0 device verifies the signature trust table based on the public key.
  • the OEM PKI server sends multiple signature trust tables to the OEM.
  • the OEM electrical inspection equipment sends the signature trust table to the layer 0 equipment.
  • the OEM electrical inspection equipment sends the signed trust table to the corresponding layer 0 device, for example, the signed ZC1 trust table is sent to ZC1, and the signed ZC2 trust table is sent to ZC2.
  • each layer 0 device saves its own signature trust table.
  • the signed ZC1 trust table will be stored in ZC1, and so on.
  • OEM involved in the embodiment of this application may be the OEM's trust service provider (trust service provider, TSP), or it may also be other equipment of the OEM that can generate a trust table.
  • TSP trust service provider
  • the trust table of the layer 0 device is signed by the OEM PKI server, and external devices cannot change these signed trust tables. Therefore, with the help of signature binding and the signature trust table, a "trust relationship" is established between layer 0 devices. Furthermore, the layer 0 device uses the public key information contained in the trust table to form a "trust ring". Devices on the ring can authenticate and establish secure communications with other devices on the ring that need to communicate with them based on the signature trust table. There is no need for any other third party to be involved in this process. In addition, layer 0 devices also help other layer devices establish secure communications.
  • two layer 0 devices can calculate the PSK between them based on the signature trust table. It should be understood that during the vehicle operation phase, the two layer 0 devices will use the PSK to calculate the session key. This calculated PSK will be stored in the secure hardware of the respective device to avoid unauthorized access and/or tampering. It should be understood that the process is the same for all layer 0 devices that need to calculate the PSK.
  • both ZC1 and ZC2 will calculate a PSK.
  • both ZC1 and ZC2 will determine the other party's signing certificate based on the trust table.
  • ZC1 and ZC2 will use the OEM PKI server's public key (which is a key pair with the secret key used to sign the public key of the layer 0 device) to verify each other's signature certificate.
  • ZC1 uses the OEM PKI server.
  • the public key verifies ZC2's signing certificate. After successful verification, they can obtain each other's public keys from the signing certificate.
  • ZC1 obtains ZC2's public key from ZC2's signing certificate
  • ZC2 obtains ZC1's public key from ZC1's signing certificate.
  • ZC1 and ZC2 can use the Diffie-Hellman (DH) key exchange protocol to calculate the PSK.
  • DH Diffie-Hellman
  • ZC1 generates a random value as the secret key, and generates the first temporary public key based on the secret key
  • ZC2 generates a random value as the secret key, and generates the first temporary public key based on the secret key.
  • Temporary public key ZC1 and ZC2 exchange each other's temporary public keys, and use the temporary public key and their own secret keys to calculate the same shared key, which can later be used to generate a new session key.
  • ZC1 generates a random value v1 as the secret key and calculates the first temporary public key G ⁇ v1.
  • ZC2 generates a random value v2 as the secret key and calculates the second temporary public key G ⁇ v2.
  • the other party sends its own temporary public key.
  • ZC1 calculates the shared key G ⁇ v2v1 based on v1 and the second temporary public key G ⁇ v2, and ZC2 calculates the shared key G ⁇ v2v1 based on v2 and the first temporary public key G ⁇ v1.
  • layer 0 devices are connected to each other via Ethernet, they can also use standard TLS solutions to authenticate each other and calculate the PSK.
  • TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA can be used for this purpose.
  • the vehicle production phase usually occurs in a controlled and trusted environment, while the vehicle operation phase is the aftermarket phase and is an environment more vulnerable to third-party attacks during actual vehicle operation.
  • These devices communicate with each other during vehicle operation. To protect this communication, the device may require keys to encrypt the communication and/or authentication keys for message integrity. Therefore, the vehicle device establishes session keys at this stage based on its needs.
  • the session key can be generated once, daily, or when the vehicle engine is started.
  • ZC1 and ZC2 authenticate each other using PSK, which is securely stored in the security hardware of ZC1 and ZC2.
  • PSK is securely stored in the security hardware of ZC1 and ZC2.
  • both parties have communication needs, one party needs to prove to the other party that it knows the PSK, that is, identity verification.
  • both parties can calculate new session keys using the Diffie-Hellman key exchange protocol or other such protocols, and use these session keys to encrypt communications, and/or calculate authentication information.
  • layer 0 devices are connected to each other via Ethernet, they can also use standard TLS and PSK solutions to establish new session keys.
  • TLS_PSK_WITH_AES_128_CBC_SHA can be used for this purpose.
  • the car owner or driver can authorize the OEM to perform parts replacement by entering a password/PIN through the car's graphical user interface or registered mobile phone.
  • ZC1 will be replaced by ZC1'.
  • ZC1’ will generate a private/public key pair and obtain a signing certificate for the public key.
  • Figure 5 shows a schematic flow chart of a communication method provided by an embodiment of the present application. More specifically, Figure 5 shows a method for updating the trust table of a new device and other devices that have a direct communication relationship with the new device. Methods can include:
  • the OEM electrical inspection equipment is connected to ZC1' and requests a signature certificate from ZC1'.
  • ZC1’ sends ZC1’s signature certificate to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends ZC1’s signature certificate to the OEM.
  • the OEM verifies the signature certificate of ZC1’, generates a trust table for ZC1’ based on the signature certificate of ZC1’, and updates the trust tables of other layer 0 devices communicating with ZC1’.
  • ZC1' replaces ZC1
  • the OEM since ZC1' replaces ZC1, the OEM only needs to import the contents of ZC1's trust table into ZC1''s trust table, and import the ZC1 information from other layer 0 devices.
  • the ZC1 public key information in the trust table is replaced with the ZC1' public key information.
  • the trust table in this step may include the trust table of ZC1' and the trust tables of other layer 0 devices that need to communicate with ZC1'.
  • the OEM can send all the above trust tables to the OEM PKI server at once or in batches.
  • the OEM PKI server uses its own private key to sign each trust table separately to generate multiple signed trust tables.
  • the OEM PKI server sends the signature trust table to the OEM.
  • the signature trust table in this step includes the signature trust table of ZC1’ and the signature trust tables of other layer 0 devices that need to communicate with ZC1’.
  • ZC1' stores ZC1's signature trust table.
  • the OEM electrical inspection equipment will also send the signature trust tables of other layer 0 devices that need to communicate with ZC1’ to the corresponding layer 0 devices, so that they can update the signature trust tables.
  • the layer 0 device affected by the device replacement can subsequently perform authentication based on the signature trust table and/or signature certificate and calculate the pre-shared key. It should be understood that while the vehicle is running, the device will calculate the new session key as normal.
  • Figure 6 shows a schematic flow chart of a communication method provided by the embodiment of the present application. More specifically, Figure 6 shows a method of key generation in a layer 1 device. This method is the same as the key generation method in a layer 0 device. The method is similar.
  • the embodiment of this application takes the controller ECU1 in the layer 1 device as an example to illustrate. The method may specifically include:
  • the generated public key/private key pair of the layer 1 device is activated.
  • ECU1 generates a private key and calculates the public key based on the private key.
  • ECU1 will generate the key "s1" and the corresponding public key G ⁇ s1 within the secure hardware.
  • ECU1 sends the public key to the OEM electrical inspection equipment.
  • ECU1 sends the public key G ⁇ s1 to the OEM electrical inspection device, while the private key "s1" remains within the secure hardware.
  • S604 The OEM electrical inspection equipment sends the public key to the PKI server.
  • the PKI server uses the private key of the PKI as a certificate to sign the public key G ⁇ s1, and generates the signed ECU1 public key CERT_G ⁇ s1.
  • the signed ECU1 public key CERT_G ⁇ s1 is essentially a signature certificate containing the ECU1 public key. In order to distinguish it from the signature certificate of the layer 0 device, the signature certificate of the layer 1 device is called the signed certificate. ECU1 public key.
  • the PKI server sends the signed public key of ECU1 to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends the signed public key of ECU1 to ECU1.
  • ECU1 saves the signed public key of ECU1.
  • the OEM may perform the method shown in Figure 6 during vehicle production. It should be understood that for each layer 1 device, the method shown in Figure 6 can be used to generate a private key/public key pair and obtain the signature certificate of the public key.
  • Figure 7 shows a schematic flow chart of a communication method provided by an embodiment of the present application. More specifically, (a) in Figure 7 shows a method for a layer 0 device to generate a trust table containing layer 1 device information. The method can include:
  • the OEM electrical inspection equipment requests the signed public key from the layer 1 equipment.
  • the layer 1 device sends the signed public key to the OEM electrical inspection device.
  • each Tier 1 device sends its signed certificate to the OEM power inspection device.
  • layer 1 devices include ECU1, ECU2 and ECU3, then ECU 1, ECU 2 and ECU 3 respectively send their signature certificates to the detection device.
  • ECU 1 sends the signed public key CERT_G ⁇ s1 to the OEM electrical inspection equipment;
  • ECU 2 sends the signed certificate CERT_G ⁇ s2 to the OEM electrical inspection equipment;
  • ECU 3 sends the signed certificate CERT_G ⁇ s3 to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends the signed public key to the OEM/OEM PKI server.
  • the OEM electrical inspection equipment sends the signed public key to the OEM, so that the OEM subsequently generates a trust table based on the signed public key.
  • the OEM electrical inspection equipment requests a signature certificate from the layer 0 device.
  • the layer 0 device sends the signed certificate to the OEM electrical inspection equipment.
  • each layer 0 device sends its signature certificate to the OEM electrical inspection device.
  • layer 0 devices include ZC1, ZC2, and ZC3, then ZC1, ZC2, and ZC3 respectively send their signature certificates to the detection device.
  • ZC1 sends the signature certificate CERT_PK_ZC1 to the OEM electrical inspection equipment
  • ZC2 sends the signature certificate CERT_PK_ZC2 to the OEM electrical inspection equipment
  • ZC3 sends the signature certificate CERT_PK_ZC3 to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends the signature certificate to the OEM/OEM PKI server.
  • the OEM electrical inspection equipment sends the signature certificate to the OEM, so that the OEM subsequently generates a trust table based on the signature certificate.
  • the OEM/OEM PKI server generates a trust table for each layer 0 device based on the signed public key and signing certificate, and signs the trust table.
  • the OEM verifies the signed public key and signing certificate, and based on the communication matrix, generates a trust table for each layer 0 device based on the signed public key and signing certificate.
  • the trust table contains information related to the layer 0 device.
  • the device has public key information for other layer 0 devices and layer 1 devices that require communication. For example, ZC1 will communicate with ZC2, ZC3, ECU1, and ECU2, and ZC2 will communicate with ZC1, ZC4, ECU3, and ECU4.
  • the trust table of ZC1 will contain the public key information of ZC2, ZC3, ECU1, and ECU2, as well as the VIN; the trust table of ZC2 will contain the public key information of ZC1, ZC4, ECU3, and ECU4, as well as the VIN.
  • the public key information may be in the form of an ID of a signing certificate, or in the form of a signing certificate, or in the form of a public key hash.
  • the trust table can also include a constant point G of a generating point for calculating the public key based on the private key.
  • the trust table may not include the constant point G of the generation point, but store the constant point G of the generation point in the security environment of the layer 0 device and/or the layer 1 device.
  • a trust table containing layer 0 and layer 1 device information can be generated, as shown in Table 3; for layer 0 device ZC2, a trust table containing layer 0 and layer 1 device information can also be generated. , shown in Table 4.
  • two trust tables are also generated, one of which only contains information about layer 0 devices (as shown in Table 5), and the other only contains information about layer 1 devices (as shown in Table 6). It should be understood that with the latter form of trust table, it is easier to update the trust table when the layer 0 device or the layer 1 device is replaced.
  • the trust table of layer 0 devices may also include the SN code of layer 1 devices.
  • the trust table of ZC1 may also include the SN code of ECU1 and the SN code of ECU2.
  • the trust table of ZC2 may also include the SN code of ECU1 and the SN code of ECU2. It can also include the SN code of ECU3 and the SN code of ECU4.
  • the OEM will send the trust table to the OEM PKI server.
  • the PKI server will sign these trust tables and send them back to the OEM.
  • the OEM/OEM PKI server sends the signature trust table to the OEM electrical inspection equipment.
  • the electrical inspection device will receive the signed trust table of each layer 0 device.
  • the OEM electrical inspection equipment sends the signature trust table to the layer 0 equipment.
  • the OEM electrical inspection equipment sends the signed trust table to the corresponding layer 0 device, for example, the signed ZC1 trust table is sent to ZC1, and the signed ZC2 trust table is sent to ZC2.
  • the layer 0 device stores the signed trust table.
  • ZC1's trust table will be stored in ZC1, and so on.
  • a trust table containing layer 0 device information can also be generated for layer 1 devices.
  • the specific method is shown in (b) in Figure 7. The method can include:
  • the OEM electrical inspection equipment requests the signed public key from the layer 1 equipment.
  • the layer 1 device sends the signed public key to the OEM electrical inspection device.
  • the OEM electrical inspection equipment sends the signed public key to the OEM/OEM PKI server.
  • the OEM/OEM PKI server verifies the signed public key, generates a trust table for the layer 1 device, and signs the trust table.
  • the OEM verifies the signed public key, and based on the communication matrix, generates a trust table for each layer 1 device based on the signed public key.
  • the trust table contains other devices that have communication needs with the layer 1 device.
  • Public key information of layer 0 devices For example, ECU1 will communicate with ZC1, therefore, ECU1's trust table will contain ZC1's public key (such as G ⁇ zc1), and the VIN, as shown in Table 7.
  • the trust table can also include a constant point G of a generating point for calculating the public key based on the private key.
  • the trust table may not include the constant point G of the generation point, but store the constant point G of the generation point in the security environment of the layer 0 device and/or the layer 1 device.
  • the trust table of the layer 1 device may also include the SN code of the layer 0 device communicating with it.
  • the trust table of ECU1 may also include the SN code of ZC1.
  • the OEM will send the trust table to the OEM PKI server.
  • the PKI server will sign these trust tables and send them back to the OEM.
  • OEM/OEM PKI sends a layer 1 device signature trust table to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends the layer 1 signature trust table to the layer 1 device.
  • the OEM electrical inspection equipment sends the signed trust table to the corresponding layer 1 device, for example, the signed ECU1 trust table is sent to ECU1, and the signed ECU2 trust table is sent to ECU2.
  • the layer 1 device stores the signature trust table.
  • ECU1's trust table will be stored in ECU1, and so on.
  • the OEM electrical inspection equipment requests a signature certificate from the layer 0 device.
  • the layer 0 device sends the signed certificate to the OEM electrical inspection equipment.
  • the OEM electrical inspection equipment sends the signature certificate to the OEM/OEM PKI server.
  • the OEM/OEM PKI server generates a trust table for each layer 0 device based on the signed public key and signing certificate, and signs the trust table.
  • the OEM/OEM PKI server sends the layer 0 device signature trust table to the OEM electrical inspection equipment.
  • the electrical inspection device will receive the signed trust table of each layer 0 device.
  • the OEM electrical inspection equipment sends the layer 0 device signature trust table to the layer 0 device.
  • the OEM electrical inspection equipment sends the signed trust table to the corresponding layer 0 device, for example, the signed ZC1 trust table is sent to ZC1, and the signed ZC2 trust table is sent to ZC2.
  • Layer 0 devices store signed trust tables.
  • ZC1's trust table will be stored in ZC1, and so on.
  • generating a trust table (or signature trust table) for the layer 0 device can be the same as in the method shown in (a) in Figure 7. are consistent.
  • S704' to S706' need to be executed after S710', that is, after the OEM obtains the signature certificate of the layer 0 device.
  • the trust table generated for a layer 1 device needs to contain the signature certificate or signature certificate ID of a layer 0 device that has communication requirements with the layer 1 device, then S704' to S706' need to be executed after S710'.
  • the layer 0 device and the layer 1 device can establish a "trust relationship" based on the trust table, and can use the public key information contained in the trust table to communicate with other devices that need to communicate with it. Authentication and establishing secure communication with it. In this process, no other third party is required to participate, and security threats caused by external access can be effectively avoided.
  • Figure 8 shows a schematic flow chart of a communication method provided by the embodiment of the present application. More specifically, (a) in Figure 8 shows the communication method based on the layer 0 device when the layer 1 device does not have a trust table.
  • the trust table calculates the PSK method between layer 0 devices and layer 1 devices.
  • the method can include:
  • ZC1 generates a random number v1 as the secret key, and calculates the first public key based on v1. Generate a Nonce value N1 for authentication.
  • a shared key (such as PSK) needs to be calculated between ZC1 and ECU1 for use in subsequent communication sessions.
  • ZC1 will generate a random number v1 as the secret key, and calculate the first public key based on the random v1 as G ⁇ v1.
  • the secret key and the public key may be a DH key pair.
  • ZC1 will also generate a Nonce value N1, which will be used to authenticate ECU1 later. It should be understood that a Nonce is an arbitrary or non-repeating random value that is used only once.
  • ZC1 sends the first public key and Nonce value N1 to ECU1.
  • ZC1 may send the first public key and the Nonce value N1 at once, or may send the first public key and the Nonce value N1 separately.
  • ECU1 calculates the shared key SS.
  • ECU1 uses the shared key SS to encrypt Nonce N1.
  • ECU1 can use SS to encrypt Nonce N1.
  • ECU1 sends the encrypted Nonce N1 to ZC1.
  • ZC1 uses the shared key SS to decrypt the encrypted Nonce N1.
  • ZC1 uses SS to decrypt the encrypted Nonce N1 to obtain N1. Successful decryption will prove that ZC1 and ECU1 have the same shared key SS.
  • ECU1 sends Nonce value N2 to ZC1.
  • ECU1 uses the shared key SS to decrypt the encrypted Nonce N2.
  • ECU1 uses SS to decrypt the encrypted Nonce N2 to obtain N2. Successful decryption completes two-way authentication and shared key confirmation.
  • ECU1 saves the shared key SS.
  • S808 to S812 are optional.
  • S813 and S814 can be executed at the same time or one after another.
  • S814 can be executed before S813.
  • S803 and S804 can also be executed at the same time or one after another.
  • S804 can be executed before S803, or S804 can be executed before S802 or S803.
  • the PSK between the layer 0 device and the layer 1 device can be calculated based on the trust tables of the layer 0 device and the layer 1 device, as shown in the figure As shown in (b) in 8, the method may include:
  • ZC1 generates a random number v1 as the secret key, and calculates the first public key based on v1. Use your own private key to sign the first public key to generate V1’.
  • a shared key (such as PSK) needs to be calculated between ZC1 and ECU1 for use in subsequent communication sessions.
  • encryption For example, ZC1 will generate a random number v1 as the secret key, and calculate the first public key based on the random v1 as G ⁇ v1.
  • the secret key and the public key may be a DH key pair.
  • ECU1 uses the public key of ZC1 to verify V1’.
  • ECU1 can obtain the public key of ZC1 according to the trust table.
  • ECU1 generates a random number v2 as the secret key, and calculates the second public key G ⁇ v2 based on v2. Use your own private key to sign the second public key to generate V2’.
  • V2' Sign(G ⁇ v2,s1)
  • ECU1 sends V2’ to ZC1.
  • ZC1 uses the public key of ECU1 to verify V2’.
  • ZC1 can obtain the public key of ECU1 according to the trust table.
  • ZC1 uses the public key of ECU1 to calculate the shared key SS.
  • ECU1 uses the public key of ZC1 to calculate the shared key SS.
  • S807’ and S808’ can be executed at the same time or one after another.
  • S808’ can be executed before S807’, or S808’ can be executed before S802 or S804’.
  • Figure 8 takes generating a PSK as an example for illustration.
  • the method flow shown in Figure 8 can also be used to generate other security keys, such as diagnostic keys and secure vehicle communication SecOC keys. keys, other application keys, etc.
  • Figure 9 shows a schematic flow chart of a communication method provided by an embodiment of the present application. More specifically, Figure 9 shows a method for calculating PSK between layer 1 devices. It should be understood that since the layer 1 devices ECU1 and ECU2 do not have each other's public key information and have no other means of mutual authentication, and the layer 0 device ZC1 saves the public key information of the two, as well as the information that the two have communication needs, therefore, ZC1 can act as a "middleman" to assist ECU1 and ECU2 in calculating PSK.
  • the method can include:
  • S901, ZC1 generates a random number v, uses the public key of ECU2 and the random number v to calculate the third public key (G ⁇ s2.v) for ECU1, and uses the public key of ECU1 and the random number v to calculate the fourth public key (G ⁇ s1.v).
  • the random number v and the third public key (G ⁇ s2.v) constitute a DH key pair
  • the random number v and the fourth public key (G ⁇ s1.v) constitute a DH key pair.
  • ZC1 sends the public key (G ⁇ s2.v) to ECU1.
  • S903, ZC1 sends the public key (G ⁇ s1.v) to ECU2.
  • ECU1 uses its own key s1 to calculate the first key (G ⁇ s2.v.s1) based on the third public key (G ⁇ s2.v).
  • ECU2 uses its own key s2 to calculate the second key (G ⁇ s1.v.s2) based on the fourth public key (G ⁇ s1.v).
  • ECU1 exports the shared key SS.
  • ECU2 exports the shared key SS.
  • This shared secret SS will be used to generate new session keys during vehicle operation.
  • ECU1 and ECU2 can further complete identity authentication and key confirmation by exchanging Nonce values encrypted using SS. Successful decryption completes two-way authentication and key confirmation.
  • Layer 1 and/or Layer 0 devices with the same PSK can authenticate each other using the PSK, with the pre-shared key stored securely in secure hardware and known only to all parties.
  • both communicating parties prove to each other that they know the PSK, the identity authentication is completed. Further, both parties can calculate a new session key using the Diffie-Hellman key exchange protocol or any other such protocol. At the end of this step, both parties will have new session keys to encrypt the communication and/or calculate message authentication information.
  • Figure 9 takes the generation of PSK as an example for illustration.
  • the method flow shown in Figure 9 can also be used to generate other security keys, such as diagnostic keys and secure vehicle communication SecOC keys. keys, other application keys, etc.
  • the vehicle will last for decades. During this time, equipment in the vehicle may become damaged and require replacement.
  • the new Layer 1 device also requires keys to communicate securely, and trust tables need to be updated for the new device and other devices with which it has a direct communication relationship. It should be understood that after replacing a layer 1 device, the process of key signing and trust table updating for the new layer 1 device is similar to that of the layer 0 device. Reference can be made to the description in the above embodiments, which will not be described again here.
  • FIG. 10 shows the method of forming a pre-embedded trust token for a layer 2 device (taking CAN ECU1 as an example). The method can include:
  • this step may be described with reference to S301 or S601, and will not be described again here.
  • ZC1 generates a trust token s1, which may be a random number or other forms of trust token.
  • ZC1 sends the trust token to the OEM electrical inspection equipment.
  • CAN ECU1 stores the trust token.
  • ZC1 before injecting the trust token into CAN ECU1, ZC1 can authenticate CAN ECU1 based on at least one of the SN code, physical fingerprint, authentication chip, and security chip of CAN ECU1. After the authentication is successful, ZC1 will The trust token is injected into CAN ECU1.
  • the above-mentioned trust token can also be generated by the electrical inspection equipment, and then "injected” into ZC1 and CAN ECU1 respectively, that is, sent to ZC1 and CAN ECU1.
  • the communication method provided by the embodiment of this application can pre-embed trust tokens for layer 2 devices, avoid injecting external keys, and maintain key generation within the vehicle/component to the greatest extent, ensuring layer 0 in the vehicle. Security of communications between devices and layer 2 devices.
  • Figure 11 shows a method for forming PSK between a layer 0 device and a layer 2 device.
  • the method may include:
  • S1110, ZC1 generates a random number v1 as a secret key, calculates the shared key SS based on the trust token and the random number v1, and uses the trust token s1 to encrypt SS to obtain SS2.
  • S1120, ZC1 sends SS2 to CAN ECU1.
  • CAN ECU1 uses trust token s1 to decrypt SS2 to obtain SS.
  • SSCAN ECU1 and ZC1 can generate a new session key during vehicle operation.
  • CAN ECU1 and ZC1 can further complete identity authentication and key confirmation by exchanging Nonce values encrypted using SS. Successfully decrypting the SS-encrypted Nonce value will complete two-way authentication and key confirmation. Further, both CAN ECU1 and ZC1 delete the trust token s1.
  • the trust table of a vehicle-mounted device in the above embodiments may also include service-oriented architecture (SOA) service information of other devices that communicate with it.
  • SOA service-oriented architecture
  • ZC1 needs to communicate with ZC2 and ZC3.
  • the SOA services supported by ZC2 include service A, service B and service C.
  • the services that ZC2 opens to ZC1 are only service A.
  • the trust table of ZC1 except the public keys of ZC2 and ZC3.
  • it can also include information related to ZC2’s service A.
  • ZC1 can only access service A of ZC2, but cannot access service B and service C of ZC2.
  • service can be at least one of device abstract service, atomic service, composite service, and application service.
  • SOA is an architectural design idea that decomposes the system into relatively independent functional units.
  • the above relatively independent functional units are called services to the outside world.
  • Services can be encapsulated with abstract interfaces. Furthermore, these services can Communicate through defined interfaces and protocols.
  • Many services of a system may be classified based on a layered approach, for example, the underlying services are device abstract services, atomic services, and composite services, and the upper-layer services are called APPs.
  • Atomic services generally encapsulate sensors, actuators, etc. as abstract hardware resources into atomic services. Atomic services generally encapsulate the most basic logical functions. For example, seat control, window control, etc.
  • Composite service is a service formed by calling and combining atomic services.
  • Application service is a service formed by calling and combining atomic services and/or composite services. It generally encapsulates various application scenarios and is a service directly facing customers.
  • Device abstraction service abstracts hardware resources such as sensors and actuators, and provides device access interfaces to atomic services.
  • Device abstraction services generally encapsulate electrical signals, such as motor power supply signals, Hall signals, etc.
  • the communication method provided by the embodiment of this application applies for a certificate associated with the vehicle identity (such as VIN) for each layer 0 device and layer 1 device during the vehicle generation stage to ensure that the device is uniquely associated with the vehicle in which it is located. Furthermore, a device trust table is issued for each device based on the device's certificate to ensure that only legitimate devices can access.
  • the layer 0 device forms a layer 0 device trust ring based on the trust table, as shown in Figure 12.
  • Each device on the ring can provide different services to outside the ring.
  • the layer 0 device trust ring can provide a vehicle integration unit. (vehicle integration unit, VIU) atomic service, VDC enhanced service, MDC enhanced service, etc.
  • Layer 0 devices can further assist layer 1 devices and layer 2 devices in establishing a trust ring between layer 1 devices and a trust ring between layer 2 devices respectively. In some possible implementations, layer 0 devices can also assist the vehicle's external devices in establishing a trust ring. Furthermore, when the device is started, the legitimacy of the device is verified through the device certificate and trust table. After the verification is passed, the session key is distributed and the session key is refreshed regularly to improve the security of the session key. When business requires secure communication, use session keys to establish secure communication and ensure the confidentiality and integrity of communication data. In the communication method provided by the embodiment of the present application, the generated session key is closed-loop in the car, which can greatly reduce the risk of key leakage and reduce the complexity of key management.
  • Figure 13 shows a schematic flowchart of the communication method 1300 provided by the embodiment of the present application.
  • the method 1300 may be applied in the vehicle shown in FIG. 1 , or may be executed by the ZC in the system shown in FIG. 2 .
  • the method 1300 includes:
  • the first node receives a first message from the first device.
  • the first message includes second node information, and the second node information is used to indicate the second node.
  • the first node determines the second node based on the second node information
  • the first node generates a security key with the second node
  • S1340 The first node communicates with the second node according to the security key.
  • the first node can be any layer 0 device in the above embodiment, such as ZC1; the second node can be a layer 0 device in the above embodiment (such as ZC2), or it can also be a layer 0 device in the above embodiment.
  • a layer 1 device such as ECU1; the first node and the second node may be provided in a first terminal, and the first terminal may be the vehicle in the above embodiment, or may be other terminals.
  • the first message may be the signature trust table in the above embodiment, or may be a signature whitelist in other forms (such as a file, etc.) containing information about nodes that have communication requirements with the first node.
  • the second node information may include at least one of the second node's signature certificate ID, the second node's signature certificate, and the second node's public key hash in the above embodiment, or may also include other forms.
  • the public key information of the second node may include the public key hash of the second node.
  • the second node information also includes the identity information of the second node.
  • the identity information of the second node may be the SN code of the second node, or may be other information that can indicate the identity of the second node.
  • the first device may be the OEM PKI server in the above embodiment, or it may be the computing platform in the first terminal, such as at least one of VDC, MDC, CDC, or it may also be other trusted devices. , such as vehicle control server ICAS1, intelligent driving server ICAS2, infotainment server ICAS3, BDC, SAS, MGU, ADAS super core, CSC, etc.
  • vehicle control server ICAS1 intelligent driving server ICAS2, infotainment server ICAS3, BDC, SAS, MGU, ADAS super core, CSC, etc.
  • the security key may be the PSK in the above embodiment.
  • the method of generating the first message may refer to the description in the above embodiment, and will not be repeated here; the method of generating the security key between the first node and the second node may refer to the description in the above embodiment. Description will not be repeated here.
  • the first node communicates with the second node based on the security key, which may include: the first node generates a session key for communicating with the second node based on the security key, and then generates a session key for the second node based on the session key.
  • the communication content between the two nodes is encrypted.
  • method 1300 may also include other methods performed by layer 0 devices in FIG. 3 to FIG. 11 .
  • the embodiment of the present application provides a communication method that enables communication nodes to establish a mutual "trust relationship" through a first message. Furthermore, the communication nodes can verify the legitimacy of each other's identity through the first message. After the verification is passed, they negotiate a shared security key, and the shared security key can be used to generate a session key for each communication. When business requires secure communication, using session keys to establish secure communication helps ensure the confidentiality and integrity of communication data.
  • FIG. 14 shows a schematic flowchart of the communication method 1400 provided by the embodiment of the present application.
  • the method 1400 includes:
  • the second device receives the first message sent by the first device.
  • the first message includes second node information, and the second node information is used to indicate the second node.
  • the second device may be the OEM in the above embodiment, and more specifically, the second device may be the OEM TSP.
  • S1420 The second device sends the first message to the first node.
  • the second device sends the first message to the first node via the electrical inspection device.
  • method 1400 may also include other methods performed by OEM equipment in FIG. 3 to FIG. 11 .
  • the OEM sends a first message containing the information of the second node to the first node, so that a "trust relationship" is established between the first node and the second node, which helps the first node and the second node generates a session key based on the first message. Furthermore, when business requires secure communication, using session keys to establish secure communication helps ensure the confidentiality and integrity of communication data.
  • Figure 15 shows a schematic flowchart of the communication method 1500 provided by the embodiment of the present application.
  • the method 1500 includes:
  • the first device receives the second message sent by the second device
  • the second message may be the trust table in the above embodiment, or may be other forms of whitelists containing information about nodes that have communication requirements with the first node.
  • the second message is generated by the second device according to the communication list and the signature public key of the second node.
  • the first device signs the second message to generate a first message
  • the specific method of signing the second message to generate the first message may refer to the description in the above embodiment, and will not be described again here.
  • S1530 The first device sends the first message to the first node.
  • method 1500 may also include other methods performed by the OEM PKI server in Figures 3 to 11.
  • the first device generates a signature trust table by signing the trust table, so that the signature trust table cannot be easily changed by other devices, which helps to further improve communication security.
  • Figure 16 shows a schematic flow chart of the communication method 1600 provided by the embodiment of the present application.
  • the method 1600 includes:
  • the electrical inspection device receives the first message sent by the first device.
  • the first message includes second node information, and the second node information is used to indicate the second node.
  • the electrical inspection equipment may be the electrical inspection equipment in the above embodiment.
  • S1620 The electrical inspection equipment sends the first message to the first node.
  • the method 1600 may also include other methods performed by the electrical inspection equipment in FIG. 3 to FIG. 11 .
  • the electrical inspection equipment sends a first message containing the information of the second node to the first node, so that a "trust relationship" is established between the first node and the second node, which is helpful to the second node.
  • a node and a second node generate a session key based on the first message. Furthermore, when the business requires secure communication, using session keys for communication helps ensure the confidentiality and integrity of communication data.
  • Figure 17 shows a schematic flowchart of the communication method 1700 provided by the embodiment of the present application.
  • the method 1700 includes:
  • the first public key is generated by the first node according to the first message.
  • the first message includes second node information.
  • the second node information is used to indicate the second node. .
  • the second node generates a security key based on the first public key.
  • the security key is used for session encryption between the first node and the second node; or, the security key is used for the third node.
  • the session between the second node and the third node is encrypted.
  • the second node may be a layer 1 device that has communication requirements with the first node in the above embodiment
  • the third node may be a layer 1 device that has communication requirements with the second node in the above embodiment.
  • the first public key may be the first public key in the above embodiment, or may be the third public key or the fourth public key in the above embodiment.
  • the security key may be the shared key SS in the above embodiment.
  • method 1700 may also include other methods performed by layer 1 devices in FIG. 3 to FIG. 11 .
  • the layer 1 device can generate a security key based on the first public key sent by the layer 0 device.
  • the security key can be used to generate communication with the layer 0 device or the layer 1 device.
  • Required session key to help ensure confidentiality and integrity of communication data.
  • Figure 18 shows a schematic block diagram of a communication device 2000 provided by an embodiment of the present application.
  • the device 2000 includes a transceiver unit 2010 and a processing unit 2020.
  • the device 2000 may also include a storage unit, which may be used to store instructions and/or data, and the processing unit 2020 may read the instructions and/or data in the storage unit, so that the device implements the foregoing method embodiments. .
  • the apparatus 2000 may include means for performing the methods in Figures 13 to 17. Moreover, each unit in the device 2000 and the above-mentioned other operations and/or functions are respectively intended to implement the corresponding processes of the method embodiments in Figures 13 to 17.
  • the transceiver unit 2010 can be used to execute S1310 in the method 1300
  • the processing unit 2020 can be used to execute S1320 to S1340 in the method 1300.
  • the device 2000 includes: a transceiver unit 2010, configured to receive a first message from a first device, where the first message includes second node information, and the second node information is used to indicate the second node; a processing unit 2020, configured according to The second node information determines the second node; generates a security key with the second node; and communicates with the second node according to the security key.
  • a transceiver unit 2010, configured to receive a first message from a first device, where the first message includes second node information, and the second node information is used to indicate the second node
  • a processing unit 2020 configured according to The second node information determines the second node; generates a security key with the second node; and communicates with the second node according to the security key.
  • the processing unit 2020 is specifically configured to: when the second node stores first node information indicating the first node, the first node generates a security key according to the second node information. , the security key is used for session encryption between the first node and the second node.
  • the processing unit 2020 is also configured to: generate a first random number; and generate the security key according to the first random number and the second node information.
  • the processing unit 2020 is also configured to generate a second random number; generate a first public key according to the first random number; and the transceiver unit 2010 is also configured to send the third public key to the second node. Two random numbers and the first public key; receiving a first encrypted value, the first encrypted value is obtained by the second node encrypting the second random number according to the first security key, the first security key is based on The secret key of the second node and the public key of the first key are generated; the processing unit 2020 is also used to decrypt the first encrypted value according to the security key; when the first encrypted value is successfully decrypted, store the security key.
  • the processing unit 2020 is also configured to: generate a third random number; generate a second public key according to the third random number; the transceiver unit 2010 is also configured to send a message to the second node according to the third random number.
  • the first signature generated by the private key of the first node and the public key of the second key; receiving the second signature, which is based on the private key of the second node after the second node successfully verifies the first signature.
  • the third key public key is generated based on the fourth random number generated by the second node; the processing unit is also used to verify the second signature based on the second node information. ; When the verification of the second signature is successful, the first node generates the security key based on the third public key and the third random number.
  • the transceiver unit 2010 is further configured to: receive third node information indicating a third node and information indicating that the second node and the third node need to communicate from the first device. ;
  • the processing unit 2020 is also configured to generate a fifth random number; generate a fourth public key according to the fifth random number and the second node information; generate a fifth secret key according to the fifth random number and the third node information.
  • the transceiver unit 2010 is also configured to send the fifth public key to the second node; and send the fourth public key to the third node.
  • the transceiver unit 2010 is also configured to: before receiving the first message, send the signature public key of the first node to the second device, and the signature public key of the first node is used to generate the third message. A message.
  • the second node information includes public key information of the second node.
  • the public key information of the second node includes at least one of the following: the public key signature certificate of the second node; the public key signature certificate identification number ID of the second node; the second node The hash value of the public key and the identity information of the second node.
  • the transceiver unit 2010 is further configured to: receive service information of the second node from the first device, where the service information of the second node is used to indicate the second node that the first node can access. Services in the node.
  • the security key includes at least one of the following: a pre-shared key, a diagnostic key, a secure vehicle communication SecOC key, and other application keys.
  • the processing unit 2020 is also used to: generate a trust token; the transceiver unit 2010 is also used to send the trust token to the fourth node; the processing unit 2020 is also used to generate a sixth random number ; Generate a second security key according to the trust token and the sixth random number; the transceiver unit 2010 is also used to send the second security key encrypted by the trust token to the fourth node, so that the fourth node The node decrypts the trust token stored in advance to obtain the second security key.
  • the second security key is used for session encryption between the first node and the fourth node.
  • the processing unit 2020 is also configured to: before the transceiver unit 2010 sends the trust token to the fourth node, according to the authentication code SN, physical fingerprint, authentication chip, security chip of the fourth node, At least one of the four nodes authenticates the fourth node; the transceiver unit 2010 is specifically configured to: when the authentication is successful, send the trust token to the fourth node.
  • the processing unit 2020 is also configured to: perform identity authentication on the fourth node based on the second security key; and delete the trust token when the identity authentication passes.
  • the apparatus 2000 can also be used to perform the method in Figure 14.
  • the transceiving unit 2010 can be used to perform S1410 and S1420 in the method 1400.
  • the device 2000 includes: a transceiver unit 2010, configured to receive a first message sent by a first device, where the first message includes second node information, and the second node information is used to indicate the second node; sending to the first node The first news.
  • the apparatus 2000 further includes a processing unit configured to: before the transceiver unit receives the first message sent by the first device, generate a second message according to the communication list and the signature public key of the second node. , the communication list is used to indicate that the first node and the second node need to communicate; the transceiver unit 2010 is also used to send the second message to the first device.
  • the apparatus 2000 can also be used to perform the method in Figure 15.
  • the transceiving unit 2010 can be used to perform S1510 and S1530 in the method 1500
  • the processing unit 2020 can be used to perform S1520 in the method 1500.
  • the device 2000 includes: a transceiver unit 2010, used to receive a second message sent by a second device; a processing unit 2020, used to sign the second message to generate a first message; the transceiver unit 2010 is also used to send a message to the first node. Send the first message.
  • the apparatus 2000 can also be used to perform the method in Figure 16.
  • the transceiver unit 2010 can be used to perform S1610 and S1620 in the method 1600.
  • the device 2000 includes: a transceiver unit 2010, configured to receive a first message sent by a first device, where the first message includes second node information, and the second node information is used to indicate the second node; sending to the first node The first news.
  • the transceiver unit 2010 is also configured to: receive the signature public key of the first node sent by the third device; and send the signature public key of the first node to the first node.
  • the apparatus 2000 can also be used to perform the method in Figure 17.
  • the transceiver unit 2010 can be used to execute S1710 in the method 1700
  • the processing unit 2020 can be used to execute S1720 in the method 1700.
  • the device 2000 includes: a transceiver unit 2010, configured to receive a first public key generated by a first node according to a first message, the first message including second node information, and the second public key.
  • the node information is used to indicate the second node;
  • the processing unit 2020 is used to generate a security key based on the first public key, and the security key is used for session encryption between the first node and the second node; Alternatively, the security key is used for session encryption between the second node and the third node.
  • the first public key is a public key signed using the private key of the first node
  • the processing unit 2020 is further configured to: determine the first node according to the first message the public key of the first node; verify the first public key according to the public key of the first node; generate a fifth random number; when the verification is successful, generate a security key based on the first public key and the fifth random number .
  • each unit in the above device is only a division of logical functions.
  • the units may be fully or partially integrated into a physical entity, or may be physically separated.
  • the unit in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, instructions are stored in the memory, and the processor calls the instructions stored in the memory to implement any of the above methods.
  • the processor is, for example, a general-purpose processor, such as a CPU or a microprocessor
  • the memory is a memory within the device or a memory outside the device.
  • the units in the device can be implemented in the form of hardware circuits, and some or all of the functions of the units can be implemented through the design of the hardware circuits, which can be understood as one or more processors; for example, in one implementation,
  • the hardware circuit is an ASIC, which realizes the functions of some or all of the above units through the design of the logical relationship of the components in the circuit; for another example, in another implementation, the hardware circuit can be implemented through PLD, taking FPGA as an example. It can include a large number of logic gate circuits, and the connection relationships between the logic gate circuits can be configured through configuration files to realize the functions of some or all of the above units. All units of the above device may be fully realized by the processor calling software, or may be fully realized by hardware circuits, or part of the units may be realized by the processor calling software, and the remaining part may be realized by hardware circuits.
  • the processor is a circuit with signal processing capabilities.
  • the processor may be a circuit with instruction reading and execution capabilities, such as a CPU, a microprocessor, a GPU, or DSP, etc.; in another implementation, the processor can realize certain functions through the logical relationship of the hardware circuit. The logical relationship of the hardware circuit is fixed or can be reconstructed.
  • the processor is a hardware circuit implemented by ASIC or PLD. For example, FPGA.
  • the process of the processor loading the configuration file and realizing the hardware circuit configuration can be understood as the process of the processor loading instructions to realize the functions of some or all of the above units.
  • it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as NPU, TPU, DPU, etc.
  • each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA , or a combination of at least two of these processor forms.
  • processors or processing circuits
  • each unit in the above device may be integrated together in whole or in part, or may be implemented independently. In one implementation, these units are integrated together and implemented as a system-on-a-chip (SOC).
  • SOC may include at least one processor for implementing any of the above methods or implementing the functions of each unit of the device.
  • the at least one processor may be of different types, such as a CPU and an FPGA, or a CPU and an artificial intelligence processor. CPU and GPU etc.
  • FIG. 19 is a schematic block diagram of a communication device according to an embodiment of the present application.
  • the communication device 2100 shown in FIG. 19 may include: a processor 2110, a transceiver 2120, and a memory 2130.
  • the processor 2110, the transceiver 2120 and the memory 2130 are connected through an internal connection path.
  • the memory 2130 is used to store instructions.
  • the processor 2110 is used to execute the instructions stored in the memory 2130, and the transceiver 2120 receives/sends some parameters.
  • the memory 2130 can be coupled with the processor 2110 through an interface or integrated with the processor 2110 .
  • transceiver 2120 may include but is not limited to a transceiver device such as an input/output interface to realize communication between the device 2100 and other devices or communication networks.
  • each step of the above method can be completed by instructions in the form of hardware integrated logic circuits or software in the processor 2110 .
  • the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware processor for execution, or can be executed by a combination of hardware and software modules in the processor.
  • the software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field.
  • the storage medium is located in the memory 2130.
  • the processor 2110 reads the information in the memory 2130 and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.
  • the processor 2110 can use a general-purpose CPU, microprocessor, ASIC, GPU or one or more integrated circuits to execute relevant programs to implement the communication method of the method embodiment of the present application.
  • the processor 2110 may also be an integrated circuit chip with signal processing capabilities.
  • each step of the communication method of the present application can be completed by instructions in the form of hardware integrated logic circuits or software in the processor 2110 .
  • the above-mentioned processor 2110 can also be a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component.
  • Each method, step and logical block diagram disclosed in the embodiment of this application can be implemented or executed.
  • a general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.
  • the steps of the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field.
  • the storage medium is located in the memory 2130.
  • the processor 2110 reads the information in the memory 2130 and executes the communication method of the method embodiment of the present application in combination with its hardware.
  • the memory 2130 may be a read-only memory (ROM), a static storage device, a dynamic storage device or a random access memory (RAM).
  • ROM read-only memory
  • RAM random access memory
  • the transceiver 2120 uses a transceiver device such as but not limited to a transceiver to implement communication between the device 2100 and other devices or communication networks.
  • An embodiment of the present application also provides a communication system, which includes the above device 2000 or the above device 2100.
  • the vehicle may include the above device 2000 or the above device 2100.
  • the vehicle may include the above-mentioned device 2000 (or the device 2100).
  • the terminal device may include the above device 2000 or the above device 2100.
  • the terminal device may include the above-mentioned device 2000 (or the device 2100).
  • Embodiments of the present application also provide a computer-readable medium.
  • the computer-readable medium stores program code.
  • the computer program code When the computer program code is run on a computer, it causes the computer to execute the methods in Figures 3 to 17. .
  • An embodiment of the present application also provides a chip, including: at least one processor and a memory.
  • the at least one processor is coupled to the memory and is used to read and execute instructions in the memory to execute the above-mentioned Figures 3 to 3. Method in Figure 17.
  • the size of the sequence numbers of the above-mentioned processes does not mean the order of execution.
  • the execution order of each process should be determined by its functions and internal logic, and should not be used in the embodiments of the present application.
  • the implementation process constitutes any limitation.
  • the disclosed systems, devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of the present application is essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application.
  • the aforementioned storage media include: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk and other media that can store program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供了一种通信方法、装置和系统，该方法可以包括：第一节点从第一设备接收第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；该第一节点根据该第二节点信息确定该第二节点；该第一节点生成与该第二节点之间的安全密钥；该第一节点根据该安全密钥与该第二节点进行通信。本申请提供的通信方法有助于在不引入外部连接的前提下，确保通信数据的机密性和完整性。

Description

通信方法、装置和系统 技术领域
本申请涉及安全领域，更具体地，涉及一种通信方法、装置和系统。
背景技术
电子控制单元(electronic control units，ECU)和/或电子控制模块(electronic control modules，ECM)是车辆电子设备中的嵌入式系统，用于控制车辆中的一个或多个电气系统或子系统。
车载控制单元需要相互通信以进行车辆操作。通信内容包括影响车辆安全的关键操作，操纵通信内容可能会导致严重后果，在最坏的情况下会剥夺车内用户或其他用户的生命。因此，常常需要为有通信需求的两个车载控制单元注入加密密钥，以使通信双方对通信内容进行加密，然而上述通信方法不够安全。
发明内容
本申请提供一种通信方法和装置，能够提高通信节点之间的通信安全。
第一方面，提供了一种通信方法，该方法可以由车辆中的控制单元或者控制模块执行；或者，也可以由用于车辆的控制单元或者控制模块的芯片或电路执行，本申请对此不作限定。
该方法可以包括：第一节点从第一设备接收第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；该第一节点根据该第二节点信息确定该第二节点；该第一节点生成与该第二节点之间的安全密钥；该第一节点根据该安全密钥与该第二节点进行通信。
在一些可能的实现方式中，第一节点从第一设备接收第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点并与该第二节点进行通信。
在一些可能的实现方式中，第一节点经由一个或多个设备接收第一设备发送的第一消息。例如，第一节点经由电检设备接收第一设备发送的第一消息。
在一些可能的实现方式中，第一节点和第二节点可以为第一终端中的节点。示例性地，第一终端可以为车辆，或者也可以为其他终端设备。
应理解，第一节点通过第一消息可以知道自己需要与哪些第二节点进行通信。
在一些可能的实现方式中，该第一节点可以为区域控制器(zone controllers，ZC)、远程通信单元(telecommunication unit，TCU)、车载信息娱乐(in-vehicle infotainment，IVI)、高级驾驶辅助系统(advanced driving assistant system，ADAS)等具备安全硬件的设备；第二节点可以为上述实施例中的ZC、TCU、IVI、ADAS等具备安全硬件的设备，或者也可以为电动助力转向(electric power steering，EPS)、电动驻车制动(electric parking brake，EPB)等具备安全硬件的设备。示例性地，第一节点和第二节点之间可以通过以太 网电缆连接，或者也可以通过控制器局域网-柔性数据(controller area network–flexible data，CAN-FD)电缆连接。
在一些可能的实现方式中，第一节点可以为0层设备，第二节点可以为0层设备或1层设备。
在一些可能的实现方式中，第一消息中还可以包括第一终端的身份识别信息，该第一终端的身份识别信可以为车辆识别号(vehicle identification number，VIN)，或者也可以为其他能够指示第一终端身份的信息，本申请对此不作具体限定。
应理解，第一节点和第二节点也可以为终端设备中其他需要通信的组件。
在一些可能的实现方式中，该第一消息可以为签名信任凭据，该签名信任凭据的形式可以为表格，或者也可以为文件(file)，或者还可以为其他形式，本申请实施例对此不作具体限定。
在一些可能的实现方式中，该第一设备可以为OEM PKI服务器，或者也可以为第一终端中的计算平台，例如车辆域控制器(vehicle domain controller，VDC)、移动数据中心(mobiledatacenter，MDC)、底盘域控制器(chassis domain controller，CDC)中的至少一个；或者还可以为其他可信任设备，例如车辆控制服务器ICAS1、智能驾驶服务器ICAS2、信息娱乐服务器ICAS3、车身控制器(body domain controller，BDC)，特殊装备系统(special equipment system，SAS)、媒体图形单元(media graphics unit，MGU)、车身超级核心(body super core，BSC)，ADAS超级核心(ADAS super core)，驾驶舱超级核心(cockpit super core，CSC)等。
在一些可能的实现方式中，第一节点可以为替换原第一节点的节点，和/或第二节点可以为替换原第二节点的节点。或者，第一节点也可以为准备替换原第一节点的节点，和/或第二节点也可以为准备替换原第二节点的节点。
在上述技术方案中，第一节点可以基于包含第二节点信息的第一消息与第二节点之间建立相互的“信任关系”。进一步地，第一节点可以通过第一消息验证第二节点身份的合法性，验证通过后，与第二节点协商共享安全密钥。进一步地，第一节点和第二节点之间可以使用共享安全密钥为每次通信生成会话密钥。在业务需要安全通信时，使用该会话密钥对通信内容进行加密，建立安全通信，有助于确保通信数据的机密性和完整性。
结合第一方面，在第一方面的某些实现方式中，该第一节点生成与该第二节点之间的安全密钥，包括：在该第二节点保存有该用于指示该第一节点的第一节点信息时，该第一节点根据该第二节点信息生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密。
应理解，第一节点信息用于指示第二节点与第一节点进行通信，和/或第一节点信息包括第一节点的公钥信息。
在一些可能的实现方式中，“该第一节点根据该第二节点信息生成安全密钥”可以理解为第一节点根据该第二节点信息确认与第二节点之间存在通信需求，进一步地，第一节点生成一个随机数，并且接收第二节点发送的临时公钥，进而根据该临时公钥和自己生成的随机数生成该安全密钥。其中，第二节点发送的临时公钥是第二节点根据其自己生成的随机数生成的。
应理解，对应地，第二节点基于第一节点的公钥信息生成与第一节点生成的安全密钥相同的密钥。
示例性地，第一节点和第二节点生成安全密钥的方法可以为Diffie-Hellman密钥交换协议，或者也可以为其他预共享密钥计算技术，本申请对此不作具体限定。
示例性地，该安全密钥可以存储在第一节点的安全硬件中，以避免未经授权的访问或篡改。
在一些可能的实现方式中，第一节点也可以使用标准TLS解决方案验证第二节点的身份并计算安全密钥。例如，TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA可用于此目的。
在上述技术方案中，第一节点和第二节点之间基于第一消息和对方的公钥信息协商出安全密钥，基于安全密钥进行通信，大幅提高安全连接的协商性能。还能够降低安全密钥泄漏风险，减少安全密钥管理复杂度。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点生成第一随机数；该第一节点生成与该第二节点之间的安全密钥，包括：该第一节点根据该第一随机数和该第二节点信息生成该安全密钥。
在一些可能的实现方式中，第一节点生成第一随机数之前，先节点根据第一消息(或第二节点信息)确认第一节点与第二节点存在通信需求，进而针对第二节点生成第一随机数，例如v1。
示例性地，第二节点信息用于指示第二节点的公钥G^s1的信息，则第一节点根据随机数v1和G^s1生成该安全密钥。
在一些可能的实现方式中，第二节点不知道自己需要和哪些节点进行通信。例如，第二节点为没有保存第一节点信息的1层设备。
在一些可能的实现方式中，第一节点根据第一随机数生成第一密钥公钥，例如G^v1。应理解，对应地，第二节点基于第一密钥公钥G^v1和自己的私钥s1生成与第一节点生成的安全密钥相同的密钥。
示例性地，该安全密钥可以存储在第一节点的安全硬件中，以避免未经授权的访问或篡改。
在上述技术方案中，0层设备和1层设备之间基于第一消息和对方的公钥信息协商出安全密钥，基于该安全密钥进行通信，大幅提高安全连接的协商性能。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点生成第二随机数；该第一节点根据该第一随机数生成第一密钥公钥；该第一节点向该第二节点发送该第二随机数和该第一密钥公钥；该第一节点接收第一加密值，该第一加密值是该第二节点根据第一安全密钥加密该第二随机数获得，该第一安全密钥是根据该第二节点的秘钥和该第一密钥公钥生成的；该第一节点根据该安全密钥对该第一加密值解密；在对该第一加密值解密成功时，该第一节点存储该安全密钥。
示例性地，该第二随机数可以为Nonce值，或者也可以为其他随机数，本申请对此不作具体限定。
应理解，在第一节点根据安全密钥对第一加密值解密成功时，完成对第二节点的身份认证，此时可以认为第二节点是第一消息指示的合法节点。
应理解，在对该第一加密值解密成功时，证明第一节点生成的安全密钥与第二节点生成的第一安全密钥相同。
在一些可能的实现方式中，第二节点也可以采用上述方法对第一节点的身份进行认证， 认证成功后，存储安全密钥。
在上述技术方案中，对第二节点进行身份认证，能够进一步保证通信安全性。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点生成第三随机数；该第一节点根据该第三随机数生成第二密钥公钥；该第一节点向该第二节点发送根据该第一节点的私钥和该第二密钥公钥生成的第一签名；该第一节点接收第二签名，该第二签名是该第二节点对该第一签名验证成功后，根据该第二节点的私钥和第三密钥公钥生成的，该第三密钥公钥是根据该第二节点生成的第四随机数生成的；该第一节点根据该第二节点信息验证该第二签名；该第一节点生成与该第二节点之间的安全密钥，包括：在对该第二签名验证成功时，该第一节点根据该第三密钥公钥和该第三随机数生成该安全密钥。
在一些可能的实现方式中，第二节点保存有第一节点信息，示例性地，该第一节点信息包括第一节点的公钥信息，则对应地，第二节点可以根据第一签名和第四随机数计算与第一节点根据该第三密钥公钥和该第三随机数生成的安全密钥相同的安全密钥。
在上述技术方案中，提供了一种1层设备保存有0层设备的公钥信息时，1层设备和0层设备之间生成安全密钥的方法，有助于保证1层设备和0层设备之间的通信安全。
结合第一方面，在第一方面的某些实现方式中，该第一节点从该第一设备接收用于指示第三节点的第三节点信息和用于指示该第二节点和该第三节点需要通信的信息；该第一节点生成第五随机数；该第一节点根据该第五随机数和该第二节点信息生成第四密钥公钥；该第一节点根据该第五随机数和该第三节点信息生成第五密钥公钥；该第一节点向该第二节点发送该第五密钥公钥；该第一节点向该第三节点发送该第四密钥公钥。
在一些可能的实现方式中，第三节点信息和用于指示该第二节点和该第三节点需要通信的信息可以包含于第一消息中；或者第三节点信息和用于指示该第二节点和该第三节点需要通信的信息也可以与第一消息分别发送，本申请实施例对此不作具体限定。
示例性地，第二节点和第三节点可以均为第一终端中的1层设备。
应理解，由于第二节点和第三节点无法获知自己可以和哪些1层设备通信，因此需要借助第一节点协助第二节点和第三节点生成它们之间通信所需的安全密钥。
进一步地，第二节点可以根据自己的私钥和第五密钥公钥生成安全密钥；第三节点可以根据自己的私钥和第四密钥公钥生成安全密钥，二者生成的安全密钥相同。
在上述技术方案中，第一节点能够协助其他节点生成通信所需的安全密钥，无需外部注入密钥，使得密钥在第一终端中闭环，能够大幅降低密钥泄漏风险，减少密钥管理复杂度。
结合第一方面，在第一方面的某些实现方式中，该第一节点接收第一消息之前，该方法还包括：该第一节点向第二设备发送该第一节点的签名公钥，该第一节点的签名公钥用于生成该第一消息。
示例性地，该第二设备可以为OEM TSP，或者也可以为OEM的其他能够生成信任凭据的节点或设备。
在一些可能的实现方式中，该第二设备可以为电检设备。
在一些可能的实现方式中，第一节点的签名公钥是由OEM PKI服务器签名，且由OEM TSP转发的，则OEM TSP保存有第一节点的签名公钥，此时，第一节点无需向OEM TSP(经由电检设备)发送第一节点的签名公钥。
在一些可能的实现方式中，第一签名证书是由设备商签发的，则OEM TSP未保存第一节点的第一节点的签名公钥，此时，需要第一节点向OEMTSP(经由电检设备)发送第一节点的签名公钥，以便OEMTSP根据第一节点的签名公钥生成第一消息。
结合第一方面，在第一方面的某些实现方式中，该第二节点信息包括该第二节点的公钥信息。
结合第一方面，在第一方面的某些实现方式中，该第二节点的公钥信息包括如下至少一项：该第二节点的公钥签名证书；该第二节点的公钥签名证书身份识别号ID；该第二节点的公钥的哈希值和该第二节点的身份信息。
在上述技术方案中，在该公钥信息为公钥的签名证书身份识别号ID时，能够降低存储公钥信息所需开销。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点从该第一设备接收该第二节点的服务信息，该第二节点的服务信息用于指示该第一节点可以访问的该第二节点中的服务。
示例性地，第二节点支持服务A、服务B、服务C和服务D，但是第二节点只向允许第一节点访问服务A和服务B，则第二节点的服务信息中可以包含服务A和服务B的信息，以指示第一节点访问其服务A和服务B。应理解，在上述情况下，第一节点无法访问第二节点的服务C和服务D。
一示例，上述服务A至服务D可以分别为：空调服务、车门控制服务、刹车控制服务和转向控制服务。
在一些可能的实现方式中，该第二节点的服务信息可以包含于第一消息中。
在一些可能的实现方式中，在第一消息为签名信任凭据时，该第二节点的服务信息与签名信任凭据可以分开发送。
在上述技术方案中，能够在第一节点和第二节点通信的基础上，构造更细粒度的访问控制，使得第一节点只能访问第二节点的部分服务，在遭受攻击时，能够保证第二节点剩余服务的内容不会遭致泄露，进一步提高通信安全。将第二节点的服务信息与签名信任凭据分开管理，便于节点更换时的信息更新，例如，使用新的第二节点替换原第二节点，可以只更新包含第二节点信息的签名信任凭据，而无需更新第二节点的服务信息。
结合第一方面，在第一方面的某些实现方式中，该安全密钥包括如下至少一个：预共享密钥、诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥。
在上述技术方案中，预共享密钥、诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥等均为基于第二节点信息生成的，无需外部“灌装”密钥，使得安全密钥能够在第一终端内部形成闭环，便于密钥管理，降低密钥泄露风险。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点生成信任令牌；该第一节点向第四节点发送该信任令牌；该第一节点生成第六随机数；该第一节点根据该信任令牌和该第六随机数生成第二安全密钥；该第一节点向该第四节点发送经过信任令牌加密过的第二安全密钥，以使得该第四节点根据其预先存储的该信任令牌进行解密得到该第二安全密钥，该第二安全密钥用于该第一节点和该第四节点之间的会话加密。
在一些可能的实现方式中，该第六随机数可以为Nonce值，或者也可以其他随机数。
示例性地，第四节点可以为2层设备，或者也可以为其他没有安全硬件的设备。
在上述技术方案中，第一节点可以为第四节点生成二者之间通信所需安全密钥，无需 外部密钥的“灌装”，防止外部连接对第一终端的安全产生威胁。
结合第一方面，在第一方面的某些实现方式中，该第一节点向第四节点发送该信任令牌之前，该方法还包括：该第一节点根据该第四节点的认证码SN、物理指纹、认证芯片、安全芯片中的至少一个对该第四节点进行认证；该第一节点向第四节点发送该信任令牌，包括：在认证成功时，该第一节点向该第四节点发送该信任令牌。
在上述技术方案中，对第四节点进行身份认证，能够进一步保证通信安全性。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第一节点基于该第二安全密钥对该第四节点进行身份认证；在该身份认证通过时，该第一节点删除该信任令牌。
在上述技术方案中，删除信任令牌，能够防止外部入侵者盗取信任令牌造成安全威胁。
第二方面，提供了一种通信方法，该方法可以包括：第二设备接收第一设备发送的第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；该第二设备向该第一节点发送该第一消息。
示例性地，该第二设备可以为OEM TSP，或者也可以为OEM的其他能够生成信任凭据的节点或设备；或者，该第二设备也可以为电检设备。
在一些可能的实现方式中，在第二设备为OEM TSP等OEM设备时，第二设备可以直接接收第一设备发送的第一消息，进一步地，第二设备向电检设备发送该第一消息，电检设备将该第一消息发送至第一节点。
在一些可能的实现方式中，在第二设备为电检设备时，第二设备可以通过OEM TSP等OEM设备接收第一设备发送的第一消息，进一步地，第二设备直接向第一节点发送该第一消息。
在一些可能的实现方式中，第二设备直接接收第一设备发送的第一消息，并直接向第一节点发送该第一消息。
需要说明的是，上述“直接接收”、“直接向……发送”可以理解为不经其他设备转发的接收或发送。
在上述技术方案中，OEM或电检设备通过向第一节点发送包含第二节点信息的第一消息，使得第一节点和第二节点之间建立“信任关系”，有助于第一节点和第二节点基于该第一消息生成会话密钥。进一步地，在业务需要安全通信时，使用会话密钥，通信，有助于确保通信数据的机密性和完整性。
结合第二方面，在第二方面的某些实现方式中，该第二设备接收第一设备发送的第一消息之前，该方法还包括：该第二设备根据通信列表和该第二节点的签名公钥生成第二消息，该通信列表用于指示该第一节点和该第二节点需要进行通信；该第二设备向该第一设备发送该第二消息。
示例性地，该方法可以由OEM TSP执行，或者也可以由OEM的其他能够生成信任凭据的节点或设备执行。
示例性地，通信列表可以为列表形式，或者也可以为矩阵形式，该通信列表用于指示第一终端中各节点之间的通信关系，该通信列表也可以为其他形式，本申请对此不作具体限定。
示例性地，该第二消息可以为未签名的信任凭据。在一些可能的实现方式中，该信任凭据可以为与第一节点通信的其他节点的白名单，该信任凭据包括与第一节点通信的其他 节点的公钥信息。
在上述技术方案中，OEM的设备可以生成第二消息，以使得第一设备对第二消息签名生成第一消息，有助于使得第一终端中的节点之间基于该第一消息建立“信任关系”。
结合第二方面，在第二方面的某些实现方式中，该第二设备为电检设备，该方法还包括：该第二设备接收第三设备发送的第一节点的签名公钥；该第二设备向该第一节点发送该第一节点的签名公钥。
在一些可能的实现方式中，第一设备和第三设备可以为同一设备，例如，均为OEM PKI服务器；或者，第一设备和第三设备也可以为不同的设备，例如第一设备为OEM PKI服务器，第三设备为设备商服务器。
需要说明的是，在第三设备与第一设备不同时，电检设备接收第一设备发送的第一消息之前，还需从第一节点处获取该第一节点的签名公钥。
在上述技术方案中，电检设备通过向第一节点发送第一节点的签名公钥，方便后续基于第一节点的签名公钥的第一消息的生成和使用。
第三方面，提供了一种通信方法，该方法可以包括：第一设备接收第二设备发送的第二消息；该第一设备对该第二消息进行签名生成第一消息；该第一设备向第一节点发送该第一消息。
在上述技术方案中，第一设备通过对信任表进行签名生成签名信任表，使得签名信任表无法轻易地被其他设备更改，有助于进一步提高通信安全性。
第四方面，提供了一种通信方法，该方法可以由车辆(或者其他终端)中的控制单元或者控制模块执行；或者，也可以由用于车辆(或者其他终端)的控制单元或者控制模块的芯片或电路执行，本申请对此不作限定。
该方法可以包括：第二节点接收第一密钥公钥，该第一密钥公钥是由第一节点根据第一消息生成，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；该第二节点根据该第一密钥公钥生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密；或者，该安全密钥用于该第二节点和第三节点之间的会话加密。
示例性地，第二节点可以为1层设备。
示例性地，第三节点可以为与第二节点具有通信需求的1层设备。
示例性地，在借助第一节点生成第二节点和第三节点之间的会话密钥时，“该第一密钥公钥是由第一节点根据第一消息生成”，具体可以为：该第一密钥公钥是第一节点根据第一消息确定第二节点和第三节点需要进行通信的前提下，由第一节点根据第一随机数和第三节点的公钥生成。“该第二节点根据该第一密钥公钥生成安全密钥”可以为：该第二节点根据第一密钥公钥和该第二节点的私钥生成安全密钥。应理解，在上述情况下，该安全密钥用于第二节点和第三节点之间的会话加密。
示例性地，在生成第一节点和第二节点之间的会话密钥时，在第二节点未保存第一节点信息时，“该第二节点根据该第一密钥公钥生成安全密钥”，可以为：该第二节点根据第一密钥公钥和该第二节点的私钥生成安全密钥；或者，在第二节点保存有第一节点信息时，“该第二节点根据该第一密钥公钥生成第二安全密钥”，还可以为：该第二节点根据第一密钥公钥和第二节点根据第二签名信任凭据生成的随机数生成安全密钥。应理解，在上述情况下，该第二安全密钥用于第一节点和第二节点之间的会话加密。
在上述技术方案中，第二节点可以基于第一节点发送的第一密钥公钥生成安全密钥， 该安全密钥可以用于生成与第一节点或第三节点进行通信所需的会话密钥，无需外部“灌装”密钥，有助于提高第一终端内部密钥安全性。
结合第四方面，在第四方面的某些实现方式中，该第一密钥公钥为使用该第一节点的私钥签名后的密钥公钥，该方法还包括：该第二节点根据该第一消息确定该第一节点的公钥；该第二节点根据该第一节点的公钥验证该第一密钥公钥；该第二节点生成第五随机数；该第二节点根据该第一密钥公钥生成安全密钥，包括：在验证成功时，该第二节点根据该第一密钥公钥和该第五随机数生成安全密钥。
示例性地，该第一密钥公钥可以为上述第一方面中的第一签名。
在上述技术方案中，第二节点和第一节点之间可以基于第一消息和对方的公钥信息协商出安全密钥，使用安全密钥通信，大幅提高安全连接的协商性能。还能够降低安全密钥泄漏风险，减少安全密钥管理复杂度。
第五方面，提供了一种第一节点，该第一节点包括：收发单元，用于从第一设备接收第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；处理单元，用于根据该第二节点信息确定该第二节点；生成与该第二节点之间的安全密钥；根据该安全密钥与该第二节点进行通信。
结合第五方面，在第五方面的某些实现方式中，该处理单元具体用于：在该第二节点保存有用于指示该第一节点的第一节点信息时，该第一节点根据该第二节点信息生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密。
结合第五方面，在第五方面的某些实现方式中，该处理单元还用于：生成第一随机数；根据该第一随机数和该第二节点信息生成该安全密钥。
结合第五方面，在第五方面的某些实现方式中，该处理单元还用于生成第二随机数；根据该第一随机数生成第一密钥公钥；该收发单元还用于向该第二节点发送该第二随机数和该第一密钥公钥；接收第一加密值，该第一加密值是该第二节点根据第一安全密钥加密该第二随机数获得，该第一安全密钥是根据该第二节点的秘钥和该第一密钥公钥生成的；该处理单元还用于根据该安全密钥对该第一加密值解密；在对该第一加密值解密成功时，存储该安全密钥。
结合第五方面，在第五方面的某些实现方式中，处理单元还用于：生成第三随机数；根据该第三随机数生成第二密钥公钥；该收发单元还用于向该第二节点发送根据该第一节点的私钥和该第二密钥公钥生成的第一签名；接收第二签名，该第二签名是该第二节点对该第一签名验证成功后，根据该第二节点的私钥和第三密钥公钥生成的，该第三密钥公钥是根据该第二节点生成的第四随机数生成的；该处理单元还用于根据该第二节点信息验证该第二签名；在对该第二签名验证成功时，该第一节点根据该第三密钥公钥和该第三随机数生成该安全密钥。
结合第五方面，在第五方面的某些实现方式中，该收发单元还用于：从该第一设备接收用于指示第三节点的第三节点信息和用于指示该第二节点和该第三节点需要通信的信息；该处理单元还用于生成第五随机数；根据该第五随机数和该第二节点信息生成第四密钥公钥；根据该第五随机数和该第三节点信息生成第五密钥公钥；该收发单元还用于向该第二节点发送该第五密钥公钥；向该第三节点发送该第四密钥公钥。
结合第五方面，在第五方面的某些实现方式中，该收发单元还用于：接收第一消息之前，向该第二设备发送该第一节点的签名公钥，该第一节点的签名公钥用于生成该第一消 息。
结合第五方面，在第五方面的某些实现方式中，该第二节点信息包括该第二节点的公钥信息。
结合第五方面，在第五方面的某些实现方式中，该第二节点的公钥信息包括如下至少一项：该第二节点的公钥签名证书；该第二节点的公钥签名证书身份识别号ID；该第二节点的公钥的哈希值和该第二节点的身份信息。
结合第五方面，在第五方面的某些实现方式中，该收发单元还用于：从该第一设备接收该第二节点的服务信息，该第二节点的服务信息用于指示该第一节点可以访问的该第二节点中的服务。
结合第五方面，在第五方面的某些实现方式中，该安全密钥包括如下至少一个：预共享密钥、诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥。
结合第五方面，在第五方面的某些实现方式中，该处理单元还用于：生成信任令牌；该收发单元还用于向第四节点发送该信任令牌；该处理单元还用于生成第六随机数；根据该信任令牌和该第六随机数生成第二安全密钥；该收发单元还用于向该第四节点发送经过信任令牌加密过的第二安全密钥，以使得该第四节点根据其预先存储的该信任令牌进行解密得到该第二安全密钥，该第二安全密钥用于该第一节点和该第四节点之间的会话加密。
结合第五方面，在第五方面的某些实现方式中，该处理单元还用于：该收发单元向第四节点发送该信任令牌之前，根据该第四节点的认证码SN、物理指纹、认证芯片、安全芯片中的至少一个对该第四节点进行认证；该收发单元具体用于：在认证成功时，向该第四节点发送该信任令牌。
结合第五方面，在第五方面的某些实现方式中，该处理单元还用于：基于该第二安全密钥对该第四节点进行身份认证；在该身份认证通过时，删除该信任令牌。
第六方面，提供了一种第二设备，该第二设备包括：收发单元，用于接收第一设备发送的第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；向该第一节点发送该第一消息。
结合第六方面，在第六方面的某些实现方式中，该第二设备还包括处理单元，用于：在该收发单元接收第一设备发送的第一消息之前，根据通信列表和该第二节点的签名公钥生成第二消息，该通信列表用于指示该第一节点和该第二节点需要进行通信；该收发单元还用于向该第一设备发送该第二消息。
结合第六方面，在第六方面的某些实现方式中，在该第二设备为电检设备时，该收发单元还用于：接收第三设备发送的第一节点的签名公钥；向该第一节点发送该第一节点的签名公钥。
第七方面，提供了一种第一设备，该第一设备包括：收发单元，用于接收第二设备发送的第二消息；处理单元，用于对该第二消息进行签名生成第一消息；该收发单元还用于向第一节点发送该第一消息。
第八方面，提供了一种第二节点，该第二节点包括：收发单元，用于接收第一密钥公钥，该第一密钥公钥是由第一节点根据第一消息生成，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；处理单元，用于根据该第一密钥公钥生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密；或者，该安全密钥用于该第二节点和第三节点之间的会话加密。
结合第八方面，在第八方面的某些实现方式中，该第一密钥公钥为使用该第一节点的私钥签名后的密钥公钥，该处理单元还用于：根据该第一消息确定该第一节点的公钥；根据该第一节点的公钥验证该第一密钥公钥；生成第五随机数；在验证成功时，根据该第一密钥公钥和该第五随机数生成安全密钥。
第九方面，提供了一种通信装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第一方面或第四方面中任一种可能实现方式中的方法。
第十方面，提供了一种通信装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第二方面或第三方面中任一种可能实现方式中的方法。
第十一方面，提供了一种通信系统，该系统上述第五方面任一种可能实现方式中的第一节点，和上述第八方面任一种可能实现方式中的第二节点。
结合第十一方面，在第十一方面中的某些实现方式中，该第一节点生成第一随机数，根据该第一随机数和第二节点信息生成安全密钥，其中该第二节点信息用于指示该第二节点；该第一节点根据该第一随机数生成第一密钥公钥；该第一节点向该第二节点发送该第一密钥公钥；该第二节点接收该第一密钥公钥，并根据该第二节点的私钥和该第一密钥公钥生成第一安全密钥，并根据该第一安全密钥加密该第二随机数获得第一加密值；该第二节点向该第一节点发送该第一加密值；该第一节点接收该第一加密值，并根据该安全密钥对该第一加密值解密，在该第一节点对该第一加密值解密成功时，该第一节点存储该安全密钥。
应理解，在该第一节点对该第一加密值解密成功时，证明第一安全密钥与安全密钥相同。
在一些可能的实现方式中，第二节点生成第一安全密钥后即存储第一安全密钥。或者，第一节点可以使用安全密钥加密第一随机数生成第二加密值，并发送给第二节点。进一步地，第二节点根据第一安全密钥对第二加密值解密成功后，存储第一安全密钥。
结合第十一方面，在第十一方面中的某些实现方式中，该第一节点生成第三随机数，并根据该第三随机数生成第二密钥公钥；该第一节点向该第二节点发送根据该第一节点的私钥和该第二密钥公钥生成的第一签名；该第二节点接收该第一签名，生成第四随机数，根据该第四随机数生成第三密钥公钥，在对该第一签名验证成功时，该第二节点根据该第二节点的私钥和第三密钥公钥生成第二签名，并向该第一节点发送该第二签名；该第二节点根据该第四随机数和该第二密钥公钥生成第三安全密钥；该第一节点接收第二签名，并根据该第二节点信息验证该第二签名，在对该第二签名验证成功时，根据该第三密钥公钥和该第三随机数生成该第四安全密钥。
应理解，该第三安全密钥与该第四安全密钥相同。
应理解，该第三安全密钥与第一方面中“第一节点根据第三密钥公钥和第三随机数生成”的安全密钥为同一安全密钥。
结合第十一方面，在第十一方面中的某些实现方式中，该系统还包括上述第八方面中的第一设备，该第二节点包括第一装置和第二装置；该第一节点从该第一设备接收用于指示第一装置的第一装置信息、用于指示第二装置的第二装置信息和用于指示该第一装置和该第二装置需要通信的信息；该第一节点生成第五随机数；该第一节点根据该第五随机数 和该第一装置信息生成第四密钥公钥；该第一节点根据该第五随机数和该第二装置信息生成第五密钥公钥；该第一节点向该第一装置发送该第五密钥公钥；该第一节点向该第二装置发送该第四密钥公钥；该第一装置接收该第五密钥公钥，并根据该第一装置的私钥和该第五密钥公钥生成第五安全密钥；该第二装置接收该第四密钥公钥，并根据该第二装置的私钥和该第四密钥公钥生成第六安全密钥。
应理解，该第五安全密钥与该第六安全密钥相同。
第十二方面，提供了一种车辆，该车辆包括上述第五方面任一种可能实现方式中的第一节点和/或第八方面中任一种可能实现方式中的第二节点。
应理解，本申请中的车辆(有时简称为车)为广义概念上的车辆，可以是交通工具(如：汽车，卡车，摩托车，火车，飞机，轮船等)，工业车辆(如：叉车，挂车，牵引车等)，工程车辆(如：挖掘机，推土机，吊车等)，农用设备(如割草机、收割机等)，游乐设备，玩具车辆等，本申请对车辆的类型不做限定。
第十三方面，提供了一种终端设备，该终端设备包括上述第六方面任一种可能实现方式中的第二设备和/或第七方面中任一种可能实现方式中的第一设备。
第十四方面，提供了一种计算机程序产品，上述计算机程序产品包括：计算机程序代码，当上述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面至第四方面中任一种可能实现方式中的方法。
需要说明的是，上述计算机程序代码可以全部或部分存储在第一存储介质上，其中第一存储介质可以与处理器封装在一起的，也可以与处理器单独封装，本申请实施例对此不作具体限定。
第十五方面，提供了一种计算机可读介质，上述计算机可读介质存储由程序代码，当上述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面至第四方面中任一种可能实现方式中的方法。
第十六方面，提供了一种芯片，该芯片包括处理器，用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述第一方面至第五方面中任一种可能实现方式中的方法。
结合第十六方面，在一种可能的实现方式中，该处理器通过接口与存储器耦合。
结合第十六方面，在一种可能的实现方式中，该芯片系统还包括存储器，该存储器中存储有计算机程序或计算机指令。
附图说明
图1是本申请实施例提供的车辆的功能性框图示意。
图2是本申请实施例提供的一种通信系统架构的示意图。
图3是本申请实施例提供的一种通信方法的示意性流程图。
图4是本申请实施例提供的一种通信方法的示意性流程图。
图5是本申请实施例提供的一种通信方法的示意性流程图。
图6是本申请实施例提供的一种通信方法的示意性流程图。
图7是本申请实施例提供的一种通信方法的示意性流程图。
图8是本申请实施例提供的一种通信方法的示意性流程图。
图9是本申请实施例提供的一种通信方法的示意性流程图。
图10是本申请实施例提供的一种通信方法的示意性流程图。
图11是本申请实施例提供的一种通信方法的示意性流程图。
图12是本申请实施例提供的一种通信方法应用场景的示意图。
图13是本申请实施例提供的一种通信方法的示意性流程图。
图14是本申请实施例提供的一种通信方法的示意性流程图。
图15是本申请实施例提供的一种通信方法的示意性流程图。
图16是本申请实施例提供的一种通信方法的示意性流程图。
图17是本申请实施例提供的一种通信方法的示意性流程图。
图18是本申请实施例提供的一种通信装置的示意性框图。
图19是本申请实施例提供的一种通信装置的又一示意性框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例中采用诸如“第一”、“第二”的前缀词，仅仅为了区分不同的描述对象，对被描述对象的位置、顺序、优先级、数量或内容等没有限定作用。本申请实施例中对序数词等用于区分描述对象的前缀词的使用不对所描述对象构成限制，对所描述对象的陈述参见权利要求或实施例中上下文的描述，不应因为使用这种前缀词而构成多余的限制。此外，在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
图1是本申请实施例提供的车辆100的一个功能框图示意。车辆100可以包括感知系统120、显示装置130和计算平台150，其中，感知系统120可以包括感测关于车辆100周边的环境的信息的若干种传感器。例如，感知系统120可以包括定位系统，定位系统可以是全球定位系统(global positioning system，GPS)，也可以是北斗系统或者其他定位系统、惯性测量单元(inertial measurement unit，IMU)、激光雷达、毫米波雷达、超声雷达以及摄像装置中的一种或者多种。
车辆100的部分或所有功能可以由计算平台150控制。计算平台150可包括处理器151至15n(n为正整数)，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如中央处理单元(central processing unit，CPU)、微处理器、图形处理器(graphics processing unit，GPU)(可以理解为一种微处理器)、或数字信号处理器(digital signal processor，DSP)等；在另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为专用集成电路(application-specific integrated circuit，ASIC)或可编程逻辑器件(programmable logic device，PLD)实现的硬件电路，例如现场可编辑逻辑门阵列(filed programmable gate array，FPGA)。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种ASIC，例如神经网络处理单元(neural network processing unit，NPU)、张量处理单元(tensor processing unit，TPU)、深度学习处理单元(deep learning processing unit，DPU)等。此 外，计算平台150还可以包括存储器，存储器用于存储指令，处理器151至15n中的部分或全部处理器可以调用存储器中的指令，执行指令，以实现相应的功能。
车辆100可以包括ADAS，ADAS利用感知系统120中的多种传感器(包括但不限于：激光雷达、毫米波雷达、摄像装置、超声波传感器、全球定位系统、惯性测量单元)从车辆周围获取信息，并对获取的信息进行分析和处理，实现例如障碍物感知、目标识别、车辆定位、路径规划、驾驶员监控/提醒等功能，从而提升车辆驾驶的安全性、自动化程度和舒适度。
图2示出本申请实施例提供的一种通信系统架构示意图。如图2所示，车载通信网络200包括0层设备、1层设备和2层设备。其中，0层设备包括ZC、TCU、IVI、ADAS等，通过以太网电缆相互连接。0层设备通常有安全的硬件，如硬件安全模块(hardware security module，HSM)、可信平台模块(trusted platform module，TPM)等，使得0层设备能够生成安全密钥并执行公钥加密操作。示例性地，生成的“安全密钥”包括但不限于预共享密钥(pre-shared key,PSK)、诊断密钥、安全车载通信(security onboard communication，SecOC)密钥和其他应用程序密钥。
1层设备通常通过CAN-FD电缆相互连接，以及通过CAN-FD与0层设备连接。1层设备包括EPS、EPB，还可以包括CDC等。1层可能具有安全硬件，如HSM、TPM等。
应理解，CAN-FD协议允许在控制器局域网(controller area network，CAN)帧数据部分传输64字节的数据，该部分数据远远小于以太网帧的有效负载。
2层设备是资源受限制的ECU设备，没有安全硬件，通过低带宽CAN总线相互连接。示例性地，2层设备的示例可以包括CAN ECU、传感器、执行器等。
应理解，通过非以太网连接的ECU(即1层设备和2层设备)没有可用于实现基于传输层安全(transport layer security，TLS)的安全性标准TLS密码套件。
需要说明的是，具有安全硬件但通过CAN总线连接的设备仍然可以执行轻量级公钥操作，在本申请实施例中可以被视为1层设备。不具备安全硬件，但通过CAN-FD连接的设备，由于无法执行公钥操作，在本申请实施例中仍被认为是资源受限制的2层设备。示例性地，“公钥操作”可以包括自主生成公私钥对的操作。
应理解，图2所示的各种设备只是一个示例，实际应用中，上述各个设备有可能根据实际需要增添或者删除。例如，可能有不同数量的具有不同名称的设备，或者它们可能在不同的车辆中以不同的拓扑相互连接。
如上所述，本申请根据其连接类型和处理能力将车载设备分为三类，即0层设备、1层设备和2层设备。本申请实施例中，针对每层提出了相应的解决方案，以建立各个车载设备之间的安全通信。
0层设备的安全通信：每个0层设备通过包含与之通信的其他0层设备信息的信任表，与上述其他0层设备之间建立“信任关系”。进一步地，基于签名证书的公钥加密技术，在0层设备之间建立设备身份验证机制和可信通信，以使得所有0层设备之间形成“信任环”，其中，来自信任环的任何一个设备都可以进一步帮助信任环上的其他设备进行身份验证和安全通信。
1层设备的安全通信：基于0层设备的信任表，建立0层设备与1层设备，以及1层设备与1层设备之间的“信任关系”，并基于上述信任关系在这些设备之间建立安全通信。
2层设备的安全通信：0层设备验证与2层设备的信任关系，并使用对称密钥加密操 作构建与2层设备之间的安全通信。
需要注意的是，具有安全硬件的ECU能够执行公钥加密操作(例如，椭圆曲线加密(elliptic curve cryptography，ECC))、安全密钥生成和存储等。
以下将结合图3至图16详细说明车载设备之间的通信方法。
图3示出了本申请实施例提供的一种的通信方法的示意性流程图，更具体地，图3示出了0层设备中生成密钥和签名证书的方法，本申请实施例以0层设备中的区域控制器ZC1为例进行说明。该方法可以包括：
S301，电检设备激活公钥/私钥生成。
示例性地，电检设备连接到0层设备时，激活0层设备的生成公钥/私钥对。
S302，ZC1生成第一公钥和第一私钥。
应理解，第一公钥和第一私钥形成一对密钥对。
示例性地，ZC1将在安全硬件内生成其私钥/公钥对，并将第一公钥(例如PK_ZC1)发送到电检设备，而将第一私钥保留在自己的安全硬件内。应理解，任何第三方都不能获取或篡改安全存储在安全硬件中的私钥。
S303，ZC1向电检设备发送第一公钥。
S304，电检设备将第一公钥发送到公钥基础设施(public key infrastructure，PKI)服务器。
可选地，电检设备和PKI服务器之间可以通过无线通信连接，例如互联网，或物联网等，本申请实施例对此不作具体限定。
S305，PKI服务器对第一公钥签名，生成包含第一公钥的第一签名证书。
示例性地，PKI服务器使用其自己的私钥对ZC1的第一公钥进行签名，生成一个签名证书(例如CERT_PK_ZC1)。应理解，该证书包含ZC1的公钥。
S306，PKI服务器将第一签名证书发送给电检设备。
S307，电检设备将第一签名证书发送给ZC1。
S308，ZC1保存第一签名证书。
需要说明的是，车载设备供应商(如ZC1的供应商)可以在设备生产期间执行图3所示的电检设备或PKI服务器执行的步骤，在这种情况下，电检设备可以是供应商的电检设备，进一步地，供应商的PKI服务器将签署第一签名证书。可选地，图3所述的方法也可以由车辆制造商(original equipment manufacturer，OEM)执行，在这种情况下，电检设备设备将是OEM的电检设备，OEM的PKI服务器将签署第一签名证书。
应理解，对于每个0层设备，都可以使用图3所示方法生成私钥/公钥对，并获得公钥的签名证书。
图4示出了本申请实施例提供的一种通信方法的示意性流程图，更具体地，图4示出了为0层设备之间生成信任表的方法，该方法可以包括：
S401，OEM电检设备向0层设备请求证书。
在一些可能的实现方式中，OEM电检设备可以分别连接到多个0层设备，并分别向每个0层设备(例如ZC1、ZC2和ZC3)请求签名证书。
S402，0层设备将签名证书发送给OEM电检设备。
示例性地，每个0层设备将其签名证书发送给OEM电检设备。例如，0层设备包括ZC1、ZC2和ZC3，则ZC1、ZC2和ZC3分别向电检设备发送其签名证书。例如，ZC1 向OEM电检设备发送签名证书CERT_PK_ZC1；ZC2向OEM电检设备发送签名证书CERT_PK_ZC2；ZC3向OEM电检设备发送签名证书CERT_PK_ZC3。
S403，OEM电检设备将签名证书发送给OEM。
示例性地，电检设备将所有签名证书发送给OEM。OEM电检设备可以将所有签名证书一次性发送给OEM，或者也可以分批次发送，例如每次发一个或多个签名证书，本申请实施例对此不作具体限定。
S404，OEM验证签名证书并根据签名证书为每个0层设备生成信任表。
在一些可能的实现方式中，OEM保存有一个通信矩阵，该通信矩阵包含用于指示哪个车载设备与另一个车载设备有通信需求的信息。需要说明的是，设备1与设备2存在通信需求可以指：在车辆运行过程中，设备1和设备2之间可能存在信令交互。在具体实现过程中，设备1和设备2并非一定通信或有信令交互。
进一步地，OEM根据通信矩阵和签名证书，为每个0层设备创建信任表。例如，OEM根据通信矩阵得知ZC1与ZC2、ZC3之间存在通信需求。因此，ZC1的信任表将包含ZC2和ZC3的公钥信息和VIN，应理解，该识别号对于每辆车都是全局唯一的。
一示例，ZC2和ZC3的信息可以是ZC2和ZC3的签名证书ID，例如，与ZC2的签名证书(CERT_PK_ZC2)对应的签名证书ID CertID_ZC2和与ZC3的签名证书(CERT_PK_ZC3)对应的签名证书ID CertID_ZC3。类似地，ZC2的信任表将具有ZC1的签名证书ID，以及在车辆运行期间需要进行通信的任何其他0层设备(如ZC4)。示例性地，ZC1和ZC2的信任表分别如表1和表2所示。
表1.ZC1的信任表。
VIN CertID_ZC2,CertID_ZC3,…
表2ZC2的信任表。
VIN CertID_ZC1,CertID_ZC4,…
又一示例，ZC2和ZC3的信息可以包括ZC2和ZC3的公钥哈希，即在ZC1的信任表中列出ZC2和ZC3的公钥哈希。
再一示例，ZC2和ZC3的信息可以包括ZC2和ZC3的签名证书，即在ZC1的信任表中包含ZC2和ZC3的签名证书。
在一些可能的实现方式中，一个设备信任表中还可以包含需要与其通信的设备的认证码(serial number，SN)，例如，ZC1的信任表中还可以包括ZC2的SN码和ZC3的SN码，ZC2的信任表中还可以包括ZC1的SN码和ZC4的SN码。
应理解，OEM将为该车辆的每个0层设备准备信任表，并将每个0层设备的信任表发送给OEM PKI服务器。
S405，OEM向OEM PKI服务器发送信任表。
示例性地，OEM可以将所有信任表一次性发送给OEM PKI服务器，或者也可以分批次发送，例如每次发一个或多个信任表，本申请实施例对此不作具体限定。
S406，OEM PKI服务器对信任表进行签名。
示例性地，OEM PKI服务器使用自己的私钥对每个信任表进行签名，生成多个签名 信任表。应理解，一个签名信任表与一个0层设备对应。
在一些可能的实现方式中，OEM PKI服务器可以将其公钥经由OEM和OEM电检设备发送给每个0层设备，以使得0层设备基于该公钥对签名信任表进行验证。
S407，OEM PKI服务器将多个签名信任表发送给OEM。
S408，OEM将签名信任表发送给OEM电检设备。
S409，OEM电检设备将签名信任表发送给0层设备。
应理解，OEM电检设备将签名信任表发送给对应的0层设备，例如，将签名的ZC1信任表发送给ZC1，将签名的ZC2信任表发送给ZC2。
S410，每个0层设备保存各自的签名信任表。
例如，签名的ZC1信任表将存储在ZC1中，以此类推。
应理解，本申请实施例中涉及的“OEM”可以为OEM的信任服务提供商(trust service provider，TSP)，或者，也可以为OEM的其他能够生成信任表的设备。
本申请实施例提供的通信方法中，0层设备的信任表由OEM PKI服务器签名，且外部设备无法更改这些签名信任表。因此，在签名绑定的帮助下，借助签名信任表，使得0层设备之间建立了“信任关系”。进一步地，0层设备使用基于信任表包含的公钥信息，形成一个“信任环”。环上的设备可以基于签名信任表对环上的其他需要与之通信的设备进行身份验证，并与之建立安全通信。在此过程中，无需任何其他第三方的参与。此外，0层设备还帮助其他层设备建立安全通信。
进一步地，两个0层设备可以根据签名信任表计算它们之间的PSK。应理解，在车辆运行阶段，该两个0层设备将使用该PSK计算会话密钥。该计算出的PSK将存储在各个设备的安全硬件中，以避免未经授权的访问和/或篡改。应理解，对于所有需要计算PSK的0层设备，该过程都是相同的。
示例性地，基于ZC1的信任表，它需要与ZC2通信，反之亦然，因此ZC1和ZC2都将计算一个PSK。在一些可能的实现方式，其中ZC1和ZC2都将根据信任表确定另一方的签名证书。进一步地，ZC1和ZC2将使用OEM PKI服务器的公钥(与对0层设备的公钥进行签名时使用的秘钥为一对密钥对)验证彼此的签名证书，例如，ZC1使用OEM PKI服务器的公钥验证ZC2的签名证书。验证成功后，它们可以从签名证书中获取彼此的公钥，例如，ZC1从ZC2的签名证书中获取ZC2的公钥，ZC2从ZC1的签名证书中获取ZC1的公钥。
进一步地，ZC1和ZC2可以使用Diffie-Hellman(DH)密钥交换协议来计算PSK。示例性地，在Diffie-Hellman密钥交换中，ZC1生成一个随机值作为秘钥，并根据该秘钥生成第一临时公钥；ZC2生成一个随机值作为秘钥，并根据该秘钥生成第二临时公钥。ZC1和ZC2交换彼此的临时公钥，并使用临时公钥和自己秘钥，计算相同的共享密钥，该共享密钥后续可用于生成新的会话密钥。
示例性地，ZC1生成一个随机值v1作为秘钥，并计算第一临时公钥G^v1，ZC2生成一个随机值v2作为秘钥，并计算第二临时公钥G^v2，二者分别向对方发送自己的临时公钥。进一步地，ZC1根据v1和第二临时公钥G^v2计算共享密钥G^v2v1，ZC2根据v2和第一临时公钥G^v1计算共享密钥G^v2v1。
应理解，除了Diffie-Hellman密钥交换协议之外，也可以使用其他预共享密钥计算技术来计算共享密钥(如PSK)。
需要说明的是，除计算PSK外，上述步骤中还可以计算其他密钥，如诊断密钥、SecOC密钥和其他应用密钥等。
应理解，由于0层设备通过以太网相互连接，因此它们也可以使用标准TLS解决方案相互验证并计算PSK。例如，TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA可用于此目的。
应理解，上述步骤可在车辆生产阶段完成。也就是说，可以在可信和受控的环境中执行上述步骤，其中所有参与实体都是可信的。
车辆生产阶段通常发生在受控和可信赖的环境中，而车辆运营阶段是售后市场阶段，是车辆实际运营中更容易遭受第三方攻击的环境。在车辆运行期间，这些设备相互进行通信。为了保护这种通信，设备可能需要密钥来对通信内容加密，和/或需要身份验证密钥来实现消息完整性。因此，车辆设备根据其需求，在此阶段建立会话密钥。该会话密钥可生成一次，或每天生成一次，或者也可以在车辆发动机启动时生成。
在一些可能的实现方式中，ZC1和ZC2使用PSK相互认证，PSK安全存储在ZC1和ZC2的安全硬件中。在双方有通信需求时，一方需向另一方证明其知道PSK，即进行身份验证。身份验证成功后，双方可以使用Diffie-Hellman密钥交换协议或其他此类协议计算新的会话密钥，并使用这些会话密钥加密通信，和/或计算认证信息。
应该注意的是，由于0层设备通过以太网相互连接，因此它们也可以使用标准TLS和PSK解决方案来建立新的会话密钥。例如，TLS_PSK_WITH_AES_128_CBC_SHA可用于此目的。
考虑到车辆的使用寿命可长达几十年，在此期间，车内设备可能会损坏，需要更换。新设备还需要密钥才能进行安全通信。因此，需要为新设备以及与新设备有直接通信关系的其他设备更新信任表。
一些可能的实现方式中，在更换设备的情况下，车主或驾驶员可以通过汽车的图形用户界面或注册手机输入密码/PIN授权OEM进行零件更换。为了解释这个过程，假设ZC1将被ZC1'替换。ZC1’将生成私钥/公钥对，并获得公钥的签名证书。
图5示出了本申请实施例提供的一种通信方法的示意性流程图，更具体地，图5显示了更新新设备和与新设备有直接通信关系的其他设备的信任表的方法，该方法可以包括：
S501，OEM电检设备向ZC1'请求签名证书。
示例性地，OEM电检设备连接到ZC1'，并向ZC1'请求签名证书。
S502，ZC1’将ZC1’的签名证书发送给OEM电检设备。
S503，OEM电检设备向OEM发送ZC1’的签名证书。
S504，OEM验证ZC1’的签名证书，并根据ZC1’的签名证书为ZC1’生成信任表，并更新与ZC1'通信的其他0层设备的信任表。
在一些可能的实现方式中，由于ZC1’是替换ZC1的，所以OEM只需将ZC1的信任表中的内容导入ZC1’的信任表中即可，并且，将其他0层设备中有ZC1信息的信任表中的ZC1公钥信息，替换为ZC1’的公钥信息。
S505，OEM向OEM PKI服务器发送信任表。
应理解，本步骤中的信任表可以包括ZC1’的信任表和需要与ZC1’通信的其他0层设备的信任表。OEM可以一次性向OEM PKI服务器发送上述所有信任表，也可以分批次发送。
S506，OEM PKI服务器对信任表进行签名。
示例性地，OEM PKI服务器使用自己的私钥对每个信任表分别签名，生成多个签名信任表。
S507，OEM PKI服务器将签名信任表发送给OEM。
应理解，本步骤中的签名信任表包括ZC1’的签名信任表以及需要与ZC1’通信的其他0层设备的签名信任表。
S508，OEM将签名信任表发送给OEM电检设备。
S509，OEM电检设备将ZC1’的签名信任表发送给ZC1’。
S510，ZC1'存储ZC1'的签名信任表。
需要说明的是，OEM电检设备还会将需要与ZC1’通信的其他0层设备的签名信任表分别发送给对应的0层设备，以使其更新签名信任表。
在一些可能的实现方式中，受设备更换影响的0层设备后续可以执行基于签名信任表和/或签名证书的认证并计算预共享密钥。应理解，在车辆运行期间，设备会像正常情况一样计算新的会话密钥。
图6示出了本申请实施例提供的一种通信方法的示意性流程图，更具体地，图6示出了1层设备中密钥生成的方法，该方法与0层设备中密钥生成的方法类似，本申请实施例以1层设备中的控制器ECU1为例进行说明，该方法具体可以包括：
S601，OEM电检设备激活公钥/私钥生成。
示例性地，电检设备连接到1层设备时，激活1层设备的生成公钥/私钥对。
S602，ECU1生成一个私钥，并根据该私钥计算公钥。
示例性地，ECU1将在安全硬件内生成密钥“s1”和相应的公钥G^s1。
S603，ECU1向OEM电检设备发送公钥。
示例性地，ECU1将公钥G^s1发送到OEM电检设备，而私钥“s1”保留在安全硬件内。
S604，OEM电检设备向PKI服务器发送公钥。
S605，PKI服务器对ECU1的公钥签名。
在一些实施例中，PKI服务器使用PKI的私钥作为证书对公钥G^s1进行签名，生成签名后的ECU1公钥CERT_G^s1。
需要说明的是，签名后的ECU1公钥CERT_G^s1本质上也是包含ECU1公钥的签名证书，此处为了与0层设备的签名证书进行区分，将1层设备的签名证书称为签名后的ECU1公钥。
S606，PKI服务器将签名后的ECU1公钥发送到OEM电检设备。
S607，OEM电检设备将签名后的ECU1公钥发送给ECU1。
S608，ECU1保存签名后的ECU1公钥。
可选地，OEM可以在车辆生产期间执行图6所示的方法。应理解，对于每个1层设备，都可以使用图6所示方法生成私钥/公钥对，并获得公钥的签名证书。
图7示出了本申请实施例提供的一种通信方法的示意性流程图，更具体地，图7中的(a)所示为0层设备生成包含1层设备信息的信任表的方法，该方法可以包括：
S701，OEM电检设备向1层设备请求签名后的公钥。
S702，1层设备向OEM电检设备发送签名后的公钥。
示例性地，每个1层设备将其签名证书发送给OEM电检设备。例如，1层设备包括ECU1、ECU2和ECU3，则ECU 1、ECU 2和ECU 3分别向检测设备发送其签名证书。例如，ECU 1向OEM电检设备发送签名后的公钥CERT_G^s1；ECU 2向OEM电检设备发送签名证书CERT_G^s2；ECU 3向OEM电检设备发送签名证书CERT_G^s3。
S703，OEM电检设备将签名后的公钥发送给OEM/OEM PKI服务器。
更具体地，OEM电检设备将签名后的公钥发送给OEM，以使得OEM后续根据该签名后的公钥生成信任表。
S704，OEM电检设备从0层设备请求签名证书。
S705，0层设备将签名证书发送给OEM电检设备。
示例性地，每个0层设备将其签名证书发送给OEM电检设备。例如，0层设备包括ZC1、ZC2和ZC3，则ZC1、ZC2和ZC3分别向检测设备发送其签名证书。例如，ZC1向OEM电检设备发送签名证书CERT_PK_ZC1；ZC2向OEM电检设备发送签名证书CERT_PK_ZC2；ZC3向OEM电检设备发送签名证书CERT_PK_ZC3。
S706，OEM电检设备将签名证书发送给OEM/OEM PKI服务器。
更具体地，OEM电检设备将签名证书发送给OEM，以使得OEM后续根据该签名证书生成信任表。
S707，OEM/OEM PKI服务器根据签名后的公钥和签名证书为每个0层设备生成信任表，并对信任表进行签名。
示例性地，OEM验证签名后的公钥和签名证书，并基于通信矩阵，根据签名后的公钥和签名证书为每个0层设备生成信任表，应理解，信任表中包含与该0层设备有通信需求的其他0层设备和1层设备的公钥信息。例如，ZC1将与ZC2、ZC3、ECU1、ECU2通信，ZC2将与ZC1、ZC4、ECU3、ECU4通信。因此，ZC1的信任表将包含ZC2、ZC3、ECU1、ECU2的公钥信息，以及VIN；ZC2的信任表将包含ZC1、ZC4、ECU3、ECU4的公钥信息，以及VIN。其中，公钥信息可以为签名证书的ID形式，或者也可以为签名证书的形式，或者也可以为公钥哈希的形式。此外，信任表中还可以包括生成点的常数点G，用于根据私钥计算公钥。在一些可能的实现方式中，信任表中也可以不包括生成点的常数点G，而是将该生成点的常数点G存储在0层设备和/或1层设备的安全环境中。
此外，对于0层设备ZC1，可以生成一个包含0层和1层设备信息的信任表，如表3所示；对于0层设备ZC2，也可以生成一个包含0层和1层设备信息的信任表，表4所示。或者，针对0层设备，也生成两个信任表，其中一个只包含0层设备的信息(如表5所示)，另一个只包含1层设备的信息(如表6所示)。应理解，后一种形式的信任表，在0层设备或1层设备发生更换时，信任表的更新更为容易。
表3.ZC1的信任表
VIN CertID_ZC2,CertID_ZC3,G,Cert_G^s1,Cert_G^s2,----
表4.ZC2的信任表
VIN CertID_ZC1,CertID_ZC4,G,Cert_G^s3,Cert_G^s4,----
表5.ZC1的一个信任表
VIN CertID_ZC2,CertID_ZC3,----
表6.ZC1的又一个信任表
VIN G,Cert_G^s1,Cert_G^s2,----
在一些可能的实现方式中，0层设备的信任表中还可以包括1层设备的SN码，例如，ZC1的信任表中还可以包括ECU1的SN码和ECU2的SN码，ZC2的信任表中还可以包括ECU3的SN码和ECU4的SN码。
进一步地，OEM将向OEM PKI服务器发送信任表。PKI服务器将对这些信任表进行签名，并将其发送回OEM。
S708，OEM/OEM PKI服务器将签名信任表发送给OEM电检设备。
电检设备将接收每个0层设备的签名信任表。
S709，OEM电检设备将签名信任表发送到0层设备。
应理解，OEM电检设备将签名信任表发送给对应的0层设备，例如，将签名的ZC1信任表发送给ZC1，将签名的ZC2信任表发送给ZC2。
S710，0层设备存储签名的信任表。
例如，ZC1的信任表将存储在ZC1中，以此类推。
在一些可能的实现方式中，还可以为1层设备生成包含0层设备信息的信任表，具体方法如图7中的(b)所示，该方法可以包括：
S701’，OEM电检设备向1层设备请求签名后的公钥。
S702’，1层设备向OEM电检设备发送签名后的公钥。
示例性地，此步骤可以参考S702中的描述，在此不再赘述。
S703’，OEM电检设备将签名后的公钥发送给OEM/OEM PKI服务器。
示例性地，此步骤可以参考S703中的描述，在此不再赘述。
S704’，OEM/OEM PKI服务器验证签名后的公钥，为1层设备生成信任表，并对信任表签名。
示例性地，OEM验证签名后的公钥，并基于通信矩阵，根据签名后的公钥为每个1层设备生成信任表，应理解，信任表中包含与该1层设备有通信需求的其他0层设备的公钥信息。例如，ECU1将与ZC1通信，因此，ECU1的信任表将包含ZC1的公钥(如G^zc1)，以及VIN，如表7所示。此外，信任表中还可以包括生成点的常数点G，用于根据私钥计算公钥。在一些可能的实现方式中，信任表中也可以不包括生成点的常数点G，而是将该生成点的常数点G存储在0层设备和/或1层设备的安全环境中。
表7.ECU1的信任表
VIN G,G^zc1
在一些可能的实现方式中，1层设备的信任表中还可以包括与之通信的0层设备的SN码。示例性地，ECU1的信任表中还可以包括ZC1的SN码。
进一步地，OEM将向OEM PKI服务器发送信任表。PKI服务器将对这些信任表进行签名，并将其发送回OEM。
S705’，OEM/OEM PKI向OEM电检设备发送1层设备签名信任表。
S706’，OEM电检设备将1层签名信任表发送给1层设备。
应理解，OEM电检设备将签名信任表发送给对应的1层设备，例如，将签名的ECU1信任表发送给ECU1，将签名的ECU2信任表发送给ECU2。
S707’，1层设备存储签名信任表。
例如，ECU1的信任表将存储在ECU1中，以此类推。
S708’，OEM电检设备从0层设备请求签名证书。
S709’，0层设备将签名证书发送给OEM电检设备。
示例性地，此步骤可以参考S705中的描述，在此不再赘述。
S710’，OEM电检设备将签名证书发送给OEM/OEM PKI服务器。
示例性地，此步骤可以参考S706中的描述，在此不再赘述。
S711’，OEM/OEM PKI服务器根据签名后的公钥和签名证书为每个0层设备生成信任表，并对信任表进行签名。
示例性地，此步骤可以参考S707中的描述，在此不再赘述。
S712’，OEM/OEM PKI服务器将0层设备签名信任表发送给OEM电检设备。
电检设备将接收每个0层设备的签名信任表。
S713’，OEM电检设备将0层设备签名信任表发送给0层设备。
应理解，OEM电检设备将签名信任表发送给对应的0层设备，例如，将签名的ZC1信任表发送给ZC1，将签名的ZC2信任表发送给ZC2。
S714’，
0层设备存储签名的信任表。
例如，ZC1的信任表将存储在ZC1中，以此类推。
应理解，在图7中的(b)所示的方法中，为0层设备生成信任表(或签名信任表)与图7中的(a)所示的方法为0层设备生成信任表可以是一致的。
需要说明的是，在一些可能的实现方式中，S704’至S706’需要在S710’之后执行，即，在OEM获取到0层设备的签名证书之后再执行。例如，为1层设备生成的信任表中需要包含与1层设备有通信需求的0层设备的签名证书，或签名证书ID，则S704’至S706’需要在S710’之后执行。
本申请实施例提供的一种通信方法中，0层设备和1层设备能够基于信任表建立“信任关系”，并且能够使用信任表中包含的公钥信息，对其他需要与之通信的设备进行身份验证，并与之建立安全通信。在此过程中，无需任何其他第三方的参与，能够有效避免外部接入导致的安全威胁。
图8示出了本申请实施例提供的一种通信方法的示意性流程图，更具体地，图8中的(a)所示为1层设备没有信任表的情况下，基于0层设备的信任表计算0层设备和1层设备之间的PSK的方法，该方法可以包括：
S801，ZC1生成一个随机数v1作为秘钥，根据v1计算第一公钥。生成一个Nonce值N1用于鉴权。
在一些可能的实现方式中，基于ZC1的信任表，它需要与ECU1通信，反之亦然，因此，ZC1和ECU1之间需要计算共享密钥(如PSK)，以用于后续通信过程中的会话加密。示例性地，ZC1将生成一个随机数v1作为秘钥，根据随机v1计算第一公钥计算为 G^v1。示例性地，该秘钥和公钥可以为DH密钥对。
此外，ZC1还将生成一个Nonce值N1，N1稍后将用于对ECU1进行鉴权。应理解，Nonce是一个只被使用一次的任意或非重复的随机数值。
S802，ZC1将第一公钥和Nonce值N1发送给ECU1。
应理解，ZC1可以一次性发送第一公钥和Nonce值N1，或者也可以分别发送第一公钥和Nonce值N1。
S803，ECU1计算共享密钥SS。
示例性地，ECU1可以使用第一公钥和自己的私钥s1计算第二公钥G^v1s1。进一步地，基于第二公钥计算共享密钥SS：SS＝F(G^v1s1)。其中，F可以是密钥派生函数或简单哈希函数。
S804，ZC1计算共享密钥SS。
在一些可能的实现方式中，ZC1根据信任表确定ECU1的公钥G^s1。进而，基于ECU1的公钥G^s1和随机数v2计算共享密钥SS：SS＝F(G^v1s1)。
S805，ECU1使用共享密钥SS加密Nonce N1。
为了进行身份验证并确保双方生成的共享密钥SS是相同的，ECU1可以使用SS加密Nonce N1。
S806，ECU1向ZC1发送加密后的Nonce N1。
S807，ZC1使用共享密钥SS解密加密后的Nonce N1。
示例性地，ZC1使用SS解密加密的Nonce N1以获得N1。成功解密将证明ZC1和ECU1具有相同的共享密钥SS。
S808，ECU1生成Nonce值N2。
S809，ECU1向ZC1发送Nonce值N2。
S810，ZC1使用共享密钥SS加密Nonce N2。
S811，ZC1将加密后的Nonce N2发送给ECU1。
S812，ECU1使用共享密钥SS解密加密后的Nonce N2。
ECU1使用SS解密加密的Nonce N2以获得N2。成功解密将完成双向身份验证和共享密钥确认。
S813，ECU1保存共享密钥SS。
S814，ZC1保存共享密钥SS。
需要说明的是，S808至S812是可选的。在一些实施例中，S813和S814可以同时执行，也可以先后执行，例如S814可以在S813之前执行。S803和S804也可以同时执行，或先后执行，例如S804可以在S803之前执行，或者，S804可以在S802或S803之前执行。
应理解，上述过程对于所有需要计算PSK的0层和1层设备都是相同的。该共享密钥SS稍后将在车辆运行期间用于生成新的会话密钥。
在一些可能的实现方式中，1层设备保存有信任表的情况下，则可以基于0层设备的和1层设备的信任表计算0层设备和1层设备之间的PSK的方法，如图8中的(b)所示，该方法可以包括：
S801’，ZC1生成一个随机数v1作为秘钥，根据v1计算第一公钥。使用自己的私钥对该第一公钥签名生成V1’。
在一些可能的实现方式中，基于ZC1的信任表，它需要与ECU1通信，反之亦然，因此，ZC1和ECU1之间需要计算共享密钥(如PSK)，以用于后续通信过程中的会话加密。示例性地，ZC1将生成一个随机数v1作为秘钥，根据随机v1计算第一公钥计算为G^v1。示例性地，该秘钥和公钥可以为DH密钥对。进一步地，ZC1使用自己的私钥zc1对第一公钥签名生成V1’：V1’＝Sign(G^v1,zc1)。
S802’，ZC1将V1’发送给ECU1。
S803’，ECU1使用ZC1的公钥验证V1’。
示例性地，ECU1可以根据信任表获取ZC1的公钥。
应理解，对V1’验证成功时，证明ZC1的身份是合法的。
S804’，ECU1生成一个随机数v2作为秘钥，根据v2计算第二公钥G^v2。使用自己的私钥对该第二公钥签名生成V2’。
示例性地，V2’＝Sign(G^v2,s1)
S805’，ECU1将V2’发送给ZC1。
S806’，ZC1使用ECU1的公钥验证V2’。
示例性地，ZC1可以根据信任表获取ECU1的公钥。
应理解，对V2’验证成功时，证明ECU1的身份是合法的。
S807’，ZC1使用ECU1的公钥计算共享密钥SS。
示例性地，ZC1使用ECU1的公钥和随机数v2计算共享密钥SS：SS＝F(G^v1v2)。
S808’，ECU1使用ZC1的公钥计算共享密钥SS。
示例性地，ECU1使用ZC1的公钥和随机数v1计算共享密钥SS：SS＝F(G^v1v2)。
在一些可能的实现方式中，S807’和S808’可以同时执行，也可以先后执行，例如S808’可以在S807’之前执行，或者，S808’可以在S802或S804’之前执行。
应理解，图8中以生成PSK为例进行说明，在一些可能的实现方式中，图8中所示的方法流程也可以用于生成其他安全密钥，如诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥等。
图9示出了本申请实施例提供的一种通信方法的示意性流程图，更具体地，图9所示为1层设备之间计算PSK的方法。应理解，由于1层设备ECU1和ECU2没有彼此的公钥信息，并且没有其他相互认证的手段，而0层设备ZC1保存有二者的公钥信息，以及二者具有通信需求的信息，因此，ZC1可以作为“中间人”辅助ECU1和ECU2计算PSK。该方法可以包括：
S901，ZC1生成随机数v，使用ECU2的公钥和随机数v为ECU1计算第三公钥(G^s2.v)，使用ECU1的公钥和随机数v为ECU2计算第四公钥(G^s1.v)。
示例性地，随机数v和第三公钥(G^s2.v)构成一个DH密钥对；随机数v和第四公钥(G^s1.v)构成一个DH密钥对。
S902，ZC1向ECU1发送公钥(G^s2.v)。
S903，ZC1向ECU2发送公钥(G^s1.v)。
S904，ECU1基于第三公钥(G^s2.v)使用自己的密钥s1计算第一密钥(G^s2.v.s1)。
S905，ECU2基于第四公钥(G^s1.v)使用自己的密钥s2计算第二密钥(G^s1.v.s2)。
应理解，此时，ECU1和ECU2都计算了相同的密钥值。由于ZC1不知道ECU1的密钥s1和ECU2的密钥s2，因此，ZC1无法计算密钥G^s1.s2.v。这使得ECU1和ECU2在 基于相同的密钥值计算出的共享密钥不会被第三方获知，进而能够保证通信安全性。
S906，ECU1导出共享密钥SS。
S907，ECU2导出共享密钥SS。
示例性地，ECU1和ECU2都可以使用F函数计算DH密钥(即共享密钥SS)，如：SS＝F(G^s1.s2.v)。在车辆运行期间该共享密钥SS将用于生成新的会话密钥。
在一些可能的实现方式中，ECU1和ECU2还可以通过交换使用SS加密的Nonce值来进一步完成身份验证和密钥确认。成功解密将完成双向身份验证和密钥确认。
具有相同PSK的1层和/或0层设备可以使用PSK相互验证，预共享密钥安全存储在安全硬件中，并且仅为各方所知。通信双方彼此证明其知道PSK，则完成了身份验证。进一步地，双方可以使用Diffie-Hellman密钥交换协议或任何其他此类协议计算新的会话密钥。在此步骤结束时，双方将拥有新的会话密钥，以对通信内容进行加密和/或计算消息身份验证信息。
应理解，图9中以生成PSK为例进行说明，在一些可能的实现方式中，图9中所示的方法流程也可以用于生成其他安全密钥，如诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥等。
如上所述，车辆的使用寿命将长达几十年。在此期间，车内设备可能会损坏，需要进行更换。新的1层设备还需要密钥才能进行安全通信，还需要为新设备以及与新设备有直接通信关系的其他设备更新信任表。应理解，更换1层设备后，针对新的1层设备进行密钥签名和信任表更新的流程与0层设备类似，可以参考上述实施例中的描述，在此不再赘述。
考虑到2层设备是资源受限的设备，一般没有安全硬件，因此这些设备的加密能力有限，在一个CAN帧中只能交换8字节的数据。因此，这些设备只需要轻量级的基于对称密钥的解决方案。图10所示为2层设备(以CAN ECU1为例)的预嵌入信任令牌形成的方法，该方法可以包括：
S1010，激活密钥生成。
示例性地，该步骤可以参考S301或S601中描述，在此不再赘述。
S1020，ZC1生成信任令牌。
示例性地，ZC1生成信任令牌s1，该信任令牌可以是随机数，或者也可以为其他形式的信任令牌。
S1030，ZC1向OEM电检设备发送信任令牌。
S1040，OEM电检设备向CAN ECU1发送信任令牌。
S1050，CAN ECU1存储信任令牌。
应理解，ZC1和CAN ECU1均会存储信任令牌s1。
在一些可能的实现方式中，将信任令牌注入CAN ECU1之前，ZC1可以根据CAN ECU1的SN码、物理指纹、认证芯片、安全芯片中的至少一个对CAN ECU1进行认证，在认证成功后，将信任令牌注入CAN ECU1。
在一些可能的实现方式中，上述信任令牌也可以由电检设备生成，进而分别“注入”ZC1和CAN ECU1，即发送给ZC1和CAN ECU1。
本申请实施例提供的一种通信方法，能够为2层设备预嵌入的信任令牌，能够避免注入外部密钥，并最大限度地保持车辆/组件内的密钥生成，能够保障车内0层设备和2层 设备之间通信的安全性。
图11示出了用于在0层设备和2层设备之间形成PSK的方法，该方法可以包括：
S1110，ZC1生成一个随机数v1作为秘钥，根据信任令牌和随机数v1计算共享密钥SS，使用信任令牌s1加密SS得到SS2。
S1120，ZC1向CAN ECU1发送SS2。
S1130，CAN ECU1使用信任令牌s1解密SS2得到SS。
进一步地，基于该共享密钥SSCAN ECU1和ZC1可以在车辆运行期间生成新的会话密钥。
需要说明的是，在CAN ECU1获取SS后，CAN ECU1和ZC1还可以通过交换使用SS加密的Nonce值来进一步完成身份验证和密钥确认。成功解密SS加密的Nonce值将完成双向身份验证和密钥确认，进一步地，CAN ECU1和ZC1均删除信任令牌s1。
在一些可能的实现方式中，上述实施例中的一个车载设备的信任表中，还可以包含与之通信的其他设备的面向服务的架构(service-oriented architecture，SOA)服务信息。例如，ZC1需要于ZC2和ZC3通信，ZC2支持的SOA服务包括服务A、服务B和服务C，但是ZC2面向ZC1开放的服务只由服务A，则ZC1的信任表中除了ZC2和ZC3的公钥信息外，还可以包含ZC2的服务A的相关信息。应理解，在上述情况下，ZC1只能访问ZC2的服务A，而无法访问ZC2的服务B和服务C。应理解，上述“服务”可以为设备抽象服务、原子服务、组合服务、应用服务中的至少一种。
为了便于读者理解，下面简单介绍“服务”相关的概念：
1、SOA，是一种架构设计思想，它将系统分解为相对独立的功能单元，上述相对独立的功能单元对外称为服务，可以将服务与抽象的接口进行封装，进一步地，这些服务之间通过定义的接口和协议进行通信。一个系统的众多服务可能基于分层的方式进行分类，例如底层的服务如设备抽象服务、原子服务、组合服务，上层的服务称为APP。
2、原子服务，一般将传感器、执行器等作为抽象硬件资源封装为原子服务。原子服务一般封装最基本的逻辑功能。例如，座椅的控制，车窗控制等。
3、组合服务，是对原子服务进行调用组合而形成的服务。
4、应用服务(或称APP)，是对原子服务和/或组合服务进行调用组合而形成的服务，一般封装各种应用场景，是直接面向客户的服务。
5、设备抽象服务，对传感器、执行器等硬件资源进行抽象，向原子服务提供设备访问接口。设备抽象服务一般封装电信号，例如电机的供电信号、霍尔信号等。
本申请实施例提供的一种通信方法，在车辆生成阶段，为每个0层设备和1层设备申请与车辆身份标识(如VIN)相关联的证书，确保该设备与其所在车辆唯一关联。进一步地，根据设备的证书为每个设备签发设备信任表，确保只有合法的设备才能接入。特别地，0层设备基于该信任表形成一个0层设备信任环，如图12所示，环上的每个设备可以对环外提供不同的服务，例如0层设备信任环可以提供车辆集成单元(vehicle integration unit，VIU)原子服务、VDC增强服务、MDC增强服务等。0层设备还可以进一步辅助1层设备和2层设备分别建立1层设备之间的信任环和2层设备之间的信任环。在一些可能的实现方式中，0层设备还可以辅助车辆的外接设备建立信任环。再进一步地，在设备启动时，通过设备证书和信任表验证设备的合法性，验证通过后，分发会话密钥，并定期刷新会话密钥，提高会话密钥的安全性。在业务需要安全通信时，使用会话密钥，建立安全通信， 确保通信数据的机密性和完整性。本申请实施例提供的一种通信方法中，生成的会话密钥在车内闭环，能够大幅降低密钥泄漏风险，减少密钥管理复杂度。
图13示出了本申请实施例提供的通信方法1300的示意性流程图。该方法1300可以应用于图1所示的车辆中，也可以由图2所示的系统中的ZC执行。该方法1300包括：
S1310，第一节点从第一设备接收第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点。
S1320，该第一节点根据该第二节点信息确定该第二节点；
S1330，该第一节点生成与该第二节点之间的安全密钥；
S1340，该第一节点根据该安全密钥与该第二节点进行通信。
示例性地，该第一节点可以为上述实施例中的任一0层设备，例如ZC1；第二节点可以为上述实施例中的0层设备(如ZC2)，或者也可以为上述实施例中的1层设备(如ECU1)；该第一节点和第二节点可以设置于第一终端中，该第一终端可以为上述实施例中的车辆，或者也可以为其他终端。
示例性地，该第一消息可以为上述实施例中的签名信任表，或者也可以为其他形式(如文件等)的包含与第一节点存在通信需求的节点的信息的签名白名单。
示例性地，该第二节点信息可以包括上述实施例中的第二节点的签名证书ID、第二节点的签名证书、第二节点的公钥哈希中的至少一个，或者还可以包括其他形式的第二节点的公钥信息。需要说明的是，在第二节点信息包括第二节点的公钥哈希时，第二节点信息还包括第二节点的身份信息。示例性地，该第二节点的身份信息可以为第二节点的SN码，或者也可以为其他能够指示第二节点身份的信息。
示例性地，该第一设备可以为上述实施例中的OEM PKI服务器，或者也可以为第一终端中的计算平台，例如VDC、MDC、CDC中的至少一个，或者还可以为其他可信任设备，例如车辆控制服务器ICAS1、智能驾驶服务器ICAS2、信息娱乐服务器ICAS3、BDC，SAS、MGU、ADAS super core、CSC等。
示例性地，该安全密钥可以为上述实施例中PSK。
示例性地，第一消息的生成方法可以参考上述实施例中的描述，在此不再赘述；该第一节点生成与该第二节点之间的安全密钥的方法可以参考上述实施例中的描述，在此不再赘述。
示例性地，该第一节点根据该安全密钥与该第二节点进行通信，可以包括：第一节点根据安全密钥生成与第二节点进行通信的会话密钥，进而根据会话密钥对于第二节点之间的通信内容进行加密。
在一些可能的实现方式中，方法1300还可以包括图3至图11中，其他由0层设备执行的方法。
本申请实施例提供的一种通信方法，使得通信节点之间通过第一消息建立相互之间的“信任关系”。进一步地，通信节点之间可以通过第一消息验证对方身份的合法性，验证通过后，协商共享安全密钥，用共享安全密钥可以为每次通信生成会话密钥。在业务需要安全通信时，使用会话密钥，建立安全通信，有助于确保通信数据的机密性和完整性。
图14示出了本申请实施例提供的通信方法1400的示意性流程图。该方法1400包括：
S1410，第二设备接收第一设备发送的第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点。
示例性地，该第二设备可以为上述实施例中的OEM，更具体地，第二设备可以为OEM TSP。
S1420，该第二设备向该第一节点发送第一消息。
示例性地，第二设备经由电检设备向第一节点发送该第一消息。
在一些可能的实现方式中，方法1400还可以包括图3至图11中，其他由OEM的设备执行的方法。
本申请实施例提供的一种通信方法，OEM通过向第一节点发送包含第二节点信息的第一消息，使得第一节点和第二节点之间建立“信任关系”，有助于第一节点和第二节点基于该第一消息生成会话密钥。进一步地，在业务需要安全通信时，使用会话密钥，建立安全通信，有助于确保通信数据的机密性和完整性。
图15示出了本申请实施例提供的通信方法1500的示意性流程图。该方法1500包括：
S1510，第一设备接收第二设备发送的第二消息；
示例性地，该第二消息可以为上述实施例中的信任表，或者可以为其他形式的包含与第一节点存在通信需求的节点的信息的白名单。
示例性地，该第二消息为第二设备根据通信列表和第二节点的签名公钥生成的。
S1520，该第一设备对该第二消息进行签名生成第一消息；
示例性地，对该第二消息进行签名生成第一消息的具体方法可以参考上述实施例中的描述，在此不再赘述。
S1530，该第一设备向第一节点发送该第一消息。
在一些可能的实现方式中，方法1500还可以包括图3至图11中，其他由OEM PKI服务器执行的方法。
本申请实施例提供的一种通信方法，第一设备通过对信任表进行签名生成签名信任表，使得签名信任表无法轻易地被其他设备更改，有助于进一步提高通信安全性。
图16示出了本申请实施例提供的通信方法1600的示意性流程图。该方法1600包括：
S1610，电检设备接收第一设备发送的第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点。
示例性地，该电检设备可以为上述实施例中的电检设备。
S1620，该电检设备向该第一节点发送该第一消息。
在一些可能的实现方式中，方法1600还可以包括图3至图11中，其他由电检设备执行的方法。
本申请实施例提供的一种通信方法，电检设备通过向第一节点发送包含第二节点信息的第一消息，使得第一节点和第二节点之间建立“信任关系”，有助于第一节点和第二节点基于该第一消息生成会话密钥。进一步地，在业务需要安全通信时，使用会话密钥，通信，有助于确保通信数据的机密性和完整性。
图17示出了本申请实施例提供的通信方法1700的示意性流程图。该方法1700包括：
S1710，接收第一密钥公钥，该第一密钥公钥是由第一节点根据第一消息生成，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点。
S1720，该第二节点根据该第一密钥公钥生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密；或者，该安全密钥用于该第二节点和第三节点之间的会话加密。
示例性地，该第二节点可以为上述实施例中的与第一节点具有通信需求的1层设备；该第三节点可以为上述实施例中与第二节点具有通信需求的1层设备。
示例性地，该第一密钥公钥可以为上述实施例中的第一公钥，或者也可以为上述实施例中的第三公钥或第四公钥。
示例性地，该安全密钥可以为上述实施例中的共享密钥SS。
在一些可能的实现方式中，方法1700还可以包括图3至图11中，其他由1层设备执行的方法。
本申请实施例提供的一种通信方法，1层设备可以基于0层设备发送的第一密钥公钥生成安全密钥，该安全密钥可以用于生成与0层设备或1层设备进行通信所需的会话密钥，有助于确保通信数据的机密性和完整性。
在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，各个实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
上文中结合图3至图17详细说明了本申请实施例提供的方法。下面将结合图18和图19详细说明本申请实施例提供的装置。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。
图18示出了本申请实施例提供的一种通信装置2000的示意性框图，该装置2000包括收发单元2010和处理单元2020。
可选地，该装置2000还可以包括存储单元，该存储单元可以用于存储指令和/或数据，处理单元2020可以读取存储单元中的指令和/或数据，以使得装置实现前述方法实施例。
该装置2000可以包括用于执行图13至图17中的方法的单元。并且，该装置2000中的各单元和上述其他操作和/或功能分别为了实现图13至图17中的方法实施例的相应流程。
其中，当该装置2000用于执行图13中的方法1300时，收发单元2010可用于执行方法1300中的S1310，处理单元2020可用于执行方法1300中的S1320至S1340。
该装置2000包括：收发单元2010，用于从第一设备接收第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；处理单元2020，用于根据该第二节点信息确定该第二节点；生成与该第二节点之间的安全密钥；根据该安全密钥与该第二节点进行通信。
在一些可能的实现方式中，该处理单元2020具体用于：在该第二节点保存有用于指示该第一节点的第一节点信息时，该第一节点根据该第二节点信息生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密。
在一些可能的实现方式中，该处理单元2020还用于：生成第一随机数；根据该第一随机数和该第二节点信息生成该安全密钥。
在一些可能的实现方式中，该处理单元2020还用于生成第二随机数；根据该第一随机数生成第一密钥公钥；该收发单元2010还用于向该第二节点发送该第二随机数和该第一密钥公钥；接收第一加密值，该第一加密值是该第二节点根据第一安全密钥加密该第二随机数获得，该第一安全密钥是根据该第二节点的秘钥和该第一密钥公钥生成的；该处理单元2020还用于根据该安全密钥对该第一加密值解密；在对该第一加密值解密成功时，存储该安全密钥。
在一些可能的实现方式中，处理单元2020还用于：生成第三随机数；根据该第三随机数生成第二密钥公钥；该收发单元2010还用于向该第二节点发送根据该第一节点的私钥和该第二密钥公钥生成的第一签名；接收第二签名，该第二签名是该第二节点对该第一签名验证成功后，根据该第二节点的私钥和第三密钥公钥生成的，该第三密钥公钥是根据该第二节点生成的第四随机数生成的；该处理单元还用于根据该第二节点信息验证该第二签名；在对该第二签名验证成功时，该第一节点根据该第三密钥公钥和该第三随机数生成该安全密钥。
在一些可能的实现方式中，该收发单元2010还用于：从该第一设备接收用于指示第三节点的第三节点信息和用于指示该第二节点和该第三节点需要通信的信息；该处理单元2020还用于生成第五随机数；根据该第五随机数和该第二节点信息生成第四密钥公钥；根据该第五随机数和该第三节点信息生成第五密钥公钥；该收发单元2010还用于向该第二节点发送该第五密钥公钥；向该第三节点发送该第四密钥公钥。
在一些可能的实现方式中，该收发单元2010还用于：接收第一消息之前，向该第二设备发送该第一节点的签名公钥，该第一节点的签名公钥用于生成该第一消息。
在一些可能的实现方式中，该第二节点信息包括该第二节点的公钥信息。
在一些可能的实现方式中，该第二节点的公钥信息包括如下至少一项：该第二节点的公钥签名证书；该第二节点的公钥签名证书身份识别号ID；该第二节点的公钥的哈希值和该第二节点的身份信息。
在一些可能的实现方式中，该收发单元2010还用于：从该第一设备接收该第二节点的服务信息，该第二节点的服务信息用于指示该第一节点可以访问的该第二节点中的服务。
在一些可能的实现方式中，该安全密钥包括如下至少一个：预共享密钥、诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥。
在一些可能的实现方式中，该处理单元2020还用于：生成信任令牌；该收发单元2010还用于向第四节点发送该信任令牌；该处理单元2020还用于生成第六随机数；根据该信任令牌和该第六随机数生成第二安全密钥；该收发单元2010还用于向该第四节点发送经过信任令牌加密过的第二安全密钥，以使得该第四节点根据其预先存储的该信任令牌进行解密得到该第二安全密钥，该第二安全密钥用于该第一节点和该第四节点之间的会话加密。
在一些可能的实现方式中，该处理单元2020还用于：该收发单元2010向第四节点发送该信任令牌之前，根据该第四节点的认证码SN、物理指纹、认证芯片、安全芯片中的至少一个对该第四节点进行认证；该收发单元2010具体用于：在认证成功时，向该第四节点发送该信任令牌。
在一些可能的实现方式中，该处理单元2020还用于：基于该第二安全密钥对该第四节点进行身份认证；在该身份认证通过时，删除该信任令牌。
该装置2000还可以用于执行图14中的方法。当该装置2000用于执行图14中的方法1400时，收发单元2010可用于执行方法1400中的S1410和S1420。
该装置2000包括：收发单元2010，用于接收第一设备发送的第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；向该第一节点发送该第一消息。
在一些可能的实现方式中，该装置2000还包括处理单元，用于：在该收发单元接收第一设备发送的第一消息之前，根据通信列表和该第二节点的签名公钥生成第二消息，该通信列表用于指示该第一节点和该第二节点需要进行通信；该收发单元2010还用于向该 第一设备发送该第二消息。
该装置2000还可以用于执行图15中的方法。当该装置2000用于执行图15中的方法1500时，收发单元2010可用于执行方法1500中的S1510和S1530，处理单元2020可用于执行方法1500中的S1520。
该装置2000包括：收发单元2010，用于接收第二设备发送的第二消息；处理单元2020，用于对该第二消息进行签名生成第一消息；该收发单元2010还用于向第一节点发送该第一消息。
该装置2000还可以用于执行图16中的方法。当该装置2000用于执行图16中的方法1600时，收发单元2010可用于执行方法1600中的S1610和S1620。
该装置2000包括：收发单元2010，用于接收第一设备发送的第一消息，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；向该第一节点发送该第一消息。
在一些可能的实现方式中，该收发单元2010还用于：接收第三设备发送的第一节点的签名公钥；向该第一节点发送该第一节点的签名公钥。
该装置2000还可以用于执行图17中的方法。当该装置2000用于执行图17中的方法1700时，收发单元2010可用于执行方法1700中的S1710，处理单元2020可用于执行方法1700中S1720。
该装置2000包括：收发单元2010，用于接收第一密钥公钥，该第一密钥公钥是由第一节点根据第一消息生成，该第一消息包括第二节点信息，该第二节点信息用于指示该第二节点；处理单元2020，用于根据该第一密钥公钥生成安全密钥，该安全密钥用于该第一节点和该第二节点之间的会话加密；或者，该安全密钥用于该第二节点和第三节点之间的会话加密。
在一些可能的实现方式中，该第一密钥公钥为使用该第一节点的私钥签名后的密钥公钥，该处理单元2020还用于：根据该第一消息确定该第一节点的公钥；根据该第一节点的公钥验证该第一密钥公钥；生成第五随机数；在验证成功时，根据该第一密钥公钥和该第五随机数生成安全密钥。
应理解，以上装置中各单元的划分仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。此外，装置中的单元可以以处理器调用软件的形式实现；例如装置包括处理器，处理器与存储器连接，存储器中存储有指令，处理器调用存储器中存储的指令，以实现以上任一种方法或实现该装置各单元的功能，其中处理器例如为通用处理器，例如CPU或微处理器，存储器为装置内的存储器或装置外的存储器。或者，装置中的单元可以以硬件电路的形式实现，可以通过对硬件电路的设计实现部分或全部单元的功能，该硬件电路可以理解为一个或多个处理器；例如，在一种实现中，该硬件电路为ASIC，通过对电路内元件逻辑关系的设计，实现以上部分或全部单元的功能；再如，在另一种实现中，该硬件电路为可以通过PLD实现，以FPGA为例，其可以包括大量逻辑门电路，通过配置文件来配置逻辑门电路之间的连接关系，从而实现以上部分或全部单元的功能。以上装置的所有单元可以全部通过处理器调用软件的形式实现，或全部通过硬件电路的形式实现，或部分通过处理器调用软件的形式实现，剩余部分通过硬件电路的形式实现。
在本申请实施例中，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如CPU、微处理器、GPU、或DSP等；在 另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为ASIC或PLD实现的硬件电路，例如FPGA。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种ASIC，例如NPU、TPU、DPU等。
可见，以上装置中的各单元可以是被配置成实施以上方法的一个或多个处理器(或处理电路)，例如：CPU、GPU、NPU、TPU、DPU、微处理器、DSP、ASIC、FPGA，或这些处理器形式中至少两种的组合。
此外，以上装置中的各单元可以全部或部分可以集成在一起，或者可以独立实现。在一种实现中，这些单元集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。该SOC中可以包括至少一个处理器，用于实现以上任一种方法或实现该装置各单元的功能，该至少一个处理器的种类可以不同，例如包括CPU和FPGA，CPU和人工智能处理器，CPU和GPU等。
图19是本申请实施例的一种通信装置的示意性框图。图19所示的通信装置2100可以包括：处理器2110、收发器2120以及存储器2130。其中，处理器2110、收发器2120以及存储器2130通过内部连接通路相连，该存储器2130用于存储指令，该处理器2110用于执行该存储器2130存储的指令，以收发器2120接收/发送部分参数。可选地，存储器2130既可以和处理器2110通过接口耦合，也可以和处理器2110集成在一起。
需要说明的是，上述收发器2120可以包括但不限于输入/输出接口(input/output interface)一类的收发装置，来实现装置2100与其他设备或通信网络之间的通信。
在实现过程中，上述方法的各步骤可以通过处理器2110中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器2130，处理器2110读取存储器2130中的信息，结合其硬件完成上述方法的步骤。为避免重复，这里不再详细描述。
处理器2110可以采用通用的CPU，微处理器，ASIC，GPU或者一个或多个集成电路，用于执行相关程序，以实现本申请方法实施例的通信方法。处理器2110还可以是一种集成电路芯片，具有信号的处理能力。在具体实现过程中，本申请的通信方法的各个步骤可以通过处理器2110中的硬件的集成逻辑电路或者软件形式的指令完成。上述处理器2110还可以是通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器2130，处理器2110读取存储器2130中的信息，结合其硬件执行本申请方法实施例的通信方法。
存储器2130可以是只读存储器(read only memory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(random access memory，RAM)。
收发器2120使用例如但不限于收发器一类的收发装置，来实现装置2100与其他设备或通信网络之间的通信。
本申请实施例还提供一种通信系统，该系统包括上述装置2000，或者上述装置2100。
本申请实施例还提供一种车辆，在一些可能的实现方式中，该车辆可以包括上述装置2000，或者上述装置2100。例如，在装置2000(或装置2100)为执行图13或图17中的方法的装置时，该车辆可以包括上述装置2000(或装置2100)。
本申请实施例还提供一种终端设备，在一些可能的实现方式中，该终端设备可以包括上述装置2000，或者上述装置2100。例如，在装置2000(或装置2100)为执行图14或图15或图16中的方法的装置时，该终端设备可以包括上述装置2000(或装置2100)。
本申请实施例还提供一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得所述计算机执行上述图3至图17中的方法。
本申请实施例还提供一种芯片，包括：至少一个处理器和存储器，所述至少一个处理器与所述存储器耦合，用于读取并执行所述存储器中的指令，以执行上述图3至图17中的方法。
应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而 前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (50)

  1. 一种通信方法，其特征在于，包括：
    第一节点从第一设备接收第一消息，所述第一消息包括第二节点信息，所述第二节点信息用于指示所述第二节点；
    所述第一节点根据所述第二节点信息确定所述第二节点；
    所述第一节点生成与所述第二节点之间的安全密钥；
    所述第一节点根据所述安全密钥与所述第二节点进行通信。
  2. 如权利要求1所述的方法，其特征在于，所述第一节点生成与所述第二节点之间的安全密钥，包括：
    在所述第二节点保存有用于指示所述第一节点的第一节点信息时，所述第一节点根据所述第二节点信息生成安全密钥，所述安全密钥用于所述第一节点和所述第二节点之间的会话加密。
  3. 如权利要求1或2所述的方法，其特征在于，所述方法还包括：
    所述第一节点生成第一随机数；
    所述第一节点生成与所述第二节点之间的安全密钥，包括：
    所述第一节点根据所述第一随机数和所述第二节点信息生成所述安全密钥。
  4. 如权利要求3所述的方法，其特征在于，所述方法还包括：
    所述第一节点生成第二随机数；
    所述第一节点根据所述第一随机数生成第一密钥公钥；
    所述第一节点向所述第二节点发送所述第二随机数和所述第一密钥公钥；
    所述第一节点接收第一加密值，所述第一加密值是所述第二节点根据第一安全密钥加密所述第二随机数获得，所述第一安全密钥是根据所述第二节点的秘钥和所述第一密钥公钥生成的；
    所述第一节点根据所述安全密钥对所述第一加密值解密；
    在对所述第一加密值解密成功时，所述第一节点存储所述安全密钥。
  5. 如权利要求1或2所述的方法，其特征在于，所述方法还包括：
    所述第一节点生成第三随机数；
    所述第一节点根据所述第三随机数生成第二密钥公钥；
    所述第一节点向所述第二节点发送根据所述第一节点的私钥和所述第二密钥公钥生成的第一签名；
    所述第一节点接收第二签名，所述第二签名是所述第二节点对所述第一签名验证成功后，根据所述第二节点的私钥和第三密钥公钥生成的，所述第三密钥公钥是根据所述第二节点生成的第四随机数生成的；
    所述第一节点根据所述第二节点信息验证所述第二签名；
    所述第一节点生成与所述第二节点之间的安全密钥，包括：
    在对所述第二签名验证成功时，所述第一节点根据所述第三密钥公钥和所述第三随机数生成所述安全密钥。
  6. 如权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一节点从所述第一设备接收用于指示第三节点的第三节点信息和用于指示所述第二节点和所述第三节点需要通信的信息；
    所述第一节点生成第五随机数；
    所述第一节点根据所述第五随机数和所述第二节点信息生成第四密钥公钥；
    所述第一节点根据所述第五随机数和所述第三节点信息生成第五密钥公钥；
    所述第一节点向所述第二节点发送所述第五密钥公钥；
    所述第一节点向所述第三节点发送所述第四密钥公钥。
  7. 如权利要求1至6中任一项所述的方法，其特征在于，所述第一节点接收第一消息之前，所述方法还包括：
    所述第一节点向第二设备发送所述第一节点的签名公钥，所述第一节点的签名公钥用于生成所述第一消息。
  8. 如权利要求1至7中任一项所述的方法，其特征在于，所述第二节点信息包括所述第二节点的公钥信息。
  9. 如权利要求8所述的方法，其特征在于，所述第二节点的公钥信息包括如下至少一项：
    所述第二节点的公钥签名证书；
    所述第二节点的公钥签名证书身份识别号ID；
    所述第二节点的公钥的哈希值和所述第二节点的身份信息。
  10. 如权利要求1至9中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一节点从所述第一设备接收所述第二节点的服务信息，所述第二节点的服务信息用于指示所述第一节点可以访问的所述第二节点中的服务。
  11. 如权利要求1至10中任一项所述的方法，其特征在于，所述安全密钥包括如下至少一个：预共享密钥、诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥。
  12. 如权利要求1至11中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一节点生成信任令牌；
    所述第一节点向第四节点发送所述信任令牌；
    所述第一节点生成第六随机数；
    所述第一节点根据所述信任令牌和所述第六随机数生成第二安全密钥；
    所述第一节点向所述第四节点发送经过信任令牌加密过的第二安全密钥，以使得所述第四节点根据其预先存储的所述信任令牌进行解密得到所述第二安全密钥，所述第二安全密钥用于所述第一节点和所述第四节点之间的会话加密。
  13. 如权利要求12所述的方法，其特征在于，所述第一节点向第四节点发送所述信任令牌之前，所述方法还包括：
    所述第一节点根据所述第四节点的认证码SN、物理指纹、认证芯片、安全芯片中的至少一个对所述第四节点进行认证；
    所述第一节点向第四节点发送所述信任令牌，包括：
    在认证成功时，所述第一节点向所述第四节点发送所述信任令牌。
  14. 如权利要求12或13所述的方法，其特征在于，所述方法还包括：
    所述第一节点基于所述第二安全密钥对所述第四节点进行身份认证；
    在所述身份认证通过时，所述第一节点删除所述信任令牌。
  15. 一种通信方法，其特征在于，包括：
    第二设备接收第一设备发送的第一消息，所述第一消息包括第二节点信息，所述第二节点信息用于指示所述第二节点；
    所述第二设备向所述第一节点发送所述第一消息。
  16. 如权利要求15所述的方法，其特征在于，所述第二设备接收第一设备发送的第一消息之前，所述方法还包括：
    所述第二设备根据通信列表和所述第二节点的签名公钥生成第二消息，所述通信列表用于指示所述第一节点和所述第二节点需要进行通信；
    所述第二设备向所述第一设备发送所述第二消息。
  17. 如权利要求15所述的方法，其特征在于，所述第二设备为电检设备，所述方法还包括：
    所述第二设备接收第三设备发送的第一节点的签名公钥；
    所述第二设备向所述第一节点发送所述第一节点的签名公钥。
  18. 一种通信方法，其特征在于，包括：
    第一设备接收第二设备发送的第二消息；
    所述第一设备对所述第二消息进行签名生成第一消息；
    所述第一设备向第一节点发送所述第一消息。
  19. 一种通信方法，其特征在于，包括：
    第二节点接收第一密钥公钥，所述第一密钥公钥是由第一节点根据第一消息生成，所述第一消息包括第二节点信息，所述第二节点信息用于指示所述第二节点；
    所述第二节点根据所述第一密钥公钥生成安全密钥，所述安全密钥用于所述第一节点和所述第二节点之间的会话加密；或者，所述安全密钥用于所述第二节点和第三节点之间的会话加密。
  20. 如权利要求19所述的方法，其特征在于，所述第一密钥公钥为使用所述第一节点的私钥签名后的密钥公钥，所述方法还包括：
    所述第二节点根据所述第一消息确定所述第一节点的公钥；
    所述第二节点根据所述第一节点的公钥验证所述第一密钥公钥；
    所述第二节点生成第五随机数；
    所述第二节点根据所述第一密钥公钥生成安全密钥，包括：
    在验证成功时，所述第二节点根据所述第一密钥公钥和所述第五随机数生成安全密钥。
  21. 一种第一节点，其特征在于，包括：
    收发单元，用于从第一设备接收第一消息，所述第一消息包括第二节点信息，所述第二节点信息用于指示所述第二节点；
    处理单元，用于根据所述第二节点信息确定所述第二节点；
    生成与所述第二节点之间的安全密钥；
    根据所述安全密钥与所述第二节点进行通信。
  22. 如权利要求21所述的第一节点，其特征在于，所述处理单元用于：
    在所述第二节点保存有用于指示所述第一节点的第一节点信息时，所述第一节点根据所述第二节点信息生成安全密钥，所述安全密钥用于所述第一节点和所述第二节点之间的会话加密。
  23. 如权利要求21或22所述的第一节点，其特征在于，所述处理单元还用于：
    生成第一随机数；
    根据所述第一随机数和所述第二节点信息生成所述安全密钥。
  24. 如权利要求23所述的第一节点，其特征在于，所述处理单元还用于：
    生成第二随机数；
    根据所述第一随机数生成第一密钥公钥；
    所述收发单元还用于向所述第二节点发送所述第二随机数和所述第一密钥公钥；
    接收第一加密值，所述第一加密值是所述第二节点根据第一安全密钥加密所述第二随机数获得，所述第一安全密钥是根据所述第二节点的秘钥和所述第一密钥公钥生成的；
    所述处理单元还用于根据所述安全密钥对所述第一加密值解密；
    在对所述第一加密值解密成功时，存储所述安全密钥。
  25. 如权利要求21或22所述的第一节点，其特征在于，所述处理单元还用于：
    生成第三随机数；
    根据所述第三随机数生成第二密钥公钥；
    所述收发单元还用于向所述第二节点发送根据所述第一节点的私钥和所述第二密钥公钥生成的第一签名；
    接收第二签名，所述第二签名是所述第二节点对所述第一签名验证成功后，根据所述第二节点的私钥和第三密钥公钥生成的，所述第三密钥公钥是根据所述第二节点生成的第四随机数生成的；
    所述处理单元还用于根据所述第二节点信息验证所述第二签名；
    在对所述第二签名验证成功时，所述第一节点根据所述第三密钥公钥和所述第三随机数生成所述安全密钥。
  26. 如权利要求21至25中任一项所述的第一节点，其特征在于，所述收发单元还用于：
    从所述第一设备接收用于指示第三节点的第三节点信息和用于指示所述第二节点和所述第三节点需要通信的信息；
    所述处理单元还用于生成第五随机数；
    根据所述第五随机数和所述第二节点信息生成第四密钥公钥；
    根据所述第五随机数和所述第三节点信息生成第五密钥公钥；
    所述收发单元还用于向所述第二节点发送所述第五密钥公钥；
    向所述第三节点发送所述第四密钥公钥。
  27. 如权利要求21至26中任一项所述的第一节点，其特征在于，所述收发单元还用于：
    接收第一消息之前，向所述第二设备发送所述第一节点的签名公钥，所述第一节点的签名公钥用于生成所述第一消息。
  28. 如权利要求21至27中任一项所述的第一节点，其特征在于，所述第二节点信息包括所述第二节点的公钥信息。
  29. 如权利要求28所述的第一节点，其特征在于，所述第二节点的公钥信息包括如下至少一项：
    所述第二节点的公钥签名证书；
    所述第二节点的公钥签名证书身份识别号ID；
    所述第二节点的公钥的哈希值和所述第二节点的身份信息。
  30. 如权利要求21至29中任一项所述的第一节点，其特征在于，所述收发单元还用于：
    从所述第一设备接收所述第二节点的服务信息，所述第二节点的服务信息用于指示所述第一节点可以访问的所述第二节点中的服务。
  31. 如权利要求21至30中任一项所述的第一节点，其特征在于，所述安全密钥包括如下至少一个：预共享密钥、诊断密钥、安全车载通信SecOC密钥、其他应用程序密钥。
  32. 如权利要求21至31中任一项所述的第一节点，其特征在于，所述处理单元还用于：
    生成信任令牌；
    所述收发单元还用于向第四节点发送所述信任令牌；
    所述处理单元还用于生成第六随机数；
    根据所述信任令牌和所述第六随机数生成第二安全密钥；
    所述收发单元还用于向所述第四节点发送经过信任令牌加密过的第二安全密钥，以使得所述第四节点根据其预先存储的所述信任令牌进行解密得到所述第二安全密钥，所述第二安全密钥用于所述第一节点和所述第四节点之间的会话加密。
  33. 如权利要求32所述的第一节点，其特征在于，所述处理单元还用于：
    所述收发单元向第四节点发送所述信任令牌之前，根据所述第四节点的认证码SN、物理指纹、认证芯片、安全芯片中的至少一个对所述第四节点进行认证；
    所述收发单元用于：在认证成功时，向所述第四节点发送所述信任令牌。
  34. 如权利要求32或33所述的第一节点，其特征在于，所述处理单元还用于：
    基于所述第二安全密钥对所述第四节点进行身份认证；
    在所述身份认证通过时，删除所述信任令牌。
  35. 一种第二设备，其特征在于，包括：
    收发单元，用于接收第一设备发送的第一消息，所述第一消息包括第二节点信息，所述第二节点信息用于指示所述第二节点；
    向所述第一节点发送所述第一消息。
  36. 如权利要求35所述的第二设备，其特征在于，所述第二设备还包括处理单元，用于：
    在所述收发单元接收第一设备发送的第一消息之前，根据通信列表和所述第二节点的签名公钥生成第二消息，所述通信列表用于指示所述第一节点和所述第二节点需要进行通信；
    所述收发单元还用于向所述第一设备发送所述第二消息。
  37. 如权利要求35所述的第二设备，其特征在于，在所述第二设备为电检设备时，所述收发单元还用于：
    接收第三设备发送的第一节点的签名公钥；
    向所述第一节点发送所述第一节点的签名公钥。
  38. 一种第一设备，其特征在于，包括：
    收发单元，用于接收第二设备发送的第二消息；
    处理单元，用于对所述第二消息进行签名生成第一消息；
    所述收发单元还用于向第一节点发送所述第一消息。
  39. 一种第二节点，其特征在于，包括：
    收发单元，用于接收第一密钥公钥，所述第一密钥公钥是由第一节点根据第一消息生成，所述第一消息包括第二节点信息，所述第二节点信息用于指示所述第二节点；
    处理单元，用于根据所述第一密钥公钥生成安全密钥，所述安全密钥用于所述第一节点和所述第二节点之间的会话加密；或者，所述安全密钥用于所述第二节点和第三节点之间的会话加密。
  40. 如权利要求39所述的第二节点，其特征在于，所述第一密钥公钥为使用所述第一节点的私钥签名后的密钥公钥，所述处理单元还用于：
    根据所述第一消息确定所述第一节点的公钥；
    根据所述第一节点的公钥验证所述第一密钥公钥；
    生成第五随机数；
    在验证成功时，所述第一密钥公钥和所述第五随机数生成安全密钥。
  41. 一种通信装置，其特征在于，包括：
    存储器，用于存储计算机程序；
    处理器，用于执行所述存储器中存储的计算机程序，以使得所述装置执行如权利要求1至14中任一项所述的方法，或者如权利要求19或20所述的方法。
  42. 一种通信装置，其特征在于，包括：
    存储器，用于存储计算机程序；
    处理器，用于执行所述存储器中存储的计算机程序，以使得所述装置执行如权利要求15至18中任一项所述的方法。
  43. 一种通信系统，其特征在于，所述系统包括如权利要求21至34中任一项所述的第一节点，和如权利要求39或40所述的第二节点。
  44. 如权利要求43所述的系统，其特征在于，所述第一节点生成第一随机数，根据所述第一随机数和第二节点信息生成安全密钥，其中所述第二节点信息用于指示所述第二节点；
    所述第一节点根据所述第一随机数生成第一密钥公钥；
    所述第一节点向所述第二节点发送所述第一密钥公钥；
    所述第二节点接收所述第一密钥公钥，并根据所述第二节点的私钥和所述第一密钥公钥生成第一安全密钥，并根据所述第一安全密钥加密所述第二随机数获得第一加密值；
    所述第二节点向所述第一节点发送所述第一加密值；
    所述第一节点接收所述第一加密值，并根据所述安全密钥对所述第一加密值解密；
    在所述第一节点对所述第一加密值解密成功时，所述第一节点存储所述安全密钥。
  45. 如权利要求44所述的系统，其特征在于，所述第一节点生成第三随机数，并根据所述第三随机数生成第二密钥公钥；
    所述第一节点向所述第二节点发送根据所述第一节点的私钥和所述第二密钥公钥生成的第一签名；
    所述第二节点接收所述第一签名，生成第四随机数，根据所述第四随机数生成第三密钥公钥，在对所述第一签名验证成功时，所述第二节点根据所述第二节点的私钥和第三密 钥公钥生成第二签名，并向所述第一节点发送所述第二签名；
    所述第二节点根据所述第四随机数和所述第二密钥公钥生成第三安全密钥；
    所述第一节点接收第二签名，并根据所述第二节点信息验证所述第二签名，在对所述第二签名验证成功时，根据所述第三密钥公钥和所述第三随机数生成第四安全密钥。
  46. 如权利要求43至45中任一项所述的系统，其特征在于，所述系统还包括如权利要求38所述的第一设备，所述第二节点包括第一装置和第二装置；
    所述第一节点从所述第一设备接收用于指示第一装置的第一装置信息、用于指示第二装置的第二装置信息和用于指示所述第一装置和所述第二装置需要通信的信息；
    所述第一节点生成第五随机数；
    所述第一节点根据所述第五随机数和所述第一装置信息生成第四密钥公钥；
    所述第一节点根据所述第五随机数和所述第二装置信息生成第五密钥公钥；
    所述第一节点向所述第一装置发送所述第五密钥公钥；
    所述第一节点向所述第二装置发送所述第四密钥公钥；
    所述第一装置接收所述第五密钥公钥，并根据所述第一装置的私钥和所述第五密钥公钥生成第五安全密钥；
    所述第二装置接收所述第四密钥公钥，并根据所述第二装置的私钥和所述第四密钥公钥生成所述第六安全密钥。
  47. 一种车辆，其特征在于，包括如权利要求21至34中任一项所述的第一节点、和/或如权利要求39、40中任一项所述的第二节点、和/或如权利要求41所述的通信装置。
  48. 一种终端设备，其特征在于，包括如权利要求35至37所述的第二设备、或如权利要求38所述的第一设备，或如权利要求42所述的通信装置。
  49. 一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被计算机执行时，以使得实现如权利要求1至20中任一项所述的方法。
  50. 一种芯片，其特征在于，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，以执行如权利要求1至20中任一项所述的方法。
PCT/CN2022/112474 2022-08-15 2022-08-15 通信方法、装置和系统 WO2024036435A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2022/112474 WO2024036435A1 (zh) 2022-08-15 2022-08-15 通信方法、装置和系统
PCT/CN2022/135195 WO2024036805A1 (zh) 2022-08-15 2022-11-29 通信方法、装置和系统
PCT/CN2023/091790 WO2024037048A1 (zh) 2022-08-15 2023-04-28 通信方法、装置和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/112474 WO2024036435A1 (zh) 2022-08-15 2022-08-15 通信方法、装置和系统

Publications (1)

Publication Number Publication Date
WO2024036435A1 true WO2024036435A1 (zh) 2024-02-22

Family

ID=89940305

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/CN2022/112474 WO2024036435A1 (zh) 2022-08-15 2022-08-15 通信方法、装置和系统
PCT/CN2022/135195 WO2024036805A1 (zh) 2022-08-15 2022-11-29 通信方法、装置和系统
PCT/CN2023/091790 WO2024037048A1 (zh) 2022-08-15 2023-04-28 通信方法、装置和系统

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/CN2022/135195 WO2024036805A1 (zh) 2022-08-15 2022-11-29 通信方法、装置和系统
PCT/CN2023/091790 WO2024037048A1 (zh) 2022-08-15 2023-04-28 通信方法、装置和系统

Country Status (1)

Country Link
WO (3) WO2024036435A1 (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106911655A (zh) * 2015-12-23 2017-06-30 北京奇虎科技有限公司 一种车辆通信的方法、车载终端及智能汽车
CN107493271A (zh) * 2017-07-28 2017-12-19 大唐高鸿信安（浙江）信息科技有限公司 可信安全网络系统
CN107846395A (zh) * 2016-09-20 2018-03-27 塞尔蒂卡姆公司 车载联网
CN110933672A (zh) * 2019-11-29 2020-03-27 华为技术有限公司 一种密钥协商方法及电子设备
CN110944327A (zh) * 2019-10-31 2020-03-31 卡斯柯信号(郑州)有限公司 用于轨道交通区域控制器的信息安全保密方法及其装置
US20210075606A1 (en) * 2019-09-05 2021-03-11 Infineon Technologies Ag Trusted authentication of automotive microcontroller
US20210226802A1 (en) * 2019-05-07 2021-07-22 Huawei Technologies Co., Ltd. Digital Certificate Application Method
CN114584287A (zh) * 2020-11-18 2022-06-03 华为技术有限公司 密钥管理的方法和装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5479408B2 (ja) * 2011-07-06 2014-04-23 日立オートモティブシステムズ株式会社 車載ネットワークシステム
CN112449326A (zh) * 2019-08-30 2021-03-05 华为技术有限公司 一种通信、更新密钥的方法及装置
CN113595717B (zh) * 2020-04-30 2023-10-17 比亚迪股份有限公司 Ecb模式分组加密方法和解密方法及控制装置和车辆
KR20230008167A (ko) * 2020-05-15 2023-01-13 후아웨이 테크놀러지 컴퍼니 리미티드 통신 방법 및 통신 장치
EP4247027A4 (en) * 2020-11-28 2024-01-03 Huawei Technologies Co., Ltd. COMMUNICATION METHOD AND DEVICE
JP2024500489A (ja) * 2020-12-24 2024-01-09 ホアウェイ・テクノロジーズ・カンパニー・リミテッド セキュアアクセス方法および装置
CN113016201B (zh) * 2020-12-31 2022-05-24 华为技术有限公司 密钥供应方法以及相关产品
CN112953939A (zh) * 2021-02-20 2021-06-11 联合汽车电子有限公司 一种密钥管理方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106911655A (zh) * 2015-12-23 2017-06-30 北京奇虎科技有限公司 一种车辆通信的方法、车载终端及智能汽车
CN107846395A (zh) * 2016-09-20 2018-03-27 塞尔蒂卡姆公司 车载联网
CN107493271A (zh) * 2017-07-28 2017-12-19 大唐高鸿信安（浙江）信息科技有限公司 可信安全网络系统
US20210226802A1 (en) * 2019-05-07 2021-07-22 Huawei Technologies Co., Ltd. Digital Certificate Application Method
US20210075606A1 (en) * 2019-09-05 2021-03-11 Infineon Technologies Ag Trusted authentication of automotive microcontroller
CN110944327A (zh) * 2019-10-31 2020-03-31 卡斯柯信号(郑州)有限公司 用于轨道交通区域控制器的信息安全保密方法及其装置
CN110933672A (zh) * 2019-11-29 2020-03-27 华为技术有限公司 一种密钥协商方法及电子设备
CN114584287A (zh) * 2020-11-18 2022-06-03 华为技术有限公司 密钥管理的方法和装置

Also Published As

Publication number Publication date
WO2024037048A1 (zh) 2024-02-22
WO2024036805A1 (zh) 2024-02-22

Similar Documents

Publication Publication Date Title
US11985238B2 (en) Vehicle-mounted device upgrade method and related device
US10965450B2 (en) In-vehicle networking
CN111279310B (zh) 一种车载设备升级方法及相关设备
CN112585905B (zh) 一种设备升级方法及相关设备
Bernardini et al. Security and privacy in vehicular communications: Challenges and opportunities
CN112543927B (zh) 一种设备升级方法及相关设备
KR20190083336A (ko) 디바이스의 보안 프로비저닝 및 관리
Iorio et al. Securing SOME/IP for in-vehicle service protection
WO2022140903A1 (zh) 一种ota升级方法及装置
WO2022160124A1 (zh) 一种服务授权管理方法及装置
CN113016201B (zh) 密钥供应方法以及相关产品
Alam Securing vehicle Electronic Control Unit (ECU) communications and stored data
WO2022155803A1 (zh) 数据加密的方法、数据传输的方法、相关装置以及设备
Groza et al. Prestvo: Privacy enabled smartphone based access to vehicle on-board units
WO2022037235A1 (en) Method and apparatus for supporting secure data routing
Jadhav Automotive cybersecurity
WO2024036435A1 (zh) 通信方法、装置和系统
CN117439740A (zh) 一种车内网络身份认证与密钥协商方法、系统及终端
EP4184857A1 (en) Bluetooth node pairing method and related apparatus
CN114980012A (zh) 一种车联网设备认证方法、装置及存储介质
CN114647836A (zh) 认证方法及装置
CN117378169B (zh) 一种密钥生成方法及装置
Wei et al. Authenticated can communications using standardized cryptographic techniques
CN115987988B (zh) 基于中继链的属性代理重加密方法、模型及存储介质
Hicks Cryptographic key management for the vehicles of tomorrow

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: 22955217

Country of ref document: EP

Kind code of ref document: A1