Communication method, device and system

Abstract

Provided are a communication method, apparatus and system, the method comprising: a first node receiving a first message from a first device, the first message comprising second node information, the second node information being used to indicate a second node; the first node determines the second node according to the second node information; the first node generates a security key between the first node and the second node; and the first node communicates with the second node according to the security key. According to the communication method provided by the invention, the confidentiality and integrity of communication data can be ensured on the premise of not introducing external connection.

Description

Communication method, device and system

[0001] This application claims priority to the PCT international application filed with the China Acceptance Office on August 15, 2022, with application number PCT / CN2022 / 112474 and application name “Communication Methods, Devices and Systems”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of security, and more specifically, to a communication method, device, and system. Background Art

[0003] Electronic control units (ECUs) and / or electronic control modules (ECMs) are embedded systems in vehicle electronics that control one or more electrical systems or subsystems in the vehicle.

[0004] Vehicle control units (ECUs) must communicate with each other to operate the vehicle. These communications include critical operations that impact vehicle safety. Manipulation of these communications can have serious consequences, including, in the worst case, the life of the vehicle occupant or other users. Therefore, encryption keys are often required to be injected between the two communicating ECUs to encrypt the communication. However, these methods are not secure enough.

[0005] Summary of the Invention

[0006] The present application provides a communication method and apparatus that can improve communication security between communication nodes.

[0007] In a first aspect, a communication method is provided, which 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, which is not limited in this application.

[0008] The method may include: a first node receives 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; the first node determines the second node based on the second node information; the first node generates a security key between itself and the second node; and the first node communicates with the second node based on the security key.

[0009] In some possible implementations, a first node receives a first message from a first device, where the first message includes second node information, where the second node information is used to indicate the second node and communicate with the second node.

[0010] In some possible implementations, 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 an electrical inspection device or a proxy unit of a vehicle.

[0011] In some possible implementations, the first node and the second node may be nodes in a first terminal. For example, the first terminal may be a vehicle, or may be other terminal devices.

[0012] It should be understood that the first node can know which second nodes it needs to communicate with through the first message.

[0013] In some possible implementations, the first node may be a device with security hardware, such as a zone controller (ZC), a telecommunication unit (TCU), an in-vehicle infotainment (IVI), or an advanced driving assistant system (ADAS); the second node may be a device with security hardware, such as the ZC, TCU, IVI, or ADAS in the above-mentioned embodiments, or may be a device with security hardware, such as an electric power steering (EPS) or an electric parking brake (EPB). For example, the first node and the second node may be connected via an Ethernet cable, or via a controller area network-flexible data (CAN-FD) cable.

[0014] In some possible implementations, the first node and the second node may also be controllers or domain controllers such as VDC, MDC, and CDC.

[0015] In some possible implementations, the first node may be a layer 0 device, and the second node may be a layer 0 device or a layer 1 device.

[0016] In some possible implementations, the first message may also include identity information of the first terminal. The identity information of the first terminal may be a vehicle identification number (VIN), or other information that can indicate the identity of the first terminal. This application does not make specific limitations on this.

[0017] It should be understood that the first node and the second node may also be other components in the terminal device that need to communicate.

[0018] In some possible implementations, the first message may be a signed trust credential, and the signed trust credential may be in the form of a table, or a file, or other forms, which is not specifically limited in the embodiments of the present application.

[0019] In some possible implementations, the first device may be an OEM PKI server, or it may be a computing platform in the first terminal, such as at least one of a vehicle domain controller (VDC), a mobile data center (MDC), and a chassis domain controller (CDC); or it may be other trusted devices, such as a vehicle control server ICAS1, an intelligent driving server ICAS2, an infotainment server ICAS3, a body domain controller (BDC), a special equipment system (SAS), a media graphics unit (MGU), a body super core (BSC), an ADAS super core, a cockpit super core (CSC), etc.

[0020] In some possible implementations, 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. Alternatively, the first node may be a node that is to replace the original first node, and / or the second node may be a node that is to replace the original second node.

[0021] In the above technical solution, a first node can establish a mutual "trust relationship" with a second node based on a first message containing the second node's information. Furthermore, the first node can verify the legitimacy of the second node's identity through the first message. Once verified, the first node and the second node can negotiate a shared security key. Furthermore, the first and second nodes can use the shared security key to generate a session key for each communication. When secure communication is required, this session key is used to encrypt the communication content, establishing secure communication and helping to ensure the confidentiality and integrity of the communication data.

[0022] In combination with the first aspect, in certain implementations of the first aspect, the first node generates a security key between itself and the second node, including: when the second node stores the first node information indicating the first node, the first node generates a security key based on the second node information, and the security key is used to encrypt the session between the first node and the second node.

[0023] It should be understood that the first node information is used to instruct the second node to communicate with the first node, and / or the first node information includes public key information of the first node.

[0024] In some possible implementations, "the first node generates a security key based on the second node information" can be understood as the first node confirming, based on the second node information, that it has a communication requirement with the second node. Furthermore, the first node generates a random number, receives a temporary public key from the second node, and then generates the security key based on the temporary public key and the random number it generated. The temporary public key sent by the second node is generated by the second node based on the random number it generated.

[0025] It should be understood that, correspondingly, the second node generates a key that is identical to the security key generated by the first node based on the public key information of the first node.

[0026] Exemplarily, the method for the first node and the second node to generate the security key may be the Diffie-Hellman key exchange protocol, or may be other pre-shared key calculation technologies, which is not specifically limited in this application.

[0027] Illustratively, the security key may be stored in secure hardware of the first node to prevent unauthorized access or tampering.

[0028] In some possible implementations, the first node may also use a standard TLS solution to verify the identity of the second node and calculate the security key. For example, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA may be used for this purpose.

[0029] In the above technical solution, the first node and the second node negotiate a security key based on the first message and the other node's public key information, and communicate based on the security key, significantly improving the negotiation performance of the secure connection. It also reduces the risk of security key leakage and the complexity of security key management.

[0030] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: the first node generates a first random number; the first node generates a security key between itself and the second node, including: the first node generates the security key based on the first random number and the second node information.

[0031] In some possible implementations, before the first node generates the first random number, the first node confirms that there is a communication need between the first node and the second node based on the first message (or second node information), and then generates a first random number for the second node, such as v1.

[0032] Exemplarily, the second node information is used to indicate information of the public key G^s1 of the second node, and the first node generates the security key according to the random number v1 and G^s1.

[0033] In some possible implementations, the second node does not know which nodes it needs to communicate with. For example, the second node is a layer 1 device that does not store the information of the first node.

[0034] In some possible implementations, the first node generates a first public key, such as G^v1, based on the first random number. It should be understood that, correspondingly, the second node generates a key identical to the security key generated by the first node based on the first public key G^v1 and its own private key s1.

[0035] Illustratively, the security key may be stored in secure hardware of the first node to prevent unauthorized access or tampering.

[0036] In the above technical solution, 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.

[0037] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: the first node generates a second random number; the first node generates a first public key based on 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 a first encrypted value, which is obtained by the second node encrypting the second random number based on a first security key, and 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 the decryption of the first encrypted value is successful, the first node stores the security key.

[0038] Exemplarily, the second random number may be a Nonce value, or may be other random numbers, which is not specifically limited in this application.

[0039] It should be understood that when the first node successfully decrypts the first encrypted value according to the security key, the identity authentication of the second node is completed, and at this time, the second node can be considered to be the legal node indicated by the first message.

[0040] It should be understood that when the first encrypted value is successfully decrypted, it proves that the security key generated by the first node is the same as the first security key generated by the second node.

[0041] In some possible implementations, the second node may also use the above method to authenticate the identity of the first node, and store the security key after successful authentication.

[0042] In the above technical solution, identity authentication is performed on the second node, which can further ensure communication security.

[0043] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: the first node generates a third random number; the first node generates a second key public key based on the third random number; the first node sends a first signature generated based on the private key of the first node and the second key public key to the second node; the first node receives a second signature, which is generated based on the private key and the third key public key of the second node after the second node successfully verifies the first signature, and the third key public key is generated based on the fourth random number generated by the second node; the first node verifies the second signature based on the second node information; the first node generates a security key between the first node and the second node, including: when the second signature is successfully verified, the first node generates the security key based on the third key public key and the third random number.

[0044] In some possible implementations, the second node stores the first node information. Exemplarily, the first node information includes the public key information of the first node. Correspondingly, the second node can calculate a security key that is the same as the security key generated by the first node based on the third public key and the third random number based on the first signature and the fourth random number.

[0045] In the above technical solution, a method for generating a security key between a layer 1 device and a layer 0 device is provided when a layer 1 device stores the public key information of a layer 0 device, which helps to ensure the communication security between the layer 1 device and the layer 0 device.

[0046] In combination with the first aspect, in certain implementations of the first aspect, the first node receives 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 first node generates a fifth random number; the first node generates a fourth key public key based on the fifth random number and the second node information; the first node generates a fifth key public key based on the fifth random number and the third node information; the first node sends the fifth key public key to the second node; and the first node sends the fourth key public key to the third node.

[0047] In some possible implementations, the third node information and the information used to indicate 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 used to indicate that the second node and the third node need to communicate may also be sent separately from the first message. The embodiments of the present application do not specifically limit this.

[0048] Exemplarily, the second node and the third node may both be layer 1 devices in the first terminal.

[0049] It should be understood that since the second node and the third node cannot know which layer 1 devices they can communicate with, they need to rely on the first node to assist the second node and the third node in generating the security keys required for communication between them.

[0050] Furthermore, the second node may generate a security key based on its own private key and the fifth key public key; the third node may generate a security key based on its own private key and the fourth key public key, and the security keys generated by the two are the same.

[0051] In the above technical solution, the first node can assist other nodes in generating 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 the complexity of key management.

[0052] In combination with the first aspect, in some implementations of the first aspect, before the first node receives the first message, the method also includes: the first node sends 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 first message.

[0053] Exemplarily, the second device may be an OEM TSP, or another OEM node or device capable of generating trust credentials. When the second device is an OEM TSP, or another node or device capable of generating trust credentials, the first node may send its signed public key to the second device via an electrical inspection device or a proxy unit in the vehicle.

[0054] In some possible implementations, the second device may be an electrical inspection device.

[0055] In some possible implementations, the signature public key of the first node is signed by the OEM PKI server and forwarded by the OEM TSP. The OEM TSP then stores the signature public key of the first node. In this case, the first node does not need to send the signature public key of the first node to the OEM TSP (via the electrical inspection equipment or the vehicle's agent unit).

[0056] In some possible implementations, the signed public key of the first node is issued by the equipment manufacturer, and the OEM TSP does not save the signed public key of the first node. At this time, the first node needs to send the signed public key of the first node to the OEM TSP (via the electrical inspection equipment or the vehicle's agent unit) so that the OEM TSP can generate a first message based on the signed public key of the first node.

[0057] It should be noted that the signature public key involved in this application may include anti-counterfeiting information obtained by signing the public key of the first node, which can prevent the public key of the first node from being forged. Exemplarily, the signature public key may include a public key obtained by the OEM PKI using its own private key to sign the public key of the first node, or the signature public key may also include a signature certificate obtained by the OEM PKI using its own private key to sign the public key of the first node.

[0058] In some possible implementations, the first message may also be generated and sent by a third-party server.

[0059] In some possible implementations, the signature public key of the first node may also be issued by a third-party server.

[0060] In combination with the first aspect, in some implementations of the first aspect, before the first node receives the first message, the method also includes: the first node sends the signature public key of the first node to the fourth device, and the signature public key of the first node is used to generate the first message.

[0061] Exemplarily, the fourth device may be an agent unit in a vehicle, wherein the agent unit may be a device having a function of sending and receiving information, for example, a vehicle-mounted telematics box (T-box).

[0062] In combination with the first aspect, in some implementations of the first aspect, the second node information includes public key information of the second node.

[0063] In combination with the first aspect, in certain implementations of the first aspect, 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 identification number ID of the public key signature certificate of the second node; the hash value of the public key of the second node and the identity information of the second node.

[0064] In the above technical solution, when the public key information is the identity identification number ID of the signature certificate of the public key, the overhead required for storing the public key information can be reduced.

[0065] In combination with the first aspect, in some implementations of the first aspect, the method further includes: the first node receiving service information of the second node from the first device, where the service information of the second node is used to indicate a service in the second node that the first node can access.

[0066] For example, the second node supports services A, B, C, and D, but the second node only allows the first node to access services A and B. In this case, the service information of the second node may include information about services A and B to instruct the first node to access its services A and B. It should be understood that in the above case, the first node cannot access services C and D of the second node.

[0067] As an example, the services A to D may be: air conditioning service, door control service, brake control service, and steering control service, respectively.

[0068] In some possible implementations, the service information of the second node may be included in the first message.

[0069] In some possible implementations, when the first message is a signed trust credential, the service information of the second node and the signed trust credential may be sent separately.

[0070] In this technical solution, based on the communication between the first and second nodes, more fine-grained access control can be constructed, allowing the first node to access only a portion of the second node's services. This ensures that the content of the remaining services of the second node will not be leaked in the event of an attack, further improving communication security. The service information of the second node is managed separately from the signature trust credential, facilitating information updates when the node is replaced. For example, when replacing the original second node with a new one, only the signature trust credential containing the second node's information can be updated without updating the second node's service information.

[0071] In combination with the first aspect, in certain implementations of the first aspect, 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.

[0072] In the above technical solution, 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, so that the security keys can form a closed loop within the first terminal, facilitating key management and reducing the risk of key leakage.

[0073] In combination with the first aspect, in certain implementations of the first aspect, the method also includes: the first node generates a trust token; the first node sends the trust token to the fourth node; the first node generates a sixth random number; 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, so that the fourth node decrypts the trust token pre-stored therein to obtain the second security key, and the second security key is used for session encryption between the first node and the fourth node.

[0074] In some possible implementations, the sixth random number may be a Nonce value, or other random numbers.

[0075] Illustratively, the fourth node may be a layer 2 device, or may be other devices without security hardware.

[0076] In the above technical solution, the first node can generate the security key required for communication between the first node and the fourth node without the need for "filling" of external keys, thereby preventing external connections from threatening the security of the first terminal.

[0077] In combination with the first aspect, in certain implementations of the first aspect, before the first node sends the trust token to the fourth node, the method also includes: the first node authenticates the fourth node based on at least one of the fourth node's serial number SN, physical fingerprint, authentication chip, and security chip; 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.

[0078] In the above technical solution, identity authentication is performed on the fourth node, which can further ensure communication security.

[0079] In combination with the first aspect, in certain implementations of the first aspect, the method further includes: the first node performing identity authentication on the fourth node based on the second security key; when the identity authentication is successful, the first node deletes the trust token.

[0080] In the above technical solution, deleting the trust token can prevent external intruders from stealing the trust token and causing security threats.

[0081] In a second aspect, a communication method is provided, which may include: a second device receiving a first message sent by a first device, the first message including second node information, the second node information being used to indicate the second node; and the second device sending the first message to the first node.

[0082] Exemplarily, the second device may be an OEM TSP, or may be other nodes or devices of the OEM that can generate trust credentials; or, the second device may be an electrical inspection device.

[0083] In some possible implementations, 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. Furthermore, the second device sends the first message to the electrical inspection device or the vehicle's agent unit, and the electrical inspection device or the vehicle's agent unit sends the first message to the first node.

[0084] In some possible implementations, when the second device is an electrical inspection device, the second device may receive the first message sent by the first device through an OEM device such as an OEM TSP. Furthermore, the second device directly sends the first message to the first node.

[0085] In some possible implementations, the second device directly receives the first message sent by the first device, and directly sends the first message to the first node.

[0086] It should be noted that the above “directly receive” and “directly send to…” can be understood as receiving or sending without forwarding through other devices.

[0087] In the above technical solution, the OEM or electrical inspection equipment establishes a "trust relationship" between the first and second nodes by sending a first message containing information about the second node to the first node. This helps the first and second nodes generate a session key based on the first message. Furthermore, when secure communication is required, using the session key helps ensure the confidentiality and integrity of the communication data.

[0088] In combination with the second aspect, in certain implementations of the second aspect, before the second device receives the first message sent by the first device, the method also includes: the second device generates a second message based on a communication list and the signature public key of the first node, 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.

[0089] Exemplarily, the method may be executed by an OEM TSP, or may also be executed by other nodes or devices of the OEM that are capable of generating trust credentials.

[0090] Exemplarily, the communication list may be in a list form or a matrix form, and the communication list is used to indicate the communication relationship between the nodes in the first terminal. The communication list may also be in other forms, which is not specifically limited in this application.

[0091] Exemplarily, the second message may be an unsigned trust credential. In some possible implementations, the trust credential may be a whitelist of other nodes communicating with the first node, and the trust credential includes public key information of the other nodes communicating with the first node.

[0092] In the above technical solution, the OEM's device can generate a second message, so that the first device signs the second message to generate a first message, which helps to establish a "trust relationship" between nodes in the first terminal based on the first message.

[0093] In combination with the second aspect, in some implementations of the second aspect, the second device is an electrical inspection device, and the method also includes: the second device receives the signature public key of the first node sent by the third device; and the second device sends the signature public key of the first node to the first node.

[0094] In some possible implementations, 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 an equipment vendor server.

[0095] It should be noted that when the third device is different from the first device, the electrical inspection device needs to obtain the signature public key of the first node from the first node before receiving the first message sent by the first device.

[0096] In the above technical solution, the electrical inspection device facilitates the subsequent generation and use of the first message based on the signature public key of the first node by sending the signature public key of the first node to the first node.

[0097] The third aspect of the proxy unit provides a communication method, which 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; and the first device sending the first message to a first node.

[0098] In the above technical solution, the first device generates a signed trust table by signing the trust table, so that the signed trust table cannot be easily modified by other devices, which helps to further improve communication security.

[0099] In a fourth aspect, a communication method is provided, which can be executed by a control unit or control module in a vehicle (or other terminal); or, it can also be executed by a chip or circuit of a control unit or control module for a vehicle (or other terminal), which is not limited in this application.

[0100] The method may include: the second node receives a first key public key, which is generated by the first node based on a first message, and the first message includes second node information, and the second node information is used to indicate the second node; the second node generates a security key based on the first key public key, and the security key is used to encrypt a session between the first node and the second node; or, the security key is used to encrypt a session between the second node and a third node.

[0101] Illustratively, the second node may be a layer 1 device.

[0102] Exemplarily, the third node may be a layer 1 device that has a communication requirement with the second node.

[0103] For example, when a session key between a second node and a third node is generated by a first node using the first node, "the first public key is generated by the first node based on the first message" can specifically mean: the first public key is generated by the first node based on a first random number and the public key of the third node, assuming that the first node determines, based on the first message, that the second and third nodes need to communicate. "The second node generates a security key based on the first public key" can mean: the second node generates a security key based on the first public key and the second node's private key. It should be understood that in this case, the security key is used to encrypt the session between the second and third nodes.

[0104] Exemplarily, when generating a session key between a first node and a second node, if the second node does not store the first node's information, "the second node generates a security key based on the first public key" may mean: the second node generates the security key based on the first public key and the second node's private key. Alternatively, if the second node stores the first node's information, "the second node generates a second security key based on the first public key" may mean: the second node generates the security key based on the first public key and a random number generated by the second node based on the second signature trust credential. It should be understood that in these cases, the second security key is used to encrypt the session between the first node and the second node.

[0105] In the above technical solution, the second node can generate a security key based on the first key public key sent by the first node. The security key can be used to generate the session key required for communicating with the first node or the third node without the need for external "filling" keys, which helps to improve the internal key security of the first terminal.

[0106] In combination with the fourth aspect, in certain implementations of the fourth aspect, the first key public key is the key public key signed with the private key of the first node, and the method also includes: the second node determines the public key of the first node based on the first message; the second node verifies the first key public key based on the public key of the first node; the second node generates a fifth random number; the second node generates a security key based on the first key public key, including: when the verification is successful, the second node generates a security key based on the first key public key and the fifth random number.

[0107] Exemplarily, the first public key may be the first signature in the first aspect described above.

[0108] In the above technical solution, the second node and the first node can negotiate a security key based on the first message and the other node's public key information, and use the security key for communication, significantly improving the negotiation performance of the secure connection. It can also reduce the risk of security key leakage and the complexity of security key management.

[0109] In a fifth aspect, a first node is provided, which includes: a transceiver unit for receiving a first message from a first device, the first message including second node information, the second node information being used to indicate the second node; a processing unit for determining the second node based on the second node information; generating a security key between the second node and the second node; and communicating with the second node based on the security key.

[0110] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is specifically used to: when the second node stores first node information for indicating the first node, the first node generates a security key based on the second node information, and the security key is used to encrypt the session between the first node and the second node.

[0111] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is further used to: generate a first random number; and generate the security key based on the first random number and the second node information.

[0112] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is further used to generate a second random number; generate a first key public key based on the first random number; the transceiver unit is further used to send the second random number and the first key public key to the second node; receive a first encrypted value, which is obtained by the second node encrypting the second random number based on a first security key, and the first security key is generated based on the secret key of the second node and the first key public key; the processing unit is further used to decrypt the first encrypted value based on the security key; and when the first encrypted value is decrypted successfully, the security key is stored.

[0113] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is further used to: generate a third random number; generate a second key public key based on the third random number; the transceiver unit is further used to send a first signature generated based on the private key of the first node and the second key public key to the second node; receive a second signature, which is generated based on the private key and the third key public key of the second node after the second node successfully verifies the first signature, and the third key public key is generated based on the fourth random number generated by the second node; the processing unit is further used to verify the second signature based on the second node information; when the second signature is successfully verified, the first node generates the security key based on the third key public key and the third random number.

[0114] In combination with the fifth aspect, in certain implementations of the fifth aspect, the transceiver unit is further used 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 is further used to generate a fifth random number; generate a fourth key public key based on the fifth random number and the second node information; generate a fifth key public key based on the fifth random number and the third node information; the transceiver unit is further used to send the fifth key public key to the second node; and send the fourth key public key to the third node.

[0115] In combination with the fifth aspect, in certain implementations of the fifth aspect, the transceiver unit is further used 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 first message.

[0116] In combination with the fifth aspect, in certain implementations of the fifth aspect, the second node information includes public key information of the second node.

[0117] In combination with the fifth aspect, in certain implementations of the fifth aspect, 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 identification number ID of the public key signature certificate of the second node; the hash value of the public key of the second node and the identity information of the second node.

[0118] In combination with the fifth aspect, in certain implementations of the fifth aspect, the transceiver unit is further used 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 services in the second node that the first node can access.

[0119] In combination with the fifth aspect, in certain implementations of the fifth aspect, 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.

[0120] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is further used to: generate a trust token; the transceiver unit is further used to send the trust token to the fourth node; the processing unit is further used to generate a sixth random number; generate a second security key based on the trust token and the sixth random number; the transceiver unit is further used to send the second security key encrypted by the trust token to the fourth node, so that the fourth node decrypts the trust token pre-stored therein to obtain the second security key, and the second security key is used to encrypt the session between the first node and the fourth node.

[0121] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is also used to: before the transceiver unit sends the trust token to the fourth node, authenticate the fourth node based on at least one of the fourth node's authentication code SN, physical fingerprint, authentication chip, and security chip; the transceiver unit is specifically used to: when the authentication is successful, send the trust token to the fourth node.

[0122] In combination with the fifth aspect, in certain implementations of the fifth aspect, the processing unit is further used to: perform identity authentication on the fourth node based on the second security key; and delete the trust token when the identity authentication passes.

[0123] In a sixth aspect, a second device is provided, which includes: a transceiver unit for receiving a first message sent by a first device, the first message including second node information, the second node information being used to indicate the second node; and sending the first message to the first node.

[0124] In combination with the sixth aspect, in certain implementations of the sixth aspect, the second device also includes a processing unit, which is used to: generate a second message based on a communication list and the signature public key of the first node before the transceiver unit receives the first message sent by the first device, 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.

[0125] In combination with the sixth aspect, in certain implementations of the sixth aspect, when the second device is an electrical inspection device, the transceiver unit is further used 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.

[0126] In the seventh aspect, a first device is provided, which 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; and the transceiver unit is also used to send the first message to the first node.

[0127] In the eighth aspect, a second node is provided, which includes: a transceiver unit for receiving a first key public key, which is generated by the first node based on a first message, and the first message includes second node information, and the second node information is used to indicate the second node; a processing unit for generating a security key based on the first key public key, and the security key is used for session encryption between the first node and the second node; or, the security key is used for session encryption between the second node and a third node.

[0128] In combination with the eighth aspect, in certain implementations of the eighth aspect, the first key public key is the key public key signed with the private key of the first node, and the processing unit is also used to: determine the public key of the first node based on the first message; verify the first key public key based on the public key of the first node; generate a fifth random number; and when the verification is successful, generate a security key based on the first key public key and the fifth random number.

[0129] In the ninth aspect, a communication device is provided, which includes: a memory for storing programs; a processor for executing the programs stored in the memory, and when the program stored in the memory is executed, the processor is used to execute the method in any possible implementation of the first aspect or the fourth aspect above.

[0130] In the tenth aspect, a communication device is provided, which includes: a memory for storing programs; a processor for executing the programs stored in the memory, and when the program stored in the memory is executed, the processor is used to execute the method in any possible implementation of the second aspect or the third aspect above.

[0131] In an eleventh aspect, a communication system is provided, which comprises the first node in any possible implementation of the fifth aspect and the second node in any possible implementation of the eighth aspect.

[0132] In combination with the eleventh aspect, in some implementations of the eleventh aspect, the first node generates a first random number, generates a security key based on the first random number and second node information, wherein the second node information is used to indicate the second node; the first node generates a first key public key based on the first random number; the first node sends the first key public key to the second node; the second node receives the first key public key, and generates a first security key based on the private key of the second node and the first key public key, and encrypts the second random number based on the first security key to obtain a first encrypted 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 based on the security key. When the first node successfully decrypts the first encrypted value, the first node stores the security key.

[0133] It should be understood that when the first node successfully decrypts the first encrypted value, it proves that the first security key is the same as the security key.

[0134] In some possible implementations, the second node may store the first security key after generating it. Alternatively, the first node may encrypt the first random number using the security key to generate a second encrypted value, and send the encrypted value to the second node. Furthermore, the second node may store the first security key after successfully decrypting the second encrypted value using the first security key.

[0135] In combination with the eleventh aspect, in some implementations of the eleventh aspect, the first node generates a third random number and generates a second key public key based on the third random number; the first node sends a first signature generated based on the private key of the first node and the second key public key to the second node; the second node receives the first signature, generates a fourth random number, and generates a third key public key based on the fourth random number. When the first signature is successfully verified, the second node generates a second signature based on the private key of the second node 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 key public key; the first node receives the second signature and verifies the second signature based on the second node information. When the second signature is successfully verified, the fourth security key is generated based on the third key public key and the third random number.

[0136] It should be understood that the third security key is the same as the fourth security key.

[0137] It should be understood that the third security key is the same security key as the security key "generated by the first node based on the third key public key and the third random number" in the first aspect.

[0138] In combination with the eleventh aspect, in some implementations of the eleventh aspect, the system also includes the first device in the above-mentioned eighth aspect, and the second node includes a first device and a second device; the first node receives first device information indicating the first device, second device information indicating the second device, and information indicating that the first device and the second device need to communicate from the first device; the first node generates a fifth random number; the first node generates a fourth key public key based on the fifth random number and the first device information; the first node generates a fifth key public key based on the fifth random number and the second device information; the first node sends the fifth key public key to the first device; the first node sends the fourth key public key to the second device; the first device receives the fifth key public key and generates a fifth security key based on the private key of the first device and the fifth key public key; the second device receives the fourth key public key and generates a sixth security key based on the private key of the second device and the fourth key public key.

[0139] It should be understood that the fifth security key is the same as the sixth security key.

[0140] In a twelfth aspect, a vehicle is provided, comprising the first node in any possible implementation of the fifth aspect and / or the second node in any possible implementation of the eighth aspect.

[0141] It should be understood that 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: cars, trucks, motorcycles, trains, airplanes, ships, etc.), industrial vehicles (such as: forklifts, trailers, tractors, etc.), engineering vehicles (such as: excavators, bulldozers, cranes, etc.), agricultural equipment (such as mowers, harvesters, etc.), amusement equipment, toy vehicles, etc. This application does not limit the type of vehicle.

[0142] In the thirteenth aspect, a terminal device is provided, which includes the second device in any possible implementation of the sixth aspect and / or the first device in any possible implementation of the seventh aspect.

[0143] In the fourteenth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the method in any one of the possible implementations of the first to fourth aspects.

[0144] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately packaged with the processor, and the embodiments of the present application do not specifically limit this.

[0145] In the fifteenth aspect, a computer-readable medium is provided, wherein the computer-readable medium stores program code, and when the computer program code runs on a computer, the computer executes the method in any possible implementation of the first to fourth aspects.

[0146] In the sixteenth aspect, a chip is provided, which includes a processor for calling a computer program or computer instructions stored in a memory so that the processor executes the method in any possible implementation of the first to fifth aspects above.

[0147] In combination with the sixteenth aspect, in one possible implementation, the processor is coupled to the memory through an interface.

[0148] In combination with the sixteenth aspect, in a possible implementation, the chip system also includes a memory, in which a computer program or computer instructions are stored.

[0149] In the seventeenth aspect, a communication method is provided, which may include: a fourth device receiving a first message sent by a first device, the first message including second node information, the second node information being used to indicate the second node; and the fourth device sending the first message to the first node.

[0150] For example, the fourth device may be associated with a vehicle agent unit. The agent unit may be software or hardware. If the agent unit is software, the fourth device may be a controller that hosts the software, such as a CDC or VIU controller. If the agent unit is hardware, the fourth device includes the hardware.

[0151] In the above technical solution, the vehicle's proxy unit sends the first node's signature public key to the first node, thereby facilitating the subsequent generation and use of the first message based on the first node's signature public key. In addition, the forwarding of the above messages and / or information is completed through the vehicle's proxy unit. This process does not require the participation of electrical inspection equipment, which can increase the speed of vehicle manufacturing.

[0152] In combination with the seventeenth aspect, in certain implementations of the seventeenth aspect, the method may also include: the fourth device receives the public key of the first node sent by the first node, and the public key of the first node is used to generate the signature public key of the first node; the fourth device sends the public key of the first node to the first device.

[0153] In combination with the seventeenth aspect, in certain implementations of the seventeenth aspect, the method further includes: the fourth device receives the signature public key of the first node sent by the first node; and the fourth device sends the signature public key of the first node to the second device.

[0154] In combination with the seventeenth aspect, in certain implementations of the seventeenth aspect, before the fourth device receives the signature public key of the first node sent by the first node, the method also includes: the fourth device receives a first signal from the electrical inspection device; and the fourth device sends a request information to the first node based on the first signal.

[0155] Exemplarily, the first signal is used to activate the fourth device.

[0156] In the eighteenth aspect, a fourth device is provided, which includes a transceiver unit, which is used to receive a first message sent by a first device, the first message including second node information, and the second node information is used to indicate the second node; and send the first message to the first node.

[0157] In combination with the eighteenth aspect, in certain implementations of the eighteenth aspect, the transceiver unit is also used to: receive the public key of the first node sent by the first node, the public key of the first node is used to generate the signature public key of the first node; and send the public key of the first node to the first device.

[0158] In combination with the eighteenth aspect, in certain implementations of the eighteenth aspect, the transceiver unit is further used to: receive the signature public key of the first node sent by the first node; and send the signature public key of the first node to the second device.

[0159] In combination with the eighteenth aspect, in certain implementations of the eighteenth aspect, the fourth device also includes a processing unit, and the transceiver unit is also used to: receive a first signal from the electrical inspection device; the processing unit is used to control the transceiver unit to send a request information to the first node based on the first signal, and the request information is used to request the public key of the first node.

[0160] In the nineteenth aspect, a communication system is provided, which includes a first node and a fourth device, wherein the first node sends the signature public key of the first node to the fourth device, the signature public key of the first node is used to generate the first message, the first message includes second node information, and the second node information is used to indicate the second node; the fourth device sends the first message to the first node.

[0161] In combination with the nineteenth aspect, in certain implementations of the nineteenth aspect, before the first node sends the signature public key of the first node to the fourth device, the fourth device receives a first signal from the electrical inspection device, and the fourth device sends a request message to the first node based on the first signal, where the request message is used to request the signature public key of the first node.

[0162] In the twentieth aspect, a communication system is provided, which includes a second device, which receives a signature public key of a first node sent by a first node, and the signature public key of the first node is used to generate a first message, and the first message includes second node information, and the second node information is used to indicate the second node; the second device sends the first message to the first node.

[0163] In combination with the twentieth aspect, in certain implementations of the twentieth aspect, the system further includes a first device, the second device generates a second message based on a communication list and the signature public key of the first node, 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; the first device signs the second message to generate the first message, and sends the first message to the second device. BRIEF DESCRIPTION OF THE DRAWINGS

[0164] FIG1 is a functional block diagram of a vehicle provided in an embodiment of the present application.

[0165] FIG2 is a schematic diagram of a communication system architecture provided in an embodiment of the present application.

[0166] FIG3 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0167] FIG4 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0168] FIG5 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0169] FIG6 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0170] FIG7 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0171] FIG8 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0172] FIG9 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0173] FIG10 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0174] FIG11 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0175] FIG12 is a schematic diagram of an application scenario of a communication method provided in an embodiment of the present application.

[0176] FIG13 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0177] FIG14 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0178] Figure 15 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0179] Figure 16 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0180] Figure 17 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0181] FIG18 is a schematic block diagram of a communication device provided in an embodiment of the present application.

[0182] FIG19 is another schematic block diagram of a communication device provided in an embodiment of the present application.

[0183] Figure 20 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0184] Figure 21 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0185] Figure 22 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0186] Figure 23 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0187] Figure 24 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0188] Figure 25 is a schematic flowchart of a communication method provided in an embodiment of the present application.

[0189] Figure 26 is a schematic block diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0190] The following describes the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents "or." For example, A / B can represent A or B. "And / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, or B exists alone.

[0191] In the embodiments of the present application, prefixes such as "first" and "second" are used 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 prefixes such as ordinal numbers to distinguish description objects in the embodiments of the present application does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and the use of such prefixes should not constitute an unnecessary restriction. In addition, in the description of this embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

[0192] FIG1 is a functional block diagram of a vehicle 100 according to an embodiment of the present application. Vehicle 100 may include a perception system 120, a display device 130, and a computing platform 150. Perception system 120 may include several sensors for sensing information about the environment surrounding vehicle 100. For example, perception system 120 may include a positioning system, which may be a global positioning system (GPS), a BeiDou system or other positioning system, an inertial measurement unit (IMU), a lidar, a millimeter-wave radar, an ultrasonic radar, or a camera.

[0193] Some or all functions of vehicle 100 may be controlled by computing platform 150. Computing platform 150 may include processors 151 to 15n (n is a positive integer). A processor is a circuit capable of processing signals. In one implementation, the processor may be a circuit capable of reading and executing instructions, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a type of microprocessor), or a digital signal processor (DSP). In another implementation, the processor may implement certain functions through the logical relationships of hardware circuits. The logical relationships of the hardware circuits may be fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field programmable gate array (FPGA). In a reconfigurable hardware circuit, the process of the processor loading a configuration file to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, 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), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc. In addition, the computing platform 150 can also include a memory for storing instructions. Some or all of the processors 151 to 15n can call the instructions in the memory and execute the instructions to achieve corresponding functions.

[0194] The vehicle 100 may include an ADAS, which utilizes a variety of sensors in the perception system 120 (including but not limited to: lidar, millimeter-wave radar, camera, ultrasonic sensor, global positioning system, inertial measurement unit) to obtain information from the surroundings of the vehicle, and analyzes and processes the obtained information to achieve functions such as obstacle perception, target recognition, vehicle positioning, path planning, driver monitoring / reminders, etc., thereby improving the safety, automation and comfort of vehicle driving.

[0195] Figure 2 shows a schematic diagram of a communication system architecture provided by an embodiment of the present application. As shown in Figure 2, the in-vehicle communication network 200 includes layer 0 devices, layer 1 devices, and layer 2 devices. Among them, layer 0 devices include ZC, TCU, IVI, ADAS, etc., which are interconnected through Ethernet cables. Layer 0 devices usually have secure hardware, such as hardware security modules (HSM), trusted platform modules (TPM), etc., so that layer 0 devices can generate security keys and perform public key encryption operations. Exemplarily, the generated "security keys" include but are not limited to pre-shared keys (PSK), diagnostic keys, security onboard communication (SecOC) keys, and other application keys.

[0196] Layer 1 devices typically connect to each other via CAN-FD cables, and to Layer 0 devices via CAN-FD. Layer 1 devices include EPS, EPB, and may also include CDC. Layer 1 may also have security hardware such as HSM and TPM.

[0197] It should be understood that the CAN-FD protocol allows 64 bytes of data to be transmitted in the data portion of a controller area network (CAN) frame, which is much smaller than the payload of an Ethernet frame.

[0198] Layer 2 devices are resource-constrained ECU devices without security hardware, connected to each other via a low-bandwidth CAN bus. For example, examples of Layer 2 devices may include CAN ECUs, sensors, actuators, etc.

[0199] In some possible implementations, the layer 2 device may also be a device connected via other buses such as a local interconnect network (LIN).

[0200] It should be understood that ECUs (ie, Layer 1 and Layer 2 devices) connected via non-Ethernet connections do not have standard TLS cipher suites available for implementing TLS-based security.

[0201] It should be noted that devices with secure hardware but connected via the CAN bus can still perform lightweight public key operations and can be considered as Layer 1 devices in this embodiment of the application. Devices without secure hardware but connected via CAN-FD are still considered as resource-constrained Layer 2 devices in this embodiment of the application because they cannot perform public key operations. For example, "public key operations" can include operations that autonomously generate public-private key pairs.

[0202] It should be understood that the various devices shown in FIG2 are merely examples. In actual applications, the aforementioned devices may be added or deleted based on actual needs. For example, there may be different numbers of devices with different names, or they may be connected to each other in different topologies in different vehicles.

[0203] As mentioned above, this application divides vehicle-mounted devices into three categories based on their connection type and processing capabilities, namely layer 0 devices, layer 1 devices, and layer 2 devices. In the embodiments of this application, corresponding solutions are proposed for each layer to establish secure communication between various vehicle-mounted devices.

[0204] Secure communication between Layer 0 devices: Each Layer 0 device establishes a "trust relationship" with other Layer 0 devices through a trust table containing information about the other Layer 0 devices it communicates with. Furthermore, based on public key cryptography using signed certificates, a device authentication mechanism and trusted communication are established between Layer 0 devices, forming a "trust ring" among all Layer 0 devices. Any device in the trust ring can further assist other devices in the trust ring with authentication and secure communication.

[0205] Secure communication between Layer 1 devices: Based on the trust table of Layer 0 devices, a "trust relationship" is established between Layer 0 devices and Layer 1 devices, and between Layer 1 devices and Layer 1 devices. Secure communication is then established between these devices based on the trust relationship.

[0206] Secure communication with Layer 2 devices: The Layer 0 device verifies the trust relationship with the Layer 2 device and establishes secure communication with the Layer 2 device using symmetric key cryptographic operations.

[0207] It is important to note that ECUs with secure hardware are capable of performing public key cryptographic operations (e.g., elliptic curve cryptography (ECC)), secure key generation and storage, etc.

[0208] The communication method between vehicle-mounted devices will be described in detail below with reference to FIG. 3 to FIG. 16 .

[0209] FIG3 is a schematic flow chart of a communication method provided in an embodiment of the present application. More specifically, FIG3 illustrates a method for generating a key and a signature certificate in a layer 0 device. This embodiment of the present application uses the zone controller ZC1 in a layer 0 device as an example for explanation. The method may include:

[0210] S301, the electrical inspection equipment activates the generation of public key / private key.

[0211] Exemplarily, when the electrical inspection device is connected to the layer 0 device, the generated public key / private key pair of the layer 0 device is activated.

[0212] S302, ZC1 generates a first public key and a first private key.

[0213] It should be understood that the first public key and the first private key form a key pair.

[0214] For example, ZC1 will generate its private / public key pair in secure hardware and send the first public key (e.g., PK_ZC1) to the electrical inspection device, while retaining the first private key in its own secure hardware. It should be understood that no third party can obtain or tamper with the private key securely stored in the secure hardware.

[0215] S303, ZC1 sends the first public key to the electrical inspection device.

[0216] S304: The electrical inspection device sends the first public key to a public key infrastructure (PKI) server.

[0217] Optionally, the electrical inspection device and the PKI server may be connected via wireless communication, such as the Internet or the Internet of Things, etc., which is not specifically limited in the embodiments of the present application.

[0218] S305: The PKI server signs the first public key and generates a first signature certificate including the first public key.

[0219] Exemplarily, the PKI server uses its own private key to sign the first public key of ZC1 to generate a signature certificate (eg, CERT_PK_ZC1). It should be understood that the certificate contains the public key of ZC1.

[0220] S306: The PKI server sends the first signature certificate to the electrical inspection device.

[0221] S307: The electrical inspection device sends the first signature certificate to ZC1.

[0222] S308, ZC1 saves the first signature certificate.

[0223] It should be noted that the steps performed by the electrical inspection equipment or PKI server shown in Figure 3 can be performed by an in-vehicle equipment supplier (such as the supplier of ZC1) during equipment production. In this case, the electrical inspection equipment can be the supplier's electrical inspection equipment, and further, the supplier's PKI server will sign the first signature certificate. Alternatively, the method shown in Figure 3 can also be performed by the vehicle manufacturer (original equipment manufacturer, OEM). In this case, the electrical inspection equipment will be the OEM's electrical inspection equipment, and the OEM's PKI server will sign the first signature certificate.

[0224] It is understandable that the sending and receiving of public keys and signature certificates by electrical inspection equipment may affect the vehicle production process and may also threaten vehicle safety. In view of this, Figure 20 provides a communication method, which uses an agent unit in the vehicle to execute the actions of sending and receiving public keys and signature certificates performed by the electrical inspection equipment in the above embodiment to solve the problem that the process of sending and receiving public keys and signature certificates affects the vehicle production process and vehicle safety. It should be noted that the agent unit involved in the embodiment of the present application can be a controller such as CDC or VIU, or it can also be software set in the controller. It should be noted that VIU can be a controller, or VIU can also be a gateway, or it can also be a unit with controller and gateway functions.

[0225] As shown in FIG. 20 , the method may include:

[0226] S301', the electrical inspection device activates the agent unit.

[0227] For example, when an electrical inspection device is connected to a vehicle or a vehicle's agent unit, the agent unit is activated. Specifically, the electrical inspection device sends diagnostic information to the agent unit based on 27 service authentication and the Unified Diagnostic Services (UDS) protocol. This diagnostic information activates the agent unit, causing it to begin sending and receiving information. In step S301, the agent unit generates the public / private key for activation ZC1.

[0228] Exemplarily, the proxy unit sends a public key request message to ZC1, so that ZC1 generates a public key / private key pair.

[0229] S302', ZC1 generates a first public key and a first private key.

[0230] For example, the specific method of this step may refer to the corresponding description of S302 shown in FIG. 3 .

[0231] S303', ZC1 sends the first public key to the proxy unit.

[0232] S304': The agent unit sends the first public key to a public key infrastructure (PKI) server.

[0233] Optionally, the proxy unit and the PKI server may be connected via wireless communication, such as the Internet, or the Internet of Things, etc., which is not specifically limited in the embodiments of the present application.

[0234] S305', the PKI server signs the first public key and generates a first signature certificate including the first public key.

[0235] For example, the specific method of this step may refer to the corresponding description of S305 shown in FIG. 3 .

[0236] S306', the PKI server sends the first signature certificate to the agent unit.

[0237] S307', the electrical inspection device sends the first signature certificate to ZC1.

[0238] S308', ZC1 saves the first signature certificate.

[0239] Optionally, the method shown in FIG. 20 may be performed by an OEM. In this case, the electrical inspection device will be the OEM's electrical inspection device, and the OEM's PKI server will sign the first signature certificate.

[0240] It should be understood that for each layer 0 device, the method shown in FIG3 can be used to generate a private key / public key pair and obtain a signature certificate for the public key.

[0241] FIG4 shows a schematic flow chart of a communication method provided in an embodiment of the present application. More specifically, FIG4 shows a method for generating a trust table between layer 0 devices. The method may include:

[0242] S401, the OEM electrical inspection device requests a certificate from the layer 0 device.

[0243] In some possible implementations, the OEM electrical inspection device may be connected to multiple layer 0 devices respectively, and request a signed certificate from each layer 0 device (eg, ZC1, ZC2, and ZC3).

[0244] S402, the layer 0 device sends the signed certificate (and / or SN) to the OEM electrical inspection device.

[0245] Exemplarily, each Tier 0 device sends its signed certificate to the OEM electrical inspection device. For example, if Tier 0 devices include ZC1, ZC2, and ZC3, then ZC1, ZC2, and ZC3 each send their signed certificates to the electrical inspection device. For example, ZC1 sends the signed certificate CERT_PK_ZC1 to the OEM electrical inspection device; ZC2 sends the signed certificate CERT_PK_ZC2 to the OEM electrical inspection device; and ZC3 sends the signed certificate CERT_PK_ZC3 to the OEM electrical inspection device.

[0246] In some possible implementations, the layer 0 device also sends its serial number (SN) to the OEM electrical inspection device.

[0247] S403, the OEM electrical inspection equipment sends the signed certificate (and / or SN) to the OEM.

[0248] For example, the electrical inspection device sends all signature certificates to the OEM. The OEM electrical inspection device can send all signature certificates to the OEM at once, or can send them in batches, for example, sending one or more signature certificates each time, which is not specifically limited in this embodiment of the present application.

[0249] In some possible implementations, the OEM electrical inspection equipment also sends the SN code of the layer 0 device to the OEM.

[0250] S404, the OEM verifies the signature certificate and generates a trust table for each layer 0 device based on the signature certificate.

[0251] In some possible implementations, the OEM maintains a communication matrix containing information indicating which in-vehicle devices require communication with each other. It should be noted that the requirement for communication between device 1 and device 2 may mean that signaling interaction may occur between devices 1 and 2 during vehicle operation. In specific implementations, devices 1 and 2 do not necessarily communicate or exchange signaling.

[0252] Furthermore, the OEM creates a trust table for each Layer 0 device based on the communication matrix and signed certificates. For example, the OEM knows from the communication matrix that ZC1 needs to communicate with ZC2 and ZC3. Therefore, ZC1's trust table will contain the public key information and VIN of ZC2 and ZC3. It should be understood that this identification number is globally unique for each vehicle.

[0253] For example, the information for ZC2 and ZC3 can be the signature certificate IDs of ZC2 and ZC3, such as the signature certificate ID CertID_ZC2 corresponding to ZC2's signature certificate (CERT_PK_ZC2) and the signature certificate ID CertID_ZC3 corresponding to ZC3's signature certificate (CERT_PK_ZC3). Similarly, ZC2's trust table will have the signature certificate IDs of ZC1 and any other Layer 0 devices (such as ZC4) that need to communicate during vehicle operation. For example, the trust tables for ZC1 and ZC2 are shown in Tables 1 and 2, respectively.

[0254] Table 1. Trust table of ZC1.

[0255] VINCertID_ZC2,CertID_ZC3,…

[0256] Table 2. Trust table of ZC2.

[0257] VINCertID_ZC1,CertID_ZC4,…

[0258] As another example, the information of ZC2 and ZC3 may include 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.

[0259] In another example, the information of ZC2 and ZC3 may include the signature certificates of ZC2 and ZC3, that is, the signature certificates of ZC2 and ZC3 are included in the trust table of ZC1.

[0260] In another example, the information of ZC2 and ZC3 may include the SN codes of ZC2 and ZC3, that is, the SN codes of ZC2 and ZC3 are included in the trust table of ZC1.

[0261] In some possible implementations, a device trust table may also include the serial number (SN) of the device that needs to communicate with it. For example, the trust table of ZC1 may also include the SN code of ZC2 and the SN code of ZC3, and the trust table of ZC2 may also include the SN code of ZC1 and the SN code of ZC4.

[0262] It should be understood that the OEM will prepare a trust table for each Tier 0 device of the vehicle and send the trust table of each Tier 0 device to the OEM PKI server.

[0263] S405: The OEM sends the trust table to the OEM PKI server.

[0264] For example, the OEM may send all trust tables to the OEM PKI server at one time, or may send them in batches, for example, sending one or more trust tables each time, which is not specifically limited in the embodiment of the present application.

[0265] S406: The OEM PKI server signs the trust table.

[0266] Exemplarily, the OEM PKI server uses its own private key to sign each trust table to generate multiple signed trust tables. It should be understood that one signed trust table corresponds to one layer 0 device.

[0267] In some possible implementations, the OEM PKI server may send its public key to each Tier 0 device via the OEM and the OEM electronic inspection device, so that the Tier 0 device verifies the signature trust table based on the public key.

[0268] S407: The OEM PKI server sends the multiple signature trust tables to the OEM.

[0269] S408, the OEM sends the signature trust table to the OEM electrical inspection equipment.

[0270] S409: The OEM electrical inspection device sends the signature trust table to the layer 0 device.

[0271] It should be understood that the OEM electrical inspection device sends the signed trust table to the corresponding layer 0 device, for example, sends the signed ZC1 trust table to ZC1 and sends the signed ZC2 trust table to ZC2.

[0272] S410: Each layer 0 device saves its own signature trust table.

[0273] For example, a signed ZC1 trust table would be stored in ZC1, and so on.

[0274] It should be understood that the “OEM” involved in the embodiments of the present application may be the OEM’s trust service provider (TSP), or may be other equipment of the OEM that can generate a trust table.

[0275] It should be noted that in the embodiments of the present application, the steps performed by the OEM can specifically be performed by a telecommunications service provider (TSP). In some possible implementations, the steps performed by the OEM PKI server and the OEM can also be performed by a third-party server, which is not specifically limited in the embodiments of the present application.

[0276] As described above, in order to address the issue of how sending and receiving messages using electrical inspection equipment affects vehicle production processes and vehicle safety, the steps of sending and receiving signature certificates and signature trust tables performed by the electrical inspection equipment in the above embodiment can be performed by a proxy unit. As shown in Figure 21, a communication method may include:

[0277] S401', the proxy unit requests a certificate from the layer 0 device.

[0278] In some possible implementations, the agent unit may be connected to multiple layer 0 devices respectively, and request a signed certificate from each layer 0 device (eg, ZC1, ZC2, and ZC3).

[0279] Exemplarily, the agent unit may include the agent unit in the above embodiment.

[0280] S402', the layer 0 device sends the signature certificate (and / or SN) to the proxy unit.

[0281] Exemplarily, each Layer 0 device sends its signature certificate to the agent. For example, if Layer 0 devices include ZC1, ZC2, and ZC3, then ZC1, ZC2, and ZC3 each send their signature certificates to the agent. For example, ZC1 sends its signature certificate CERT_PK_ZC1 to the agent; ZC2 sends its signature certificate CERT_PK_ZC2 to the agent; and ZC3 sends its signature certificate CERT_PK_ZC3 to the agent.

[0282] In some possible implementations, the layer 0 device also sends its SN code to the proxy unit.

[0283] S403', the agent unit sends the signature certificate (and / or SN) to the OEM.

[0284] For example, the proxy unit sends all signature certificates to the OEM. The proxy unit can send all signature certificates to the OEM at once, or can send them in batches, for example, sending one or more signature certificates each time, which is not specifically limited in this embodiment of the present application.

[0285] In some possible implementations, the agent unit also sends the SN code of the layer 0 device to the OEM.

[0286] S404', the OEM verifies the signature certificate and generates a trust table for each layer 0 device based on the signature certificate.

[0287] For example, the specific method of this step may refer to the corresponding description of S404 shown in FIG. 4 .

[0288] S405', the OEM sends the trust table to the OEM PKI server.

[0289] For example, the specific method of this step may refer to the corresponding description of S405 shown in FIG. 4 .

[0290] S406', the OEM PKI server signs the trust table.

[0291] For example, the specific method of this step may refer to the corresponding description of S406 shown in FIG. 4 .

[0292] S407', the OEM PKI server sends the multiple signature trust tables to the OEM.

[0293] S408', the OEM sends the signature trust table to the agent unit.

[0294] S409', the proxy unit sends the signature trust table to the layer 0 device.

[0295] It should be understood that the proxy unit sends the signed trust table to the corresponding layer 0 device, for example, sending the signed ZC1 trust table to ZC1 and sending the signed ZC2 trust table to ZC2.

[0296] S410', each layer 0 device saves its own signature trust table.

[0297] In some possible implementations, before S401' is executed, S4 needs to be executed, that is, the electrical inspection device needs to activate the process based on the diagnostic protocol. For example, the specific method of activating the process by the electrical inspection device can refer to the description of S301' and will not be repeated here.

[0298] In some possible implementations, the proxy unit communicates with other devices via a scalable service-oriented middleware over Internet protocol (SOME / IP) protocol.

[0299] In some possible implementations, the OEM PKI server also issues a device management certificate. When the OEM PKI server sends the signed trust table to the Layer 0 device, the device management certificate is also sent to the Layer 0 device. This allows the Layer 0 device to verify the signed trust table using the device management certificate after confirming the legitimacy and revocation status of the device management certificate.

[0300] In some possible implementations, the signature certificate of the Layer 0 device is signed by the OEM PKI server and forwarded by the OEM. The OEM then stores the signature certificate of the Layer 0 device. In this case, the Layer 0 device does not need to send the signature certificate to the OEM (via the electrical inspection equipment or the vehicle's agent unit), but only needs to send the SN to the OEM TSP.

[0301] In the communication method provided in the embodiment of the present application, 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 devices use the public key information contained in the trust table to form a "trust ring". Devices on the ring can authenticate other devices on the ring that need to communicate with them based on the signature trust table and establish secure communication with them. In this process, the participation of any other third party is not required. In addition, the layer 0 device also helps other layer devices establish secure communication.

[0302] Furthermore, two Layer 0 devices can calculate the PSK between them based on the signature trust table. It should be understood that during vehicle operation, the two Layer 0 devices will use this PSK to calculate a session key. This calculated PSK will be stored in the secure hardware of each device to prevent unauthorized access and / or tampering. It should be understood that this process is the same for all Layer 0 devices that need to calculate a PSK.

[0303] For example, based on ZC1's trust table, it needs to communicate with ZC2, and vice versa, so both ZC1 and ZC2 will calculate a PSK. In some possible implementations, ZC1 and ZC2 will each determine the other's signature certificate based on the trust table. Furthermore, ZC1 and ZC2 will use the OEM PKI server's public key (which forms a key pair with the secret key used to sign the Layer 0 device's public key) to verify each other's signature certificates. For example, ZC1 uses the OEM PKI server's public key to verify ZC2's signature certificate. After successful verification, they can obtain each other's public keys from the signature certificates. For example, ZC1 obtains ZC2's public key from ZC2's signature certificate, and ZC2 obtains ZC1's public key from ZC1's signature certificate.

[0304] Furthermore, ZC1 and ZC2 can use the Diffie-Hellman (DH) key exchange protocol to calculate the PSK. For example, in the Diffie-Hellman key exchange, ZC1 generates a random value as a secret key and uses it to generate a first temporary public key; ZC2 generates a random value as a secret key and uses it to generate a second temporary public key. ZC1 and ZC2 exchange their temporary public keys and use them with their own secret keys to calculate the same shared key, which can then be used to generate a new session key.

[0305] For example, ZC1 generates a random value v1 as a secret key and calculates a first temporary public key G^v1. ZC2 generates a random value v2 as a secret key and calculates a second temporary public key G^v2. Each ZC1 sends its temporary public key to the other. Furthermore, ZC1 calculates a shared key G^v2v1 based on v1 and the second temporary public key G^v2. ZC2 calculates a shared key G^v2v1 based on v2 and the first temporary public key G^v1.

[0306] It should be understood that in addition to the Diffie-Hellman key exchange protocol, other pre-shared key calculation technologies may also be used to calculate the shared key (such as PSK).

[0307] It should be noted that, in addition to calculating the PSK, other keys may also be calculated in the above steps, such as a diagnosis key, a SecOC key, and other application keys.

[0308] It should be understood that since the 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. For example, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA can be used for this purpose.

[0309] It should be understood that the above steps can be completed during the vehicle production phase. That is, the above steps can be performed in a trusted and controlled environment where all participating entities are trusted.

[0310] While the vehicle production phase typically occurs in a controlled and trusted environment, the vehicle operation phase, the aftermarket phase, is the actual operational environment of the vehicle, more susceptible to third-party attacks. During vehicle operation, these devices communicate with each other. To protect this communication, devices may require keys to encrypt the communication content and / or authentication keys to ensure message integrity. Therefore, vehicle devices establish session keys during this phase, depending on their needs. These session keys can be generated once, daily, or even at vehicle engine startup.

[0311] In some possible implementations, ZC1 and ZC2 authenticate each other using a PSK, which is securely stored in the secure hardware of ZC1 and ZC2. When two parties need to communicate, one party must prove to the other that it knows the PSK, a process known as authentication. After successful authentication, both parties can use the Diffie-Hellman key exchange protocol or other similar protocols to calculate new session keys, use these session keys to encrypt communications, and / or calculate authentication information.

[0312] It should be noted that since Layer 0 devices are connected to each other via Ethernet, they can also use standard TLS and PSK solutions to establish new session keys. For example, TLS_PSK_WITH_AES_128_CBC_SHA can be used for this purpose.

[0313] Considering that the lifespan of a vehicle can span decades, during which time devices within the vehicle may break down and need to be replaced. New devices also require keys for secure communication. Therefore, the trust table needs to be updated for the new device and other devices with which it has direct communication relationships.

[0314] In some possible implementations, when replacing a device, the owner or driver can authorize the OEM to perform the part replacement by entering a password / PIN through the vehicle's graphical user interface or a registered phone. To explain this process, assume that ZC1 will be replaced by ZC1'. ZC1' will generate a private / public key pair and obtain a signing certificate for the public key.

[0315] FIG5 shows a schematic flow chart of a communication method provided in an embodiment of the present application. More specifically, FIG5 shows a method for updating a trust table of a new device and other devices that have a direct communication relationship with the new device. The method may include:

[0316] S501, the OEM electrical inspection equipment requests a signed certificate from ZC1'.

[0317] Exemplarily, the OEM electrical inspection equipment is connected to ZC1 ′ and requests a signed certificate from ZC1 ′.

[0318] S502 , ZC1 ′ sends the signature certificate (and / or SN) of ZC1 ′ to the OEM electrical inspection equipment.

[0319] S503: The OEM electrical inspection device sends the signature certificate (and / or SN) of ZC1' to the OEM.

[0320] S504 , the OEM verifies the signature certificate of ZC1 ′, generates a trust table for ZC1 ′ according to the signature certificate of ZC1 ′, and updates the trust tables of other layer 0 devices communicating with ZC1 ′.

[0321] In some possible implementations, since ZC1' replaces ZC1, the OEM only needs to import the contents of ZC1's trust table into ZC1's trust table, and replace the ZC1 public key information in the trust tables of other layer 0 devices that contain ZC1 information with the public key information of ZC1'.

[0322] S505: The OEM sends the trust table to the OEM PKI server.

[0323] It should be understood that 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 may send all the above trust tables to the OEM PKI server at once or in batches.

[0324] S506: The OEM PKI server signs the trust table.

[0325] Exemplarily, the OEM PKI server uses its own private key to sign each trust table respectively, generating multiple signed trust tables.

[0326] S507: The OEM PKI server sends the signature trust table to the OEM.

[0327] It should be understood that 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 ′.

[0328] S508: The OEM sends the signature trust table to the OEM electrical inspection equipment.

[0329] S509 , the OEM electrical inspection device sends the signature trust table of ZC1 ′ to ZC1 ′.

[0330] S510 , ZC1 ′ stores the signature trust table of ZC1 ′.

[0331] It should be noted that the OEM electrical inspection device will also send the signature trust tables of other layer 0 devices that need to communicate with ZC1' to the corresponding layer 0 devices respectively, so that they can update the signature trust tables.

[0332] In some possible implementations, a method for updating a trust table between a new device and other devices that have a direct communication relationship with the new device may also be shown in FIG22 . The method may include:

[0333] S501', the proxy unit requests a signature certificate from ZC1'.

[0334] Exemplarily, the proxy unit connects to ZC1 ′ and requests a signed certificate from ZC1 ′.

[0335] S502', ZC1' sends the signature certificate (and / or SN) of ZC1' to the proxy unit.

[0336] S503': The agent unit sends the signature certificate (and / or SN) of ZC1' to the OEM.

[0337] S504', the OEM verifies the signature certificate of ZC1', generates a trust table for ZC1' according to the signature certificate of ZC1', and updates the trust tables of other layer 0 devices communicating with ZC1'.

[0338] S505', the OEM sends the trust table to the OEM PKI server.

[0339] S506': The OEM PKI server signs the trust table.

[0340] S507', the OEM PKI server sends the signature trust table to the OEM.

[0341] S508', the OEM sends the signature trust table to the agent unit.

[0342] S504 ′ to S508 ′ are similar to the method flow shown in FIG5 , and are not described again here.

[0343] S509', the proxy unit sends the signature trust table of ZC1' to ZC1'.

[0344] S510', ZC1' stores the signature trust table of ZC1'.

[0345] It should be noted that the proxy unit will also send the signature trust tables of other layer 0 devices that need to communicate with ZC1 ′ to the corresponding layer 0 devices respectively, so that they can update the signature trust tables.

[0346] In some possible implementations, before S501 ′ is executed, S5 needs to be executed, that is, the electrical testing device needs to activate the process based on the diagnostic protocol.

[0347] In some possible implementations, the OEM PKI server also issues a device management certificate. When the OEM PKI server sends the signed trust table to the Layer 0 device, the device management certificate is also sent to the Layer 0 device. This allows the Layer 0 device to verify the signed trust table using the device management certificate after confirming the legitimacy and revocation status of the device management certificate.

[0348] In some possible implementations, ZC1's signature certificate is signed by the OEM PKI server and forwarded by the OEM. The OEM then stores ZC1's signature certificate. In this case, ZC1' does not need to send the signature certificate to the OEM (via the electrical inspection equipment or the vehicle's agent unit), and can only send the SN to the OEM TSP.

[0349] In some possible implementations, the Layer 0 devices 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 during vehicle operation, the device will calculate a new session key as normal.

[0350] FIG6 shows a schematic flow chart of a communication method provided in an embodiment of the present application. More specifically, FIG6 shows a method for generating a key in a layer 1 device. This method is similar to the method for generating a key in a layer 0 device. This embodiment of the present application is described using the controller ECU1 in the layer 1 device as an example. The method may specifically include:

[0351] S601, OEM electrical inspection equipment activation public key / private key generation.

[0352] Exemplarily, when the electrical inspection device is connected to the layer 1 device, the generated public key / private key pair of the layer 1 device is activated.

[0353] S602: ECU1 generates a private key and calculates a public key based on the private key.

[0354] For example, ECU1 will generate a secret key “s1” and a corresponding public key G^s1 within secure hardware.

[0355] S603, ECU1 sends the public key to the OEM electrical inspection equipment.

[0356] For example, ECU1 sends the public key G^s1 to the OEM electronic inspection equipment, while the private key "s1" remains in the secure hardware.

[0357] S604: The OEM electrical inspection device sends the public key to the PKI server.

[0358] S605, the PKI server signs the public key of ECU1.

[0359] In some embodiments, the PKI server uses the private key of the PKI as a certificate to sign the public key G^s1 and generate the signed ECU1 public key CERT_G^s1.

[0360] It should be noted that the signed ECU1 public key CERT_G^s1 is essentially also 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 referred to as the signed ECU1 public key.

[0361] S606: The PKI server sends the signed ECU1 public key to the OEM electrical inspection equipment.

[0362] S607 , the OEM electrical inspection device sends the signed ECU1 public key to ECU1 .

[0363] S608, ECU1 saves the signed ECU1 public key.

[0364] In some possible implementations, a method for generating a key in a layer 1 device may also be as shown in FIG. 23 , and the method may include:

[0365] S601', the electrical inspection device activates the agent unit.

[0366] Exemplarily, when the electrical inspection device is connected to the vehicle or the agent unit of the vehicle, the agent unit will be activated.

[0367] Exemplarily, the agent unit may be the agent unit in the above embodiment.

[0368] In some possible implementations, S601 ′ and S301 ′ are the same step.

[0369] S601”, the agent unit activates the public key / private key generation of ECU1.

[0370] Exemplarily, the proxy unit sends a public key request message to the ECU 1 , so that the ECU 1 generates a public key / private key pair.

[0371] S602', ECU1 generates a private key, and calculates a public key based on the private key.

[0372] For example, the specific method of this step may refer to the corresponding description of S602 shown in FIG6 .

[0373] S603', ECU1 sends the public key to the proxy unit.

[0374] Exemplarily, ECU1 sends the public key G^s1 to the proxy unit, while the private key "s1" remains in the secure hardware.

[0375] S604', the agent sends the public key to the PKI server.

[0376] S605, the PKI server signs the public key of ECU1.

[0377] For example, the specific method of this step may refer to the corresponding description of S605 shown in FIG6 .

[0378] S606', the PKI server sends the signed public key of ECU1 to the proxy unit.

[0379] S607', the proxy unit sends the signed public key of ECU1 to ECU1.

[0380] S608', ECU1 saves the signed ECU1 public key.

[0381] Alternatively, 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 may be used to generate a private key / public key pair and obtain a signed certificate for the public key.

[0382] FIG7 shows a schematic flow chart of a communication method provided in an embodiment of the present application. More specifically, FIG7 (a) shows a method for a layer 0 device to generate a trust table containing layer 1 device information. The method may include:

[0383] S701: The OEM electrical inspection device requests the signed public key from the layer 1 device.

[0384] S702: The layer 1 device sends the signed public key to the OEM electrical inspection device.

[0385] Exemplarily, each Tier 1 device sends its signed certificate to the OEM electrical inspection device. For example, if Tier 1 devices include ECU1, ECU2, and ECU3, ECU1, ECU2, and ECU3 will each send their signed certificates to the inspection device. For example, ECU1 sends its signed public key CERT_G^s1 to the OEM electrical inspection device; ECU2 sends its signed certificate CERT_G^s2 to the OEM electrical inspection device; and ECU3 sends its signed certificate CERT_G^s3 to the OEM electrical inspection device.

[0386] S703: The OEM electrical inspection device sends the signed public key to the OEM / OEM PKI server.

[0387] More specifically, the OEM electrical inspection device sends the signed public key to the OEM, so that the OEM subsequently generates a trust table according to the signed public key.

[0388] S704: The OEM electrical inspection device requests a signed certificate from the layer 0 device.

[0389] S705, the layer 0 device sends the signed certificate to the OEM electrical inspection device.

[0390] Exemplarily, each Layer 0 device sends its signed certificate to the OEM electrical inspection device. For example, if Layer 0 devices include ZC1, ZC2, and ZC3, then ZC1, ZC2, and ZC3 each send their signed certificates to the inspection device. For example, ZC1 sends the signed certificate CERT_PK_ZC1 to the OEM electrical inspection device; ZC2 sends the signed certificate CERT_PK_ZC2 to the OEM electrical inspection device; and ZC3 sends the signed certificate CERT_PK_ZC3 to the OEM electrical inspection device.

[0391] S706: The OEM electrical inspection device sends the signed certificate to the OEM / OEM PKI server.

[0392] More specifically, the OEM electrical inspection device sends the signed certificate to the OEM, so that the OEM subsequently generates a trust table according to the signed certificate.

[0393] S707: The OEM / OEM PKI server generates a trust table for each layer 0 device according to the signed public key and signature certificate, and signs the trust table.

[0394] Exemplarily, the OEM verifies the signed public key and signature certificate and, based on the communication matrix, generates a trust table for each Layer 0 device. This trust table includes the public key information of other Layer 0 and Layer 1 devices that need to communicate with the Layer 0 device. For example, ZC1 will communicate with ZC2, ZC3, ECU1, and ECU2, and ZC2 will communicate with ZC1, ZC4, ECU3, and ECU4. Therefore, ZC1's trust table will include the public key information of ZC2, ZC3, ECU1, and ECU2, as well as the vehicle identification number (VIN); ZC2's trust table will include the public key information of ZC1, ZC4, ECU3, and ECU4, as well as the vehicle identification number (VIN). The public key information can be in the form of a signature certificate ID, a signature certificate, or a public key hash. Furthermore, the trust table may include a constant point G, which is used to calculate the public key from the private key. In some possible implementations, the trust table may not include the constant point G of the generation point, but instead store the constant point G of the generation point in a secure environment of the layer 0 device and / or the layer 1 device.

[0395] Furthermore, for Layer 0 device ZC1, a trust table containing information about both Layer 0 and Layer 1 devices can be generated, as shown in Table 3. For Layer 0 device ZC2, a trust table containing information about both Layer 0 and Layer 1 devices can also be generated, as shown in Table 4. Alternatively, two trust tables can be generated for Layer 0 devices: one containing only information about Layer 0 devices (as shown in Table 5), and the other containing only information about Layer 1 devices (as shown in Table 6). It should be understood that the latter trust table makes it easier to update the trust table when a Layer 0 or Layer 1 device is replaced.

[0396] Table 3. Trust table of ZC1

[0397] VINCertID_ZC2,CertID_ZC3,G,Cert_G^s1,Cert_G^s2,----

[0398] Table 4. ZC2 trust table

[0399] VINCertID_ZC1,CertID_ZC4,G,Cert_G^s3,Cert_G^s4,----

[0400] Table 5. A trust table for ZC1

[0401] VINCertID_ZC2,CertID_ZC3,----

[0402] Table 6. Another trust table for ZC1

[0403] VING,Cert_G^s1,Cert_G^s2,----

[0404] In some possible implementations, the trust table of the layer 0 device may also include the SN code of the layer 1 device. For example, the trust table of ZC1 may also include the SN code of ECU1 and the SN code of ECU2, and the trust table of ZC2 may also include the SN code of ECU3 and the SN code of ECU4.

[0405] Furthermore, the OEM will send a trust table to the OEM PKI server, which will sign the trust table and send it back to the OEM.

[0406] S708: The OEM / OEM PKI server sends the signature trust table to the OEM electrical inspection device.

[0407] The electronic inspection device will receive a signed trust list for each layer 0 device.

[0408] S709: The OEM electrical inspection device sends the signature trust table to the layer 0 device.

[0409] It should be understood that the OEM electrical inspection device sends the signed trust table to the corresponding layer 0 device, for example, sends the signed ZC1 trust table to ZC1 and sends the signed ZC2 trust table to ZC2.

[0410] S710, a layer 0 device stores a trust table of signatures.

[0411] For example, the trust table for ZC1 will be stored in ZC1, and so on.

[0412] In some possible implementations, a trust table containing layer 0 device information may be generated for a layer 1 device. A specific method is shown in (b) of FIG. 7 , and the method may include:

[0413] S701', the OEM electrical inspection device requests the signed public key from the layer 1 device.

[0414] S702', the layer 1 device sends the signed public key to the OEM electrical inspection device.

[0415] For example, this step may refer to the description in S702 and will not be repeated here.

[0416] S703', the OEM electrical inspection device sends the signed public key to the OEM / OEM PKI server.

[0417] For example, this step may refer to the description in S703 and will not be repeated here.

[0418] S704', the OEM / OEM PKI server verifies the signed public key, generates a trust table for the layer 1 device, and signs the trust table.

[0419] Exemplarily, the OEM verifies the signed public key and, based on the communication matrix, generates a trust table for each Tier 1 device based on the signed public key. It should be understood that the trust table includes the public key information of other Tier 0 devices that need to communicate with the Tier 1 device. For example, ECU1 will communicate with ZC1, so ECU1's trust table will include ZC1's public key (e.g., G^zc1) and VIN, as shown in Table 7. Furthermore, the trust table may include a constant point G for the generator point, which is used to calculate the public key based on the private key. In some possible implementations, the trust table may not include the constant point G for the generator point, but instead store the constant point G for the generator point in a secure environment on the Tier 0 device and / or Tier 1 device.

[0420] Table 7. Trust table of ECU1

[0421] VING,G^zc1

[0422] In some possible implementations, the trust table of a layer 1 device may further include the SN code of a layer 0 device with which it communicates. For example, the trust table of ECU1 may further include the SN code of ZC1.

[0423] Furthermore, the OEM will send a trust table to the OEM PKI server, which will sign the trust table and send it back to the OEM.

[0424] S705', the OEM / OEM PKI sends a layer 1 device signature trust table to the OEM electrical inspection device.

[0425] S706', the OEM electrical inspection device sends the layer 1 signature trust table to the layer 1 device.

[0426] It should be understood that the OEM electrical inspection device sends the signed trust table to the corresponding layer 1 device, for example, sends the signed ECU1 trust table to ECU1 and sends the signed ECU2 trust table to ECU2.

[0427] S707', the layer 1 device stores the signature trust table.

[0428] For example, the trust table for ECU1 will be stored in ECU1, and so on.

[0429] S708', the OEM electrical inspection device requests a signed certificate from the layer 0 device.

[0430] S709', the layer 0 device sends the signed certificate to the OEM electrical inspection device.

[0431] For example, this step may refer to the description in S705 and will not be repeated here.

[0432] S710', the OEM electrical inspection device sends the signed certificate to the OEM / OEM PKI server.

[0433] For example, this step may refer to the description in S706 and will not be repeated here.

[0434] S711', the OEM / OEM PKI server generates a trust table for each layer 0 device according to the signed public key and signature certificate, and signs the trust table.

[0435] For example, this step may refer to the description in S707 and will not be repeated here.

[0436] S712', the OEM / OEM PKI server sends the layer 0 device signature trust table to the OEM electrical inspection device.

[0437] The electronic inspection device will receive a signed trust list for each layer 0 device.

[0438] S713', the OEM electrical inspection device sends the layer 0 device signature trust table to the layer 0 device.

[0439] It should be understood that the OEM electrical inspection device sends the signed trust table to the corresponding layer 0 device, for example, sends the signed ZC1 trust table to ZC1 and sends the signed ZC2 trust table to ZC2.

[0440] S714', the layer 0 device stores the signed trust table.

[0441] For example, the trust table for ZC1 will be stored in ZC1, and so on.

[0442] It should be understood that in the method shown in (b) of FIG. 7 , generating a trust table (or signature trust table) for a layer 0 device may be consistent with generating a trust table for a layer 0 device in the method shown in (a) of FIG. 7 .

[0443] It should be noted that in some possible implementations, S704' to S706' need to be executed after S710', that is, after the OEM obtains the signature certificate of the Layer 0 device. For example, if the trust table generated for the Layer 1 device needs to include the signature certificate or signature certificate ID of the Layer 0 device that needs to communicate with the Layer 1 device, then S704' to S706' need to be executed after S710'.

[0444] It should also be noted that in the method shown in (a) and (b) of Figure 7, the steps performed by the electrical inspection device can also be performed by the agent unit in the above embodiment, as shown in Figures 24 and 25.

[0445] In a communication method provided by an embodiment of the present application, Layer 0 devices and Layer 1 devices can establish a "trust relationship" based on a trust table. The devices can then use the public key information contained in the trust table to authenticate other devices that need to communicate with them and establish secure communications with them. This process eliminates the need for any third-party involvement, effectively preventing security threats caused by external access.

[0446] FIG8 is a schematic flowchart of a communication method provided in an embodiment of the present application. More specifically, FIG8 (a) shows a method for calculating a PSK between a layer 0 device and a layer 1 device based on a trust table of the layer 0 device when the layer 1 device does not have a trust table. The method may include:

[0447] S801: ZC1 generates a random number v1 as a secret key, calculates a first public key based on v1, and generates a Nonce value N1 for authentication.

[0448] In some possible implementations, based on ZC1's trust table, it needs to communicate with ECU1 and vice versa. Therefore, ZC1 and ECU1 need to calculate a shared key (such as a PSK) for subsequent session encryption during communication. Exemplarily, ZC1 generates a random number v1 as a secret key and calculates a first public key G^v1 based on the random number v1. Exemplarily, the secret and public keys can be a DH key pair.

[0449] In addition, ZC1 will also generate a Nonce value N1, which will be used later to authenticate ECU 1. It should be understood that Nonce is an arbitrary or non-repeating random value that is used only once.

[0450] S802 , ZC1 sends the first public key and Nonce value N1 to ECU1 .

[0451] It should be understood that ZC1 may send the first public key and the Nonce value N1 at one time, or may send the first public key and the Nonce value N1 separately.

[0452] S803, ECU1 calculates the shared key SS.

[0453] For example, ECU1 can use the first public key and its own private key s1 to calculate the second public key G^v1s1. Further, based on the second public key, a shared key SS is calculated: SS=F(G^v1s1). Where F can be a key derivation function or a simple hash function.

[0454] S804, ZC1 calculates the shared key SS.

[0455] In some possible implementations, ZC1 determines the public key G^s1 of ECU1 according to the trust table, and then calculates the shared key SS based on the public key G^s1 of ECU1 and the random number v2: SS=F(G^v1s1).

[0456] S805, ECU1 uses the shared key SS to encrypt Nonce N1.

[0457] To authenticate and ensure that the shared key SS generated by both parties is the same, ECU1 can use SS to encrypt Nonce N1.

[0458] S806, ECU1 sends the encrypted Nonce N1 to ZC1.

[0459] S807, ZC1 decrypts the encrypted Nonce N1 using the shared key SS.

[0460] For example, ZC1 decrypts the encrypted Nonce N1 using SS to obtain N1. Successful decryption proves that ZC1 and ECU1 have the same shared key SS.

[0461] S808 , ECU1 generates a Nonce value N2.

[0462] S809, ECU1 sends Nonce value N2 to ZC1.

[0463] S810, ZC1 encrypts Nonce N2 using the shared key SS.

[0464] S811, ZC1 sends the encrypted Nonce N2 to ECU1.

[0465] S812, ECU1 decrypts the encrypted Nonce N2 using the shared key SS.

[0466] ECU1 decrypts the encrypted Nonce N2 using SS to obtain N2. Successful decryption completes mutual authentication and shared key confirmation.

[0467] S813, ECU1 saves the shared key SS.

[0468] S814, ZC1 saves the shared key SS.

[0469] It should be noted that S808 to S812 are optional. In some embodiments, S813 and S814 may be executed simultaneously or sequentially. For example, S814 may be executed before S813. S803 and S804 may also be executed simultaneously or sequentially. For example, S804 may be executed before S803, or S804 may be executed before S802 or S803.

[0470] It should be understood that the above process is the same for all Layer 0 and Layer 1 devices that need to calculate the PSK. This shared key SS will later be used to generate new session keys during vehicle operation.

[0471] In some possible implementations, when a layer 1 device stores a trust table, a method for calculating a PSK between a layer 0 device and a layer 1 device based on the trust tables of the layer 0 device and the layer 1 device may include:

[0472] S801', ZC1 generates a random number v1 as a secret key, calculates a first public key based on v1, and signs the first public key with its own private key to generate V1'.

[0473] In some possible implementations, based on ZC1's trust table, it needs to communicate with ECU1 and vice versa. Therefore, a shared key (such as a PSK) needs to be calculated between ZC1 and ECU1 for session encryption during subsequent communications. Exemplarily, ZC1 generates a random number v1 as a secret key and calculates a first public key G^v1 based on the random number v1. Exemplarily, the secret key and public key can be a DH key pair. Furthermore, ZC1 uses its own private key zc1 to sign the first public key to generate V1': V1' = Sign(G^v1, zc1).

[0474] S802', ZC1 sends V1' to ECU1.

[0475] S803', ECU1 uses the public key of ZC1 to verify V1'.

[0476] Exemplarily, ECU1 may obtain the public key of ZC1 according to the trust table.

[0477] It should be understood that when the verification of V1' is successful, it proves that the identity of ZC1 is legitimate.

[0478] S804': ECU1 generates a random number v2 as a secret key, calculates a second public key G^v2 based on v2, and signs the second public key using its own private key to generate V2'.

[0479] For example, V2′=Sign(G^v2,s1)

[0480] S805', ECU1 sends V2' to ZC1.

[0481] S806', ZC1 uses the public key of ECU1 to verify V2'.

[0482] Exemplarily, ZC1 may obtain the public key of ECU1 according to the trust table.

[0483] It should be understood that when the verification of V2' is successful, it proves that the identity of ECU1 is legitimate.

[0484] S807', ZC1 calculates the shared key SS using the public key of ECU1.

[0485] Exemplarily, ZC1 uses the public key of ECU1 and the random number v2 to calculate the shared key SS: SS=F(G^v1v2).

[0486] S808', ECU1 uses ZC1's public key to calculate the shared key SS.

[0487] For example, ECU1 uses the public key of ZC1 and the random number v1 to calculate the shared key SS: SS=F(G^v1v2).

[0488] In some possible implementations, S807' and S808' may be executed simultaneously or sequentially. For example, S808' may be executed before S807', or S808' may be executed before S802 or S804'.

[0489] It should be understood that Figure 8 uses the generation of PSK as an example for illustration. In some possible implementations, the method flow shown in Figure 8 can also be used to generate other security keys, such as diagnostic keys, secure vehicle communication SecOC keys, other application keys, etc.

[0490] 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 the PSK between layer 1 devices. It should be understood that since layer 1 devices ECU1 and ECU2 do not have each other's public key information and have no other means of mutual authentication, while layer 0 device ZC1 stores both of their public key information and information that they have communication needs, ZC1 can act as a "middleman" to assist ECU1 and ECU2 in calculating the PSK. This method may include:

[0491] 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) for ECU2.

[0492] Exemplarily, 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.

[0493] S902, ZC1 sends the public key (G^s2.v) to ECU1.

[0494] S903, ZC1 sends the public key (G^s1.v) to ECU2.

[0495] S904 , ECU1 calculates the first key (G^s2.v.s1) based on the third public key (G^s2.v) using its own key s1.

[0496] S905 , ECU2 calculates a second key (G^s1.v.s2) based on the fourth public key (G^s1.v) using its own key s2.

[0497] It should be understood that at this point, ECU1 and ECU2 have both calculated the same key value. Since ZC1 does not know ECU1's key s1 or ECU2's key s2, ZC1 cannot calculate the key G^s1.s2.v. This prevents third parties from accessing the shared key calculated by ECU1 and ECU2 based on the same key value, thereby ensuring communication security.

[0498] S906, ECU1 derives the shared key SS.

[0499] S907, ECU2 derives the shared key SS.

[0500] For example, both ECU1 and ECU2 can use the F function to calculate the DH key (i.e., the shared key SS), such as: SS = F(G^s1.s2.v). The shared key SS will be used to generate a new session key during vehicle operation.

[0501] In some possible implementations, ECU1 and ECU2 can further complete identity authentication and key confirmation by exchanging Nonce values ​​encrypted using SS. Successful decryption will complete mutual identity authentication and key confirmation.

[0502] Layer 1 and / or Layer 0 devices with the same PSK can use the PSK to authenticate each other. This pre-shared key is securely stored in secure hardware and known only to the parties involved. Once both communicating parties prove knowledge of the PSK, authentication is complete. Furthermore, they 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 possess a new session key to encrypt communications and / or calculate message authentication information.

[0503] It should be understood that Figure 9 uses the generation of PSK as an example for illustration. In some possible implementations, the method flow shown in Figure 9 can also be used to generate other security keys, such as diagnostic keys, secure vehicle communication SecOC keys, other application keys, etc.

[0504] As mentioned above, a vehicle's service life can span decades. During this time, in-vehicle devices may become damaged and require replacement. New Layer 1 devices will also require keys for secure communication, and trust tables must be updated for the new device and any other devices with which it communicates directly. It should be understood that after replacing a Layer 1 device, the key signing and trust table update process for the new Layer 1 device is similar to that for Layer 0 devices. Please refer to the description in the previous embodiment and will not be repeated here.

[0505] Considering that Layer 2 devices are resource-constrained and generally lack security hardware, their encryption capabilities are limited, and they can only exchange 8 bytes of data in a CAN frame. Therefore, these devices only require a lightweight symmetric key-based solution. Figure 10 shows a method for forming a pre-embedded trust token for a Layer 2 device (using CAN ECU1 as an example). This method may include:

[0506] S1010, activation key generation.

[0507] Illustratively, this step may refer to the description in S301 or S601 and will not be repeated here.

[0508] S1020, ZC1 generates a trust token.

[0509] Exemplarily, ZC1 generates a trust token s1 , which may be a random number or a trust token in other forms.

[0510] S1030, ZC1 sends a trust token to the OEM electrical inspection equipment.

[0511] S1040 : The OEM electrical inspection device sends a trust token to the CAN ECU1 .

[0512] S1050 , CAN ECU 1 stores the trust token.

[0513] It should be understood that both ZC1 and CAN ECU1 store the trust token s1.

[0514] In some possible implementations, before injecting the trust token into the CAN ECU1, ZC1 may authenticate the CAN ECU1 based on at least one of the SN code, physical fingerprint, authentication chip, and security chip of the CAN ECU1, and inject the trust token into the CAN ECU1 after successful authentication.

[0515] In some possible implementations, the trust token may also be generated by an electrical inspection device and then “injected” into ZC1 and CAN ECU1 respectively, ie, sent to ZC1 and CAN ECU1.

[0516] A communication method provided in an embodiment of the present application can pre-embed a trust token for a layer 2 device, avoid injecting external keys, and maximize key generation within the vehicle / component, thereby ensuring the security of communication between layer 0 devices and layer 2 devices within the vehicle.

[0517] FIG11 shows a method for forming a PSK between a layer 0 device and a layer 2 device, which may include:

[0518] S1110, ZC1 generates a random number v1 as a secret key, calculates a shared key SS based on the trust token and the random number v1, and encrypts SS using the trust token s1 to obtain SS2.

[0519] S1120, ZC1 sends SS2 to CAN ECU1.

[0520] S1130 , CAN ECU1 uses the trust token s1 to decrypt SS2 to obtain SS.

[0521] Furthermore, based on the shared key SSCAN ECU1 and ZC1 can generate new session keys during vehicle operation.

[0522] It should be noted that after CAN ECU1 obtains SS, CAN ECU1 and ZC1 can further complete identity authentication and key confirmation by exchanging Nonce values ​​encrypted using SS. Successful decryption of the Nonce value encrypted by SS completes mutual identity authentication and key confirmation. Furthermore, both CAN ECU1 and ZC1 delete the trust token s1.

[0523] In some possible implementations, the trust table of an on-board device in the above embodiment may also include service-oriented architecture (SOA) service information of other devices communicating with it. For example, ZC1 needs to communicate with ZC2 and ZC3. The SOA services supported by ZC2 include Service A, Service B, and Service C. However, the only service open to ZC1 by ZC2 is Service A. In this case, in addition to the public key information of ZC2 and ZC3, the trust table of ZC1 may also include relevant information of ZC2's Service A. It should be understood that in the above case, ZC1 can only access ZC2's Service A, but cannot access ZC2's Service B and Service C. It should be understood that the above "service" can be at least one of a device abstract service, an atomic service, a composite service, and an application service.

[0524] To facilitate readers' understanding, the following briefly introduces the concepts related to "service":

[0525] 1. SOA is an architectural design concept that decomposes a system into relatively independent functional units, which are externally referred to as services. Services can be encapsulated with abstract interfaces. Furthermore, these services communicate with each other through defined interfaces and protocols. A system's numerous services may be categorized in a layered manner. For example, low-level services may include device abstract services, atomic services, and composite services, while high-level services are referred to as applications.

[0526] 2. Atomic services: Sensors, actuators, and other abstract hardware resources are typically encapsulated as atomic services. Atomic services typically encapsulate the most basic logical functions, such as seat control and window control.

[0527] 3. Composite service is a service formed by calling and combining atomic services.

[0528] 4. Application service (or APP) 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.

[0529] 5. Device abstraction services abstract hardware resources such as sensors and actuators, providing device access interfaces to atomic services. Device abstraction services typically encapsulate electrical signals, such as motor power signals and Hall effect signals.

[0530] An embodiment of the present application provides a communication method that, during the vehicle generation phase, applies for a certificate associated with a vehicle identity (e.g., VIN) for each Layer 0 device and Layer 1 device to ensure that the device is uniquely associated with the vehicle it is in. Furthermore, a device trust table is issued for each device based on the device's certificate to ensure that only legitimate devices can access it. Specifically, Layer 0 devices form a Layer 0 device trust ring based on this trust table, as shown in Figure 12. Each device in the ring can provide different services to those outside the ring. For example, the Layer 0 device trust ring can provide vehicle integration unit (VIU) atomic services, VDC enhanced services, MDC enhanced services, etc. Layer 0 devices can also further assist Layer 1 devices and Layer 2 devices in establishing trust rings between Layer 1 devices and between Layer 2 devices, respectively. In some possible implementations, Layer 0 devices can also assist external devices connected to the vehicle in establishing trust rings. Furthermore, at device startup, the device's legitimacy is verified using the device certificate and trust table. Once verified, a session key is distributed and periodically refreshed to improve the security of the session key. When secure communication is required for business, session keys are used to establish secure communication and ensure the confidentiality and integrity of the communication data. In a communication method provided by an embodiment of the present application, the generated session keys are closed-loop within the vehicle, which can significantly reduce the risk of key leakage and reduce the complexity of key management.

[0531] FIG13 shows a schematic flow chart of a communication method 1300 provided in an embodiment of the present application. The method 1300 can be applied to the vehicle shown in FIG1 or executed by the ZC in the system shown in FIG2. The method 1300 includes:

[0532] S1310: A first node receives a first message from a first device, where the first message includes second node information, where the second node information is used to indicate the second node.

[0533] S1320: The first node determines the second node according to the second node information;

[0534] S1330: The first node generates a security key with the second node;

[0535] S1340: The first node communicates with the second node according to the security key.

[0536] Exemplarily, the first node can be any layer 0 device in the above embodiments, such as ZC1; the second node can be a layer 0 device in the above embodiments (such as ZC2), or it can also be a layer 1 device in the above embodiments (such as ECU1); the first node and the second node can be set in a first terminal, which can be the vehicle in the above embodiments, or it can also be other terminals.

[0537] Exemplarily, 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 of nodes that have communication needs with the first node.

[0538] Exemplarily, 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-mentioned embodiment, or may also include other forms of the second node's public key information. It should be noted that when the second node information includes the second node's public key hash, the second node information also includes the second node's identity information. Exemplarily, the second node's identity information may be the second node's SN code, or may be other information that can indicate the second node's identity.

[0539] Exemplarily, the first device can be the OEM PKI server in the above embodiment, or it can be a computing platform in the first terminal, such as at least one of VDC, MDC, and CDC, or it can 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.

[0540] Exemplarily, the security key may be the PSK in the above embodiment.

[0541] Exemplarily, the method for generating the first message can refer to the description in the above embodiment and will not be repeated here; the method for the first node to generate a security key between the first node and the second node can refer to the description in the above embodiment and will not be repeated here.

[0542] Exemplarily, the first node communicating with the second node according to the security key may include: the first node generating a session key for communicating with the second node according to the security key, and then encrypting the communication content between the first node and the second node according to the session key.

[0543] In some possible implementations, method 1300 may further include other methods in FIG. 3 to FIG. 11 that are performed by a layer 0 device.

[0544] A communication method provided in an embodiment of the present application 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 identities through the first message. Once the verification is successful, a shared security key is negotiated. The shared security key is used to generate a session key for each communication. When secure communication is required for a business, the session key is used to establish secure communication, helping to ensure the confidentiality and integrity of the communication data.

[0545] FIG14 shows a schematic flow chart of a communication method 1400 provided in an embodiment of the present application. The method 1400 includes:

[0546] S1410. The second device receives a first message sent by the first device. The first message includes second node information, where the second node information is used to indicate the second node.

[0547] Exemplarily, the second device may be the OEM in the above embodiment. More specifically, the second device may be an OEM TSP.

[0548] S1420: The second device sends a first message to the first node.

[0549] Exemplarily, the second device sends the first message to the first node via the electrical inspection device.

[0550] In some possible implementations, method 1400 may further include other methods shown in FIG. 3 to FIG. 11 , which are performed by the OEM's equipment.

[0551] In a communication method provided by an embodiment of the present application, an OEM establishes a trust relationship between a first node and a second node by sending a first message containing information about a second node to the first node. This facilitates the generation of a session key based on the first message. Furthermore, when secure communication is required for a business, the session key is used to establish secure communication, helping to ensure the confidentiality and integrity of the communication data.

[0552] FIG15 shows a schematic flow chart of a communication method 1500 provided in an embodiment of the present application. The method 1500 includes:

[0553] S1510, the first device receives a second message sent by the second device;

[0554] Exemplarily, the second message may be the trust table in the above embodiment, or may be a whitelist in other forms containing information of nodes that have communication requirements with the first node.

[0555] Exemplarily, the second message is generated by the second device according to the communication list and the signature public key of the first node.

[0556] Exemplarily, the communication list may include the communication matrix in the above embodiment.

[0557] S1520: The first device signs the second message to generate a first message;

[0558] Exemplarily, the specific method of signing the second message to generate the first message can refer to the description in the above embodiment and will not be repeated here.

[0559] S1530: The first device sends the first message to the first node.

[0560] In some possible implementations, method 1500 may further include other methods in FIG. 3 to FIG. 11 , which are performed by the OEM PKI server.

[0561] In a communication method provided by an embodiment of the present application, a first device generates a signature trust table by signing a trust table, so that the signature trust table cannot be easily changed by other devices, which helps to further improve communication security.

[0562] FIG16 shows a schematic flow chart of a communication method 1600 provided in an embodiment of the present application. The method 1600 includes:

[0563] S1610: The electrical inspection device receives a first message sent by a first device, where the first message includes second node information, where the second node information is used to indicate the second node.

[0564] Illustratively, the electrical inspection device may be the electrical inspection device in the above embodiment.

[0565] S1620: The electrical inspection device sends the first message to the first node.

[0566] In some possible implementations, method 1600 may further include other methods performed by the electrical inspection device in FIG. 3 to FIG. 11 .

[0567] FIG26 shows a schematic flow chart of a communication method 1600′ provided in an embodiment of the present application. The method 1600′ includes:

[0568] S1610': The agent unit receives 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.

[0569] Exemplarily, the agent unit may be the agent unit in the above embodiment.

[0570] S1620': The agent unit sends the first message to the first node.

[0571] In some possible implementations, method 1600' may further include other methods in FIG. 20 to FIG. 25 that are performed by the agent unit.

[0572] In a communication method provided by an embodiment of the present application, an electrical inspection device or agent unit establishes a "trust relationship" between the first and second nodes by sending a first message containing information about the second node to the first node. This facilitates the first and second nodes to generate a session key based on the first message. Furthermore, when secure communication is required for a business, the use of the session key helps ensure the confidentiality and integrity of the communication data.

[0573] FIG17 shows a schematic flow chart of a communication method 1700 provided in an embodiment of the present application. The method 1700 includes:

[0574] S1710: Receive a first public key, where the first public key is generated by a first node according to a first message. The first message includes second node information, where the second node information is used to indicate the second node.

[0575] S1720, the second node generates a security key based on the first public key, and the security key is used for encrypting a session between the first node and the second node; or, the security key is used for encrypting a session between the second node and a third node.

[0576] Illustratively, the second node may be a layer 1 device having a communication requirement with the first node in the above embodiment; the third node may be a layer 1 device having a communication requirement with the second node in the above embodiment.

[0577] Exemplarily, 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.

[0578] Exemplarily, the security key may be the shared key SS in the above embodiment.

[0579] In some possible implementations, method 1700 may further include other methods performed by a layer 1 device in FIG. 3 to FIG. 11 .

[0580] An embodiment of the present application provides a communication method in which a layer 1 device can generate a security key based on a first key public key sent by a layer 0 device. The security key can be used to generate a session key required for communicating with a layer 0 device or a layer 1 device, thereby helping to ensure the confidentiality and integrity of communication data.

[0581] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between the various embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0582] The method provided in the embodiments of the present application is described in detail above with reference to Figures 3 to 17 . The apparatus provided in the embodiments of the present application will be described in detail below with reference to Figures 18 and 19 . It should be understood that the description of the apparatus embodiment corresponds to the description of the method embodiment. Therefore, for matters not described in detail, reference can be made to the method embodiment above, and for the sake of brevity, no further description will be given here.

[0583] FIG18 shows a schematic block diagram of a communication device 2000 provided in an embodiment of the present application. The device 2000 includes a transceiver unit 2010 and a processing unit 2020 .

[0584] Optionally, the device 2000 may further include a storage unit, which may be used to store instructions and / or data. The processing unit 2020 may read the instructions and / or data in the storage unit so that the device implements the aforementioned method embodiment.

[0585] The apparatus 2000 may include units for executing the methods in Figures 13 to 17. Furthermore, the units in the apparatus 2000 and the other operations and / or functions described above are for implementing corresponding processes of the method embodiments in Figures 13 to 17.

[0586] When the device 2000 is used to execute the method 1300 in FIG. 13 , the transceiver unit 2010 may be used to execute S1310 in the method 1300 , and the processing unit 2020 may be used to execute S1320 to S1340 in the method 1300 .

[0587] The apparatus 2000 includes: a transceiver unit 2010, for receiving a first message from a first device, the first message including second node information, the second node information being used to indicate the second node; a processing unit 2020, for determining the second node based on the second node information; generating a security key between the second node and the second node; and communicating with the second node based on the security key.

[0588] In some possible implementations, the processing unit 2020 is specifically used to: when the second node stores first node information indicating the first node, the first node generates a security key based on the second node information, and the security key is used to encrypt the session between the first node and the second node.

[0589] In some possible implementations, the processing unit 2020 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.

[0590] In some possible implementations, the processing unit 2020 is also used to generate a second random number; generate a first public key based on the first random number; the transceiver unit 2010 is also used to send the second random number and the first public key to the second node; receive a first encrypted value, which is obtained by the second node encrypting the second random number based on a first security key, and the first security key is generated based on the secret key of the second node and the first public key; the processing unit 2020 is also used to decrypt the first encrypted value based on the security key; when the first encrypted value is decrypted successfully, the security key is stored.

[0591] In some possible implementations, the processing unit 2020 is also used to: generate a third random number; generate a second key public key based on the third random number; the transceiver unit 2010 is also used to send a first signature generated based on the private key of the first node and the second key public key to the second node; receive a second signature, which is generated based on the private key and the third key public key of the second node after the second node successfully verifies the first signature, and 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 second signature is successfully verified, the first node generates the security key based on the third key public key and the third random number.

[0592] In some possible implementations, the transceiver unit 2010 is also used 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 used to generate a fifth random number; generate a fourth key public key based on the fifth random number and the second node information; generate a fifth key public key based on the fifth random number and the third node information; the transceiver unit 2010 is also used to send the fifth key public key to the second node; and send the fourth key public key to the third node.

[0593] In some possible implementations, the transceiver unit 2010 is further configured to: before receiving the first message, send the signature public key of the first node to the second device, where the signature public key of the first node is used to generate the first message.

[0594] In some possible implementations, the second node information includes public key information of the second node.

[0595] In some possible implementations, 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 identification number ID of the public key signature certificate of the second node; the hash value of the public key of the second node and the identity information of the second node.

[0596] In some possible implementations, 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 services in the second node that can be accessed by the first node.

[0597] In some possible implementations, 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 program keys.

[0598] In some possible implementations, 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 based on 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 decrypts the trust token pre-stored to obtain the second security key, and the second security key is used to encrypt the session between the first node and the fourth node.

[0599] In some possible implementations, the processing unit 2020 is also used to: before the transceiver unit 2010 sends the trust token to the fourth node, authenticate the fourth node based on at least one of the serial number SN, physical fingerprint, authentication chip, and security chip of the fourth node; the transceiver unit 2010 is specifically used to: when the authentication is successful, send the trust token to the fourth node.

[0600] In some possible implementations, the processing unit 2020 is further 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.

[0601] The apparatus 2000 may also be used to execute the method in FIG14. When the apparatus 2000 is used to execute the method 1400 in FIG14, the transceiver unit 2010 may be used to execute S1410 and S1420 in the method 1400.

[0602] The apparatus 2000 includes: a transceiver unit 2010, configured to receive a first message sent by a first device, the first message including second node information, the second node information being used to indicate the second node; and send the first message to the first node.

[0603] In some possible implementations, the apparatus 2000 further includes a processing unit configured to: generate a second message based on a communication list and a signature public key of the first node before the transceiver unit receives a first message sent by the first device, wherein the communication list is used to indicate that the first node and the second node need to communicate; and the transceiver unit 2010 is further configured to send the second message to the first device.

[0604] The apparatus 2000 may also be used to execute the method in Figure 15. When the apparatus 2000 is used to execute the method 1500 in Figure 15, the transceiver unit 2010 may be used to execute S1510 and S1530 in the method 1500, and the processing unit 2020 may be used to execute S1520 in the method 1500.

[0605] The apparatus 2000 includes: a transceiver unit 2010 for receiving a second message sent by a second device; a processing unit 2020 for signing the second message to generate a first message; and the transceiver unit 2010 is further used to send the first message to the first node.

[0606] The apparatus 2000 may also be used to execute the method in FIG16. When the apparatus 2000 is used to execute the method 1600 in FIG16, the transceiver unit 2010 may be used to execute S1610 and S1620 in the method 1600.

[0607] The apparatus 2000 includes: a transceiver unit 2010, configured to receive a first message sent by a first device, the first message including second node information, the second node information being used to indicate the second node; and send the first message to the first node.

[0608] In some possible implementations, the transceiver unit 2010 is further configured to: receive a signature public key of the first node sent by a third device; and send the signature public key of the first node to the first node.

[0609] In some possible implementations, 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 an equipment vendor server.

[0610] When the apparatus 2000 is used to execute the method 1600 ′ in FIG. 16 , the transceiver unit 2010 may be used to execute S1610 ′ and S1620 ′ in the method 1600 ′.

[0611] The apparatus 2000 includes: a transceiver unit 2010, configured to receive a first message sent by a first device, the first message including second node information, the second node information being used to indicate the second node; and send the first message to the first node.

[0612] In some possible implementations, the transceiver unit 2010 is further configured to: receive the signature public key of the first node sent by the first node; and send the signature public key of the first node to the first device.

[0613] In some possible implementations, the transceiver unit 2010 is further configured to: receive the signature public key of the first node sent by the first node; and send the signature public key of the first node to the second device.

[0614] In some possible implementations, the device 2000 also includes a processing unit 2020, and the transceiver unit 2010 is also used to: receive a first signal from the electrical inspection equipment; the processing unit 2020 is used to control the transceiver unit 2010 to send a request information to the first node according to the first signal, and the request information is used to request the signature public key of the first node.

[0615] The apparatus 2000 may also be used to execute the method in Figure 17. When the apparatus 2000 is used to execute the method 1700 in Figure 17, the transceiver unit 2010 may be used to execute S1710 in the method 1700, and the processing unit 2020 may be used to execute S1720 in the method 1700.

[0616] The device 2000 includes: a transceiver unit 2010, used to receive a first public key, where the first public key is generated by a first node based on a first message, where the first message includes second node information, where the second node information is used to indicate the second node; a processing unit 2020, used to generate a security key based on the first public key, where the security key is used to encrypt a session between the first node and the second node; or, the security key is used to encrypt a session between the second node and a third node.

[0617] In some possible implementations, the first key public key is the key public key signed with the private key of the first node, and the processing unit 2020 is further used to: determine the public key of the first node based on the first message; verify the first key public key based on the public key of the first node; generate a fifth random number; and when the verification is successful, generate a security key based on the first key public key and the fifth random number.

[0618] It should be understood that the division of the various units in the above device is merely a division of logical functions. In actual implementation, they may be fully or partially integrated into a single physical entity, or they may be physically separated. Furthermore, the units in the device may be implemented in the form of a processor calling software; for example, the device includes a processor connected to a memory storing instructions, and the processor calls the instructions stored in the memory to implement any of the above methods or the functions of the various units in the device. The processor may be a general-purpose processor, such as a CPU or a microprocessor, and the memory may be a memory within the device or external to the device. Alternatively, the units in the device may be implemented in the form of hardware circuits, and the functions of some or all of the units may be implemented through the design of the hardware circuits. The hardware circuits may be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all of the above units may be implemented through the design of the logical relationships between the components within the circuits. In another implementation, the hardware circuit may be implemented using a PLD, such as an FPGA, which may include a large number of logic gate circuits. The connections between the logic gate circuits are configured using a configuration file to implement the functions of some or all of the above units. All units of the above apparatus may be implemented entirely in the form of software called by a processor, or entirely in the form of hardware circuits, or partially in the form of software called by a processor and the rest in the form of hardware circuits.

[0619] In an embodiment of the present application, a processor is a circuit with the ability to process signals. In one implementation, the processor may be a circuit with the ability to read and execute instructions, such as a CPU, a microprocessor, a GPU, or a DSP. In another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit may be fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the configuration of the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, DPU, etc.

[0620] It can be seen that 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.

[0621] In addition, the various units in the above devices can be fully or partially integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the various units of the device. The type of the at least one processor can be different, for example, including a CPU and FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

[0622] Figure 19 is a schematic block diagram of a communication device according to an embodiment of the present application. The communication device 2100 shown in Figure 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 via an internal connection path. The memory 2130 is used to store instructions, and the processor 2110 is used to execute the instructions stored in the memory 2130 to receive / send some parameters through the transceiver 2120. Optionally, the memory 2130 may be coupled to the processor 2110 via an interface or may be integrated with the processor 2110.

[0623] It should be noted that the transceiver 2120 may include but is not limited to a transceiver device such as an input / output interface to implement communication between the device 2100 and other devices or a communication network.

[0624] During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 2110 or by instructions in the form of software. The method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 2130, and 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.

[0625] The processor 2110 can be a general-purpose CPU, microprocessor, ASIC, GPU, or one or more integrated circuits, configured to execute relevant programs to implement the communication methods of the embodiments of the present application. The processor 2110 can also be an integrated circuit chip with signal processing capabilities. In specific implementations, the various steps of the communication methods of the present application can be performed by hardware integrated logic circuits or software instructions within the processor 2110. The 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. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules can be located in storage media well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 2130, and the processor 2110 reads the information in the memory 2130 and executes the communication method of the embodiment of the method of the present application in combination with its hardware.

[0626] The memory 2130 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM).

[0627] 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 a communication network.

[0628] An embodiment of the present application further provides a communication system, which includes the above-mentioned device 2000 or the above-mentioned device 2100.

[0629] The present application also provides a vehicle. In some possible implementations, the vehicle may include the aforementioned apparatus 2000 or apparatus 2100. For example, when apparatus 2000 (or apparatus 2100) is an apparatus for executing the method in FIG. 13 or FIG. 17 , the vehicle may include the aforementioned apparatus 2000 (or apparatus 2100).

[0630] The present application also provides a terminal device. In some possible implementations, the terminal device may include the aforementioned apparatus 2000 or the aforementioned apparatus 2100. For example, when the apparatus 2000 (or apparatus 2100) is an apparatus for executing the method in FIG. 14 , FIG. 15 , or FIG. 16 , the terminal device may include the aforementioned apparatus 2000 (or apparatus 2100).

[0631] An embodiment of the present application further provides a computer-readable medium storing a program code. When the computer program code is executed on a computer, the computer executes the methods in FIG. 3 to FIG. 17 .

[0632] An embodiment of the present application also provides a chip, comprising: at least one processor and a memory, wherein the at least one processor is coupled to the memory and is used to read and execute instructions in the memory to execute the methods in Figures 3 to 17 above.

[0633] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0634] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0635] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0636] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0637] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0638] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0639] If 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. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, 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 and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0640] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method, characterized in that: include: The first node receives a first message from a first device, where the first message includes second node information, where the second node information is used to indicate the second node; The first node determines the second node according to the second node information; The first node generates a security key with the second node; The first node communicates with the second node according to the security key.

2. The method according to claim 1, wherein The first node generating a security key with the second node, including: 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, and the security key is used for encrypting a session between the first node and the second node.

3. The method according to claim 1 or 2, wherein: The method further comprises: The first node generates a first random number; The first node generating a security key with the second node, including: The first node generates the security key according to the first random number and the second node information.

4. The method according to claim 3, wherein The method further comprises: 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 a first encrypted value, where the first encrypted value is obtained by the second node encrypting the second random number using a first security key, where the first security key is generated using a secret key of the second node and the first public key; Decrypting, by the first node, the first encrypted value according to the security key; When decryption of the first encrypted value is successful, the first node stores the security key.

5. The method according to claim 1 or 2, wherein: The method further comprises: 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 a first signature generated according to the private key of the first node and the second public key to the second node; The first node receives a second signature, where the second signature is generated based on the second node's private key and a third public key after the second node successfully verifies the first signature, where the third public key is generated based on a fourth random number generated by the second node; The first node verifies the second signature according to the second node information; The first node generating a security key with the second node, including: When the second signature is successfully verified, the first node generates the security key according to the third public key and the third random number.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: The first node receives, from the first device, third node information indicating a third node and information indicating that the second node and the third node need to communicate; The first node generates a fifth random number; The first node generates a fourth public key according to the fifth random number and the second node information; The first node generates a fifth public key according to the fifth random number and the third node information; The first node sends the fifth public key to the second node; The first node sends the fourth public key to the third node.

7. The method according to any one of claims 1 to 6, characterized in that Before the first node receives the first message, the method further includes: The first node sends the signature public key of the first node to the second device, where the signature public key of the first node is used to generate the first message.

8. The method according to any one of claims 1 to 7, characterized in that Before the first node receives the first message, the method further includes: The first node sends the signature public key of the first node to the fourth device, where the signature public key of the first node is used to generate the first message.

9. The method according to any one of claims 1 to 7, characterized in that The second node information includes public key information of the second node.

10. The method according to claim 9, wherein 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 identity ID of the second node; A hash value of the public key of the second node and the identity information of the second node.

11. The method according to any one of claims 1 to 10, characterized in that The method further comprises: The first node receives service information of the second node from the first device, where the service information of the second node is used to indicate a service in the second node that the first node can access.

12. The method according to any one of claims 1 to 11, characterized in that 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 program keys.

13. The method according to any one of claims 1 to 12, characterized in that The method further comprises: The first node generates a trust token; The first node sends the trust token to the fourth node; The first node generates a sixth random number; The first node generates a second security key based on the trust token and the sixth random number; The first node sends a second security key encrypted by a trust token to the fourth node, so that the fourth node decrypts the second security key according to the trust token stored in advance, and the second security key is used for session encryption between the first node and the fourth node.

14. The method according to claim 13, wherein Before the first node sends the trust token to the fourth node, the method further includes: The first node authenticates the fourth node according to at least one of a serial number SN, a physical fingerprint, an authentication chip, and a security chip of the fourth node; The first node sending the trust token to the fourth node includes: When the authentication is successful, the first node sends the trust token to the fourth node.

15. The method according to claim 13 or 14, characterized in that The method further comprises: The first node performs identity authentication on the fourth node based on the second security key; When the identity authentication passes, the first node deletes the trust token.

16. A communication method, characterized in that: include: The second device receives a first message sent by the first device, where the first message includes second node information, where the second node information is used to indicate the second node; The second device sends the first message to the first node.

17. The method according to claim 16, wherein Before the second device receives the first message sent by the first device, the method further includes: The second device generates a second message according to a communication list and a signature public key of the first node, wherein 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.

18. The method according to claim 16, wherein The second device is an electrical inspection device, and the method further includes: The second device receives 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.

19. A communication method, characterized in that: include: The first device receives a second message sent by the second device; The first device signs the second message to generate a first message; The first device sends the first message to the first node.

20. A communication method, characterized in that: include: The second node receives a first public key, where the first public key is generated by the first node according to a first message, where the first message includes second node information, where the second node information is used to indicate the second node; The second node generates a security key based on the first key public key, and the security key is used for session encryption between the first node and the second node; or, the security key is used for session encryption between the second node and a third node.

21. The method according to claim 20, wherein The first public key is a public key signed by the private key of the first node, and the method further includes: The second node determines the public key of the first node according to the first message; The second node verifies the first secret public key according to the public key of the first node; The second node generates a fifth random number; The second node generates a security key according to the first public key, including: When the verification is successful, the second node generates a security key according to the first public key and the fifth random number.

22. A first node, characterized in that: include: a transceiver unit, configured to receive a first message from a first device, where the first message includes second node information, where 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; generating a security key between the node and the second node; Communicate with the second node based on the security key.

23. The first node according to claim 22, wherein: The processing unit 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, and the security key is used for encrypting a session between the first node and the second node.

24. The first node according to claim 22 or 23, characterized in that The processing unit is further configured to: generating a first random number; The security key is generated according to the first random number and the second node information.

25. The first node according to claim 24, wherein: The processing unit is further configured to: generating a second random number; Generate a first public key according to the first random number; The transceiver unit is further configured to send the second random number and the first public key to the second node; receiving a first encrypted value, where the first encrypted value is obtained by the second node encrypting the second random number using a first security key, where the first security key is generated using a secret key of the second node and the first public key; The processing unit is further configured to decrypt the first encrypted value according to the security key; When the first encrypted value is successfully decrypted, the security key is stored.

26. The first node according to claim 22 or 23, characterized in that The processing unit is further configured to: generating a third random number; Generate a second public key according to the third random number; The transceiver unit is further configured to send a first signature generated based on the private key of the first node and the second public key to the second node; receiving a second signature, where the second signature is generated by the second node based on the private key of the second node and a third public key after the second node successfully verifies the first signature, where the third public key is generated based on a fourth random number generated by the second node; The processing unit is further configured to verify the second signature according to the second node information; When the second signature is successfully verified, the first node generates the security key according to the third public key and the third random number.

27. The first node according to any one of claims 22 to 26, characterized in that The transceiver unit is further configured to: receiving, from the first device, third node information indicating a third node and information indicating that the second node and the third node need to communicate; The processing unit is further 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 public key according to the fifth random number and the third node information; The transceiver unit is further configured to send the fifth public key to the second node; The fourth public key is sent to the third node.

28. The first node according to any one of claims 22 to 27, characterized in that The transceiver unit is further configured to: Before receiving the first message, the signature public key of the first node is sent to the second device, where the signature public key of the first node is used to generate the first message.

29. The first node according to any one of claims 22 to 28, characterized in that The transceiver unit is further configured to: Send the signature public key of the first node to the fourth device, where the signature public key of the first node is used to generate the first message.

30. The first node according to any one of claims 22 to 29, characterized in that The second node information includes public key information of the second node.

31. The first node according to claim 30, wherein: 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 identity ID of the second node; A hash value of the public key of the second node and the identity information of the second node.

32. The first node according to any one of claims 22 to 31, characterized in that The transceiver unit is further configured to: The service information of the second node is received from the first device, where the service information of the second node is used to indicate a service in the second node that the first node can access.

33. The first node according to any one of claims 22 to 32, characterized in that 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 program keys.

34. The first node according to any one of claims 22 to 33, characterized in that The processing unit is further configured to: Generate a trust token; The transceiver unit is further configured to send the trust token to the fourth node; The processing unit is further configured to generate a sixth random number; generating a second security key based on the trust token and the sixth random number; The transceiver unit is also used to send a second security key encrypted by a trust token to the fourth node, so that the fourth node decrypts the second security key according to the trust token stored in advance to obtain the second security key, and the second security key is used to encrypt the session between the first node and the fourth node.

35. The first node according to claim 34, wherein: The processing unit is further configured to: Before sending the trust token to the fourth node, the transceiver unit authenticates the fourth node according to at least one of the authentication code SN, physical fingerprint, authentication chip, and security chip of the fourth node; The transceiver unit is specifically configured to send the trust token to the fourth node when the authentication is successful.

36. The first node according to claim 34 or 35, characterized in that The processing unit is further configured to: authenticating the fourth node based on the second security key; When the identity authentication is passed, the trust token is deleted.

37. A second device, characterized in that: include: a transceiver unit, configured to receive a first message sent by a first device, where the first message includes second node information, where the second node information is used to indicate the second node; Send the first message to the first node.

38. The second device according to claim 37, wherein The second device further includes a processing unit, configured to: Before the transceiver unit receives the first message sent by the first device, generating a second message according to the communication list and the signature public key of the first node, wherein the communication list is used to indicate that the first node and the second node need to communicate; The transceiver unit is further configured to send the second message to the first device.

39. The second device according to claim 37, wherein When the second device is an electrical inspection device, the transceiver unit is further configured to: Receiving the signature public key of the first node sent by the third device; Send the signature public key of the first node to the first node.

40. A first device, characterized in that include: a transceiver unit, configured to receive a second message sent by a second device; a processing unit, configured to sign the second message to generate a first message; The transceiver unit is further configured to send the first message to the first node.

41. A second node, characterized in that: include: a transceiver unit, configured to receive a first public key, where the first public key is generated by the first node according to a first message, where the first message includes second node information, where the second node information is used to indicate the second node; A processing unit is configured to generate a security key based on the first key public key, wherein the security key is used for encrypting a session between the first node and the second node; or, the security key is used for encrypting a session between the second node and a third node.

42. The second node according to claim 41, wherein: The first public key is a public key signed by the private key of the first node, and the processing unit is further configured to: determining a public key of the first node according to the first message; verifying the first secret public key based on the public key of the first node; generating a fifth random number; When the verification is successful, the first public key and the fifth random number generate a security key.

43. A communication device, characterized in that include: memory for storing computer programs; A processor, configured to execute the computer program stored in the memory, so that the apparatus performs the method according to any one of claims 1 to 15, or the method according to claim 20 or 21.

44. A communication device, characterized in that include: memory for storing computer programs; A processor, configured to execute the computer program stored in the memory, so that the apparatus performs the method according to any one of claims 16 to 19.

45. A communication system, characterized in that The system comprises a first node according to any one of claims 22 to 36 and a second node according to claim 41 or 42.

46. ​​The system of claim 45, wherein: The first node generates a first random number, and generates a security key according to the first random number and second node information, wherein the second node 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, generates a first security key according to the private key of the second node and the first public key, and encrypts the second random number according to the first security key to obtain a first encrypted 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; When the first node successfully decrypts the first encrypted value, the first node stores the security key.

47. The system of claim 46, wherein: The first node generates a third random number, and generates a second public key according to the third random number; The first node sends a first signature generated according to the private key of the first node and the second public key to the second node; The second node receives the first signature, generates a fourth random number, and generates a third public key based on the fourth random number. 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 public key, and sends the second signature to the first node. The second node generates a third security key according to the fourth random number and the second public key; The first node receives the second signature and verifies the second signature according to the second node information. When the second signature is successfully verified, a fourth security key is generated according to the third key public key and the third random number.

48. The system according to any one of claims 45 to 47, wherein The system further comprises the first apparatus of claim 40, the second node comprising a first device and a second device; The first node receives, from the first device, first device information indicating a first apparatus, second device information indicating a second apparatus, and information indicating that the first apparatus and the second apparatus need to communicate; The first 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 public key 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 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 the sixth security key based on the second device's private key and the fourth public key.

49. A vehicle, characterized in that The method comprises the first node according to any one of claims 22 to 36, and / or the second node according to any one of claims 41 and 42, and / or the communication device according to claim 43.

50. A terminal device, characterized in that: The method comprises the second device according to claims 37 to 39, or the first device according to claim 40, or the communication apparatus according to claim 44.

51. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is executed by a computer, the method according to any one of claims 1 to 21 is implemented.

52. A chip, characterized in that: The chip includes a processor and a data interface, and the processor reads instructions stored in a memory through the data interface to execute the method according to any one of claims 1 to 21.

53. A communication method, characterized in that: include: The fourth device receives a first message sent by the first device, where the first message includes second node information, where the second node information is used to indicate the second node; The fourth device sends the first message to the first node.

54. The method of claim 53, wherein: The method further comprises: The fourth device receives the public key of the first node sent by the first node, where the public key of the first node is used to generate a signature public key of the first node; The fourth device sends the public key of the first node to the first device.

55. The method according to claim 53 or 54, wherein The method further comprises: The fourth device receives the signature public key of the first node sent by the first node; The fourth device sends the signature public key of the first node to the second device.

56. The method according to claim 54 or 55, wherein Before the fourth device receives the signature public key of the first node sent by the first node, the method further includes: The fourth device receives the first signal from the electrical detection device; The fourth device sends request information to the first node according to the first signal, where the request information is used to request the public key of the first node.

57. A fourth device, characterized in that include: a transceiver unit, configured to receive a first message sent by a first device, where the first message includes second node information, where the second node information is used to indicate the second node; The fourth device sends the first message to the first node.

58. The fourth device according to claim 57, characterized in that The transceiver unit is further configured to: receiving a public key of the first node sent by the first node, where the public key of the first node is used to generate a signature public key of the first node; The public key of the first node is sent to the first device.

59. The fourth device according to claim 57 or 58, characterized in that The transceiver unit is further configured to: Receiving the signature public key of the first node sent by the first node; Send the signature public key of the first node to the second device.

60. The fourth device according to claim 58 or 59, characterized in that The fourth device further includes a processing unit, and the transceiver unit is further configured to: receiving a first signal from an electrical inspection device; The processing unit is used to control the transceiver unit to send request information to the first node according to the first signal, where the request information is used to request the public key of the first node.

61. A communication system, characterized in that The system includes a first node and a fourth device, wherein: The first node sends a signature public key of the first node to a fourth device, where the signature public key of the first node is used to generate the first message, where the first message includes second node information, where the second node information is used to indicate the second node; The fourth device sends the first message to the first node.

62. The system of claim 61, wherein: Before the first node sends the signature public key of the first node to the fourth device, the fourth device receives a first signal from the electrical inspection device, and the fourth device sends a request message to the first node according to the first signal, where the request message is used to request the signature public key of the first node.

63. A communication system, characterized in that The system includes a second device, wherein The second device receives a signature public key of the first node sent by the first node, where the signature public key of the first node is used to generate a first message, where the first message includes second node information, and the second node information is used to indicate the second node; The second device sends the first message to the first node.

64. The system of claim 63, wherein: The system further includes a first device, The second device generates a second message according to a communication list and a signature public key of the first node, wherein 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; The first device signs the second message to generate the first message, and sends the first message to the second device.

Images