COMMUNICATION METHOD, APPARATUS, AND SYSTEM

Abstract

The present application provides a communication method, apparatus, and system. The method may include: a first node receiving a first message from a first device, the first message including second node information, the second node information indicating the second node; the first node determining the second node based on the second node information; the first node generating a security key between the first node and the second node; and the first node communicating with the second node based on the security key. The communication method provided in the present application helps ensure confidentiality and integrity of communication data without introducing an external connection.

Description

[Technical Field]

[0001] This application claims priority to PCT International Application No. PCT / CN2022 / 112474, entitled "COMMUNICATION METHOD, APPARATUS, AND SYSTEM," filed with the State Intellectual Property Office of China on August 15, 2022, the entire contents of which are incorporated herein by reference.

[0002] The present application relates to the field of security, and more particularly to communication methods, devices, and systems. [Background technology]

[0003] Electronic control units (ECUs) and / or electronic control modules (ECMs) are embedded systems within a vehicle's electronic devices that are configured to control one or more electrical systems or subsystems within the vehicle.

[0004] Vehicle control units need to communicate with each other to perform vehicle operations. The communication content includes key operations that affect the security of the vehicle. Tampering with the communication content can have serious consequences, and in the worst case, it can even result in the loss of life of the user or other users in the vehicle. Therefore, an encryption key is usually injected into two vehicle control units that have communication requirements so that the two communicating parties can encrypt the communication content. However, this communication method is not secure enough. Summary of the Invention [Means for solving the problem]

[0005] The present application provides a communication method and apparatus for improving communication security between communication nodes.

[0006] According to a first aspect, there is provided a communication method, which may be performed by a control unit or control module in a vehicle, or by a chip or circuit used in a control unit or control module of a vehicle, which is not a limitation of the present application.

[0007] The method may include: a first node receiving a first message from a first device, the first message including second node information, the second node information indicating the second node; the first node determining the second node based on the second node information; the first node generating a security key between the first node and the second node; and the first node communicating with the second node based on the security key.

[0008] In some possible implementations, a first node receives a first message from a first device, the first message including second node information, the second node information indicating the second node and indicating that the first node is to communicate with the second node.

[0009] In some possible implementations, the first node receives the first message transmitted by the first device via one or more devices, for example, the first node receives the first message transmitted by the first device via an electrical inspection device or a proxy unit of a vehicle.

[0010] In some possible implementations, the first node and the second node may be nodes within a first terminal, for example, the first terminal may be a vehicle or another terminal device.

[0011] It should be appreciated that the first node may learn with which second node it needs to communicate by using the first message.

[0012] In some possible implementations, the first node may be a device having security hardware, such as a zone controller (ZC), a telecommunication unit (TCU), an in-vehicle infotainment (IVI), or an advanced driver assistance system (ADAS), and the second node may be a device having security hardware, such as a ZC, a TCU, an IVI, or an ADAS in the above-mentioned embodiments, or a device having 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.

[0013] In some possible implementations, the first node and the second node may alternatively be controllers or domain controllers, such as a VDC, an MDC, or a CDC.

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

[0015] In some possible implementations, the first message may further 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 is not specifically limited in the present application.

[0016] It should be understood that the first node and the second node may alternatively be other components that need to communicate within the terminal device.

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

[0018] In some possible implementations, the first device may be an OEM PKI server, or 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 may be another trusted device, such as a vehicle control server ICAS 1, an intelligent driving server ICAS 2, an infotainment server ICAS 3, a body domain controller (BDC), or a special equipment system (SAS), a media graphics unit (MGU), a body super core (BSC), an ADAS super core, or a cockpit super core (CSC).

[0019] 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 prepares to replace the original first node, and / or the second node may also be a node that prepares to replace the original second node.

[0020] In the above technical solution, a first node may establish a mutual "trust relationship" with a second node based on a first message containing second node information. Furthermore, the first node may verify the validity of the second node's identity by using the first message, and after successful verification, negotiate with the second node to share a security key. Furthermore, the shared security key may be used between the first node and the second node to generate a session key for each communication. When a service requires secure communication, the session key is used to encrypt the communication content and establish the secure communication. This helps ensure the confidentiality and integrity of the communication data.

[0021] With reference to the first aspect, in some implementations of the first aspect, generating a security key between the first node and the second node by the first node includes: 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 for session encryption between the first node and the second node.

[0022] It should be understood that the first node information indicates a second node for communicating with the first node, and / or the first node information includes public key information of the first node.

[0023] In some possible implementations, "the first node generates a security key based on the second node information" can be understood as the first node determining, based on the second node information, that there is a communication requirement between the first node and the second node. Furthermore, the first node generates a random number, receives a temporary public key sent by the second node, and generates a security key based on the temporary public key and the random number generated by the first node. The temporary public key sent by the second node is generated by the second node based on the random number generated by the second node.

[0024] Correspondingly, it should be understood that the second node generates a key based on the public key information of the first node that is the same as the security key generated by the first node.

[0025] For example, the method for generating the security keys by the first node and the second node may be a Diffie-Hellman key exchange protocol or another pre-shared key computing technique, which is not specifically limited in this application.

[0026] For example, the security key may be stored in security hardware of the first node to avoid unauthorized access or tampering.

[0027] In some possible implementations, the first node can alternatively use a standard TLS solution to verify the identity of the second node and calculate security keys, for example, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA can be used for this purpose.

[0028] In the above technical solution, the first node and the second node obtain a security key through negotiation based on the first message and each other's public key information, and communicate based on the security key. This greatly improves the negotiation performance of the secure connection. In addition, the risk of security key leakage can be reduced, and the complexity of security key management can be reduced.

[0029]

[0013] Referring to the first aspect, in some implementations of the first aspect, the method further includes the first node generating a first random number, and the first node generating a security key between the first node and the second node includes the first node generating the security key based on the first random number and second node information.

[0030] In some possible implementations, before generating the first random number, the first node first determines, based on the first message (or the second node information), that the first node has a communication requirement with the second node, and then generates a first random number, for example, v1, for the second node.

[0031] For example, if the second node information indicates information about the second node's public key Ĝs1, the first node generates a security key based on the random number v1 and Ĝs1.

[0032] In some possible implementations, the second node does not know which node it needs to communicate with, for example, the second node is a Layer 1 device that does not store first node information.

[0033] In some possible implementations, the first node generates a first public key, for example, Ĝv1, based on the first random number. Correspondingly, it should be understood that the second node generates a security key that is the same as the security key generated by the first node, based on the first public key Ĝv1 and the second node's private key s1.

[0034] For example, the security key may be stored in security hardware of the first node to avoid unauthorized access or tampering.

[0035] In the above technical solution, the layer 0 device and the layer 1 device obtain a security key through negotiation based on the first message and each other's public key information, and communicate based on the security key, which greatly improves the negotiation performance of the secure connection.

[0036] Referring to the first aspect, in some implementations of the first aspect, the method further includes: the first node generating a second random number; the first node generating a first public key based on the first random number; the first node sending the second random number and the first public key to the second node; the first node receiving the first encrypted value; the first encrypted value being obtained by the second node by encrypting the second random number based on a first security key; the first security key being generated based on the key of the second node and the first public key; the first node decrypting the first encrypted value based on the security key; and when the first encrypted value is successfully decrypted, the first node storing the security key.

[0037] For example, the second random number may be a Nonce value or another random number, which is not specifically limited in this application.

[0038] It should be understood that when the first node successfully decrypts the first encrypted value based on the security key, identity authentication for the second node is completed, and in this case, the second node may be considered to be the legitimate node indicated by the first message.

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

[0040] In some possible implementations, the second node can also authenticate the identity of the first node by using the above-mentioned method and store the security key after successful authentication.

[0041] In the above technical solution, identity authentication is performed for the second node, so that communication security can be further guaranteed.

[0042] Referring to the first aspect, in some implementations of the first aspect, the method further includes: the first node generating a third random number; the first node generating a second public key based on the third random number; the first node transmitting a first signature to the second node, the first signature being generated based on the first node's private key and the second public key; the first node receiving the second signature; the second signature being generated based on the second node's private key and the third public key after the second node successfully verifies the first signature; the third public key being generated based on a fourth random number generated by the second node; and the first node verifying the second signature based on second node information. The first node generating a security key between the first node and the second node includes the first node generating a security key based on the third public key and the third random number if the second signature is successfully verified.

[0043] In some possible implementations, the second node stores first node information. For example, the first node information includes public key information of the first node. In this case, the second node can correspondingly calculate a security key based on the first signature and the fourth random number, the security key being the same as the security key generated by the first node based on the third public key and the third random number.

[0044] In the above technical solution, in order to help ensure communication security between the Layer 1 device and the Layer 0 device, a method is provided for generating a security key between the Layer 1 device and the Layer 0 device when the Layer 1 device stores the public key information of the Layer 0 device.

[0045] With reference to the first aspect, in some implementation forms of the first aspect, the first node receives, from the first device, third node information indicating the 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 based on the fifth random number and the second node information, the first node generates a fifth public key based on the fifth random number and the third node information, the first node sends the fifth public key to the second node, and the first node sends the fourth public key to the third node.

[0046] In some possible implementation forms, the third node information and the information indicating that the second node and the third node need to communicate may be included in the first message, or the third node information and the information indicating that the second node and the third node need to communicate may be sent separately together with the first message, which is not specifically limited in the embodiments of the present application.

[0047] For example, both the second node and the third node may be layer 1 devices within the first terminal.

[0048] It should be understood that because the second node and the third node cannot know the Layer 1 devices with which the second node and the third node can communicate, the first node is required to assist the second node and the third node in generating the security keys needed for communication between the second node and the third node.

[0049] Furthermore, the second node can generate a security key based on the second node's private key and the fifth public key, and the third node can generate a security key based on the third node's private key and the fourth public key. The security keys generated by the second node and the third node are the same.

[0050] In the above technical solution, a first node can assist another node in generating a security key required for communication, and the key does not need to be injected from outside, so that the key processing is a closed-loop process in the first terminal, which can greatly reduce the risk of key leakage and reduce the complexity of key management.

[0051] Referring to the first aspect, in some implementations of the first aspect, before the first node receives the first message, the method further includes the first node sending a signed public key of the first node to the second device, where the signed public key of the first node is used to generate the first message.

[0052] For example, the second device may be an OEM TSP or another OEM node or device capable of generating a trust certificate. If the second device is an OEM TSP or another node or device capable of generating a trust certificate, the first node may send the signed public key of the first node to the second device via an electrical inspection device or a proxy unit in the vehicle.

[0053] In some possible implementations, the second device may be an electrical testing device.

[0054] In some possible implementations, if the first node's signed public key is signed by the OEM PKI server and forwarded by the OEM TSP, the OEM TSP stores the first node's signed public key. In this case, the first node does not need to transmit the first node's signed public key to the OEM TSP (via an electrical test device or a proxy unit in the vehicle).

[0055] In some possible implementations, if the first node's signed public key is issued by the device vendor, the OEM TSP does not store the first node's signed public key. In this case, the first node needs to send the first node's signed public key to the OEM TSP (via the electrical test device or the vehicle's proxy unit) so that the OEM TSP generates the first message based on the first node's signed public key.

[0056] It should be noted that the signed public key in this application may include anti-counterfeit information obtained by signing the public key of the first node, thereby preventing the public key of the first node from being forged. For example, the signed public key may include a public key obtained by an OEM PKI by using a private key of the OEM PKI to sign the public key of the first node, or the signed public key may include a signing certificate obtained by an OEM PKI by using a private key of the OEM PKI to sign the public key of the first node.

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

[0058] In some possible implementations, the signed public key of the first node may alternatively be issued by a third-party server.

[0059] Referring to the first aspect, in some implementations of the first aspect, before the first node receives the first message, the method further includes the first node transmitting a signed public key of the first node to the fourth device, where the signed public key of the first node is used to generate the first message.

[0060] For example, the fourth device may be a proxy unit in the vehicle, which may be a device capable of receiving and transmitting information, such as a telematics box (T-box).

[0061] Referring to the first aspect, in some implementation forms of the first aspect, the second node information includes public key information of the second node.

[0062] With reference to the first aspect, in some implementations of the first aspect, the public key information of the second node includes at least one of a public key signing certificate of the second node, a public key signing certificate identity ID of the second node, and a hash value of the second node's public key and the second node's identity information.

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

[0064] With reference to 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, wherein the service information of the second node indicates services that are present in the second node and that can be accessed by the first node.

[0065] For example, if the second node supports service A, service B, service C, and service D, but the second node only allows the first node to access service A and service B, the service information of the second node may include information about service A and service B to indicate that the first node accesses service A and service B of the second node. In the above case, it should be understood that the first node cannot access service C and service D of the second node.

[0066] In one example, services A to D may be an air conditioning service, a vehicle door control service, a brake control service, and a steering control service, respectively.

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

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

[0069] In the above technical solution, finer-grained access control can be established based on the communication between the first node and the second node, so that the first node can access only a portion of the services of the second node. When the first node is attacked, the contents of the remaining services of the second node are guaranteed not to be leaked, further improving communication security. The service information and signed trust certificate of the second node are managed separately to facilitate information updates during node replacement. For example, when a new second node is used to replace the original second node, only the signed trust certificate containing the second node information needs to be updated, and the service information of the second node does not need to be updated.

[0070] With reference to the first aspect, in some implementations of the first aspect, the security key includes at least one of a pre-shared key, a diagnostic key, a security on-board communication SecOC key, and another application key.

[0071] In the above technical solution, the pre-shared key, diagnostic key, security on-board communication SecOC key, other application keys, etc. are all generated based on the second node information, and no external key "filling" is required. As a result, the security key processing is a closed loop within the first terminal, which facilitates key management and reduces the risk of key leakage.

[0072] Referring to the first aspect, in some implementation forms of the first aspect, the method further includes: the first node generating a trust token; the first node sending the trust token to the fourth node; the first node generating a sixth random number; the first node generating a second security key based on the trust token and the sixth random number; and the first node sending the second security key encrypted by using the trust token to the fourth node, so that the fourth node performs decryption based on the trust token pre-stored in the fourth node to obtain the second security key, and the second security key is used for session encryption between the first node and the fourth node.

[0073] In some possible implementations, the sixth random number may be a Nonce value or may be another random number.

[0074] For example, the fourth node may be a tier 2 device or another device without security hardware.

[0075] In the above technical solution, the first node can generate, for the fourth node, the security key required for communication between the first node and the fourth node, and no "filling" of the external key is required to prevent the external connection from jeopardizing the security of the first terminal.

[0076] With reference to the first aspect, in some implementations of the first aspect, before the first node transmits the trust token to the fourth node, the method further includes the first node performing authentication with the fourth node based on at least one of a serial number SN, a physical fingerprint, an authentication chip, or a security chip of the fourth node. The first node transmitting the trust token to the fourth node includes the first node transmitting the trust token to the fourth node when the authentication is successful.

[0077] In the above technical solution, identity authentication is performed for the fourth node, so that communication security can be further guaranteed.

[0078] Referring to the first aspect, in some implementations of the first aspect, the method further includes: the first node performing identity authentication with the fourth node based on the second security key; and when the identity authentication is successful, the first node deleting the trust token.

[0079] In the above technical solution, the trust token is deleted to prevent external intruders from stealing the trust token and causing security threats.

[0080] According to a second aspect, there is provided a communication method. The method 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 indicating the second node; and the second device sending the first message to the first node.

[0081] For example, the second device may be an OEM TSP, or may be another OEM node or device capable of generating a trust certificate, or the second device may be an electrical testing device.

[0082] 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, and the second device can send the first message to an electrical inspection device or a proxy unit of the vehicle, which then sends the first message to the first node.

[0083] In some possible implementations, if the second device is an electrical testing device, the second device can receive the first message sent by the first device through an OEM device, such as an OEM TSP, and further transmit the first message directly to the first node.

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

[0085] It should be noted that "directly receiving" or "directly transmitting" may be understood as receiving or transmitting without being forwarded by another device.

[0086] In the above technical solution, the OEM or the electrical testing device sends a first message containing second node information to the first node, thereby establishing a "trust relationship" between the first node and the second node. This helps the first node and the second node generate a session key based on the first message. Furthermore, if the service requires secure communication, using the session key for communication helps ensure the confidentiality and integrity of the communication data.

[0087] Referring to the second aspect, in some implementation forms of the second aspect, before the second device receives the first message sent by the first device, the method further includes: the second device generating a second message based on the signed public key of the first node and a communication list, the communication list indicating that the first node and the second node need to communicate; and the second device sending the second message to the first device.

[0088] For example, the method may be performed by an OEM TSP or by another OEM node or device capable of generating trust certificates.

[0089] For example, the communication list may be in the form of a list or a matrix. The communication list indicates communication relationships between nodes in the first terminal. Alternatively, the communication list may be in another form. This is not specifically limited in the present application.

[0090] For example, the second message may be an unsigned trust certificate. In some possible implementations, the trust certificate may be a trust list of other nodes that communicate with the first node, and the trust certificate includes public key information of the other nodes that communicate with the first node.

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

[0092] Referring to the second aspect, in some implementations of the second aspect, the second device is an electrical testing device, and the method further includes: the second device receiving a signed public key of the first node sent by the third device; and the second device sending the signed public key of the first node to the first node.

[0093] In some possible implementations, the first device and the third device may be the same device. For example, both may be OEM PKI servers. Alternatively, the first device and the third device may be different devices. For example, the first device may be an OEM PKI server and the third device may be a vendor server.

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

[0095] In the above technical solution, the electrical inspection device transmits the signed public key of the first node to the first node to facilitate subsequent generation and use of a first message based on the signed public key of the first node.

[0096] According to a third aspect, there is provided 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.

[0097] 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 another device, which helps to further improve communication security.

[0098] According to a fourth aspect, there is provided a communication method. The method may be performed by a control unit or control module in a vehicle (or another terminal), or may be performed by a chip or circuit used in a control unit or control module of a vehicle (or another terminal). This is not a limitation in the present application.

[0099] The method may include: a second node receiving a first public key, the first public key generated by the first node based on a first message, the first message including second node information, the second node information indicating the second node; and the second node generating a security key based on the first public key, the security key being used for session encryption between the first node and the second node, or the security key being used for session encryption between the second node and a third node.

[0100] For example, the second node may be a tier 1 device.

[0101] For example, the third node may be a layer 1 device that has a communication requirement with the second node.

[0102] For example, when a first node is used to generate a session key between a second node and a third node, "a first public key is generated by the first node based on the first message" may be specifically as follows: "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 node and the third node need to communicate." "The second node generates a security key based on the first public key" may be specifically as follows: "The second node generates a security key based on the first public key and the private key of the second node." In the above case, it should be understood that the security key is used for session encryption between the second node and the third node.

[0103] For example, when a session key between a first node and a second node is generated and the second node does not store the first node information, "the second node generates a security key based on the first public key" may be as follows: "The second node generates a security key based on the first public key and the second node's private key." Alternatively, when the second node stores the first node information, "the second node generates a second security key based on the first public key" may be as follows: "The second node generates a security key based on the first public key and a random number generated by the second node based on the second signed trust certificate." In the above case, it should be understood that the second security key is used for session encryption between the first node and the second node.

[0104] In the above technical solution, the second node can generate a security key based on the first public key sent by the first node. The security key can be used to generate a session key required for communication with the first node or a third node, and no external key "filling" is required. This helps improve the security of the internal key of the first terminal.

[0105] With reference to the fourth aspect, in some implementations of the fourth aspect, the first public key is a public key signed by using the private key of the first node, and the method further includes the second node determining a public key of the first node based on the first message, the second node verifying the first public key based on the public key of the first node, and the second node generating a fifth random number. When the verification is successful, the second node generating a security key based on the first public key includes the second node generating a security key based on the first public key and the fifth random number.

[0106] For example, the first public key may be the first signature in the first aspect.

[0107] In the above technical solution, the second node and the first node can obtain a security key through negotiation based on the first message and each other's public key information, and communicate by using the security key. This greatly improves the negotiation performance of the secure connection. In addition, the risk of security key leakage can be reduced, and the complexity of security key management can be reduced.

[0108] According to a fifth aspect, there is provided a first node, the first node including: a transceiver unit configured to receive a first message from a first device, the first message including second node information, the second node information indicating the second node, and a processing unit configured to determine the second node based on the second node information, generate a security key between the first node and the second node, and communicate with the second node based on the security key.

[0109] With reference to the fifth aspect, in some implementation forms of the fifth aspect, the processing unit is specifically configured to: when the second node stores first node information indicating the first node, generate, by the first node, a security key based on the second node information, wherein the security key is used for session encryption between the first node and the second node.

[0110] With reference to the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to generate a first random number and generate a security key based on the first random number and the second node information.

[0111]

[0013] Referring to the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to generate a second random number and generate a first public key based on the first random number. The transceiver unit is further configured to transmit the second random number and the first public key to a second node and receive a first encrypted value, the first encrypted value being obtained by the second node by encrypting the second random number based on a first security key, the first security key being generated based on the key of the second node and the first public key. The processing unit is further configured to decrypt the first encrypted value based on the security key and store the security key when the first encrypted value is successfully decrypted.

[0112]

[0013] Referring to the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to generate a third random number and generate a second public key based on the third random number. The transceiver unit is further configured to transmit a first signature generated based on the private key and the second public key of the first node to the second node and receive a second signature generated based on the private key and the third public key of the second node after the second node successfully verifies the first signature, the second signature being generated based on the private key and the third public key of the second node, the third public key being generated based on a fourth random number generated by the second node. The processing unit is further configured to verify the second signature based on the second node information and, when the second signature is successfully verified, generate, by the first node, a security key based on the third public key and the third random number.

[0113]

[0013] Referring to the fifth aspect, in some implementations of the fifth aspect, the transceiver unit is further configured to receive, from the first device, third node information indicating the 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 based on the fifth random number and the second node information, and generate a fifth public key based on the fifth random number and the third node information. The transceiver unit is further configured to transmit the fifth public key to the second node and the fourth public key to the third node.

[0114] With reference to the fifth aspect, in some implementations of the fifth aspect, the transceiver unit is further configured to transmit a signed public key of the first node to the second device before receiving the first message, and the signed public key of the first node is used to generate the first message.

[0115] With reference to the fifth aspect, in some implementation forms of the fifth aspect, the second node information includes public key information of the second node.

[0116] With reference to the fifth aspect, in some implementation forms of the fifth aspect, the public key information of the second node includes at least one of the second node's public key signing certificate, the second node's public key signing certificate identity ID, and a hash value of the second node's public key and the second node's identity information.

[0117] With reference to the fifth aspect, in some implementations of the fifth aspect, the transceiver unit is further configured to receive service information of a second node from the first device, wherein the service information of the second node indicates services that are present in the second node and that can be accessed by the first node.

[0118] With reference to the fifth aspect, in some implementation forms of the fifth aspect, the security key includes at least one of a pre-shared key, a diagnostic key, a security on-board communication SecOC key, and another application key.

[0119]

[0013] Referring to the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to generate a trust token. The transceiver unit is further configured to transmit the trust token to a fourth node. The processing unit is further configured to generate a sixth random number and generate a second security key based on the trust token and the sixth random number. The transceiver unit is further configured to transmit the second security key encrypted by using the trust token to the fourth node, so that the fourth node performs decryption based on the trust token pre-stored by the fourth node to obtain the second security key, and the second security key is used for session encryption between the first node and the fourth node.

[0120] With reference to the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to perform authentication with the fourth node based on at least one of an authentication code SN, a physical fingerprint, an authentication chip, or a security chip of the fourth node before the transceiver unit transmits the trust token to the fourth node. The transceiver unit is specifically configured to transmit the trust token to the fourth node when the authentication is successful.

[0121] With reference to the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to perform identity authentication with the fourth node based on the second security key, and delete the trust token if the identity authentication is successful.

[0122] According to a sixth aspect, there is provided a second device, the second device including: a transceiver unit configured to receive a first message transmitted by a first device, the first message including second node information, the second node information indicating the second node; and transmit the first message to the first node.

[0123] With reference to the sixth aspect, in some implementation forms of the sixth aspect, the second device further includes a processing unit configured to generate a second message based on the signed public key of the first node and a communication list before the transceiver unit receives the first message sent by the first device, the communication list indicating that the first node and the second node need to communicate, and the transceiver unit is further configured to transmit the second message to the first device.

[0124] With reference to the sixth aspect, in some implementation forms of the sixth aspect, when the second device is an electrical testing device, the transceiver unit is further configured to receive a signed public key of the first node transmitted by the third device, and transmit the signed public key of the first node to the first node.

[0125] According to a seventh aspect, there is provided a first device including: a transceiver unit configured to receive a second message transmitted by a second device; and a processing unit configured to sign the second message to generate a first message. The transceiver unit is further configured to transmit the first message to a first node.

[0126] According to an eighth aspect, there is provided a second node, the second node including: a transceiver unit configured to receive a first public key, the first public key generated by the first node based on a first message, the first message including second node information, the second node information indicating the second node; and a processing unit configured to generate a security key based on the first public key, the security key being used for session encryption between the first node and the second node, or the security key being used for session encryption between the second node and a third node.

[0127] With reference to the eighth aspect, in some implementation forms of the eighth aspect, the first public key is a public key signed by using a private key of the first node, and the processing unit is further configured to determine a public key of the first node based on the first message, verify the first public key based on the public key of the first node, generate a fifth random number, and if the verification is successful, generate a security key based on the first public key and the fifth random number.

[0128] According to a ninth aspect, there is provided a communications device, the device including: a memory configured to store a program; and a processor configured to execute the program stored in the memory, the processor being configured to perform a method according to any one of the possible implementations of the first or fourth aspects when the program is executed.

[0129] According to a tenth aspect, there is provided a communications device, the device including: a memory configured to store a program; and a processor configured to execute the program stored in the memory, the processor being configured to execute a method according to any one of the possible implementations of the second or third aspect when the program is executed.

[0130] According to an eleventh aspect, there is provided a communication system, the system including: a first node in any possible implementation form of the fifth aspect; and a second node in any possible implementation form of the eighth aspect.

[0131] With reference to the eleventh aspect, in some implementations of the eleventh aspect, a first node generates a first random number and generates a security key based on the first random number and second node information, where the second node information indicates the second node. The first node generates a first public key based on the first random number. The first node transmits the first public key to the second node. The second node receives the first public key, generates a first security key based on the second node's private key and the first public key, and encrypts the second random number based on the first security key to obtain a first encrypted value. The second node transmits 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.

[0132] It should be understood that when the first node successfully decrypts the first encrypted value, the first security key is proven to be the same as the security key.

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

[0134] With reference to the eleventh aspect, in some implementations of the eleventh aspect, the first node generates a third random number and generates a second public key based on the third random number. The first node transmits a first signature generated based on the first node's private key 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. If 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 transmits the second signature to the first node. The second node generates a third security key based on the fourth random number and the second public key. The first node receives the second signature, verifies the second signature based on the second node information, and if the second signature is successfully verified, generates a fourth security key based on the third public key and the third random number.

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

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

[0137] Referring to the eleventh aspect, in some implementation forms of the eleventh aspect, the system further includes the first device of the eighth aspect, and the second node includes the first device and the second device. The first node receives from the first device 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. 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 the fifth public key based on the fifth random number and the second device information. The first node transmits the fifth public key to the first device. The first node transmits 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 first device's private key and the fifth public key. The second device receives the fourth public key and generates a sixth security key based on the second device's private key and the fourth public key.

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

[0139] According to a twelfth aspect, there is provided a vehicle, the vehicle including the first node in any possible implementation form of the fifth aspect and / or the second node in any possible implementation form of the eighth aspect.

[0140] It should be understood that a vehicle (sometimes simply referred to as a vehicle) in this application is a vehicle in the broad sense, and may be a means of transportation (e.g., a car, truck, motorcycle, train, airplane, or ship), an industrial vehicle (e.g., a forklift, trailer, or tractor), an engineering vehicle (e.g., an excavator, bulldozer, or crane), an agricultural device (e.g., a lawnmower or harvester), a recreational device, a toy vehicle, etc. The type of vehicle is not limited in this application.

[0141] According to a thirteenth aspect, there is provided a terminal device, the terminal device including the second device in any possible implementation form of the sixth aspect and / or the first device in any possible implementation form of the seventh aspect.

[0142] According to a fourteenth aspect, there is provided a computer program product, the computer program product comprising computer program code, which, when executed on a computer, enables the computer to perform a method according to any possible implementation of the first to fourth aspects.

[0143] It should be noted that all or part of the computer program code may be stored in a first storage medium, which may be encapsulated together with the processor or may be encapsulated separately from the processor, which is not specifically limited in the embodiments of the present application.

[0144] According to a fifteenth aspect, there is provided a computer-readable medium storing program code which, when executed on a computer, enables the computer to perform the method of any possible implementation of the first to fourth aspects.

[0145] According to a sixteenth aspect, there is provided a chip, the chip including a processor configured to invoke a computer program or computer instructions stored in a memory, such that the processor performs a method in any possible implementation of the first to fifth aspects.

[0146] Referring to the sixteenth aspect, in a possible implementation, the processor is coupled to the memory via an interface.

[0147] Referring to the sixteenth aspect, in a possible implementation, the chip system further includes a memory, which stores computer programs or computer instructions.

[0148] According to a seventeenth aspect, there is provided a communication method. The method 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 indicating the second node; and the fourth device sending the first message to the first node.

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

[0150] In the above technical solution, the proxy unit of the vehicle transmits the signed public key of the first node to the first node to facilitate subsequent generation and use of a first message based on the signed public key of the first node. Furthermore, the proxy unit of the vehicle completes the transfer of the message and / or information. This procedure does not require the involvement of an electrical testing device, which can improve the overall vehicle manufacturing speed.

[0151] With reference to the seventeenth aspect, in some implementation forms of the seventeenth aspect, the method may further include: the fourth device receiving, by the first node, a public key of the first node sent by the first node, wherein the public key of the first node is used to generate a signed public key of the first node; and the fourth device sending, by the fourth device, the public key of the first node to the first device.

[0152] With reference to the seventeenth aspect, in some implementations of the seventeenth aspect, the method further includes: the fourth device receiving a signed public key of the first node sent by the first node; and the fourth device sending the signed public key of the first node to the second device.

[0153] With reference to the seventeenth aspect, in some implementations of the seventeenth aspect, before the fourth device receives the signed public key of the first node sent by the first node, the method further includes: the fourth device receiving a first signal from the electrical inspection device; and the fourth device sending request information to the first node based on the first signal.

[0154] For example, the first signal is used to activate a fourth device.

[0155] According to an eighteenth aspect, there is provided a fourth device, the fourth device including: a transceiver unit configured to receive a first message transmitted by a first device, the first message including second node information, the second node information indicating the second node; and transmit the first message to the first node.

[0156] With reference to the eighteenth aspect, in some implementation forms of the eighteenth aspect, the transceiver unit is further configured to receive a public key of the first node transmitted by the first node, the public key of the first node being used to generate a signed public key of the first node, and transmit the public key of the first node to the first device.

[0157] With reference to the eighteenth aspect, in some implementations of the eighteenth aspect, the transceiver unit is further configured to receive a signed public key of the first node transmitted by the first node, and transmit the signed public key of the first node to the second device.

[0158]

[0023] Referring to the eighteenth aspect, in some implementations of the eighteenth aspect, the fourth device further includes a processing unit. The transceiver unit is further configured to receive a first signal from the electrical testing device. The processing unit is configured to control the transceiver unit to send request information to the first node based on the first signal, where the request information is used to request a public key of the first node.

[0159] According to a nineteenth aspect, there is provided a communication system including a first node and a fourth device. The first node transmits a signed public key of the first node to the fourth device, the signed public key of the first node is used to generate a first message, the first message includes second node information, the second node information indicates the second node, and the fourth device transmits the first message to the first node.

[0160] With reference to the 19th aspect, in some implementation forms of the 19th aspect, before the first node transmits the first node's signed public key to the fourth device, the fourth device receives a first signal from the electrical inspection device, and the fourth device transmits request information to the first node based on the first signal, and the request information is used to request the first node's signed public key.

[0161] According to a twentieth aspect, there is provided a communication system including a second device, the second device receiving a signed public key of the first node transmitted by the first node, the signed public key of the first node being used to generate a first message, the first message including second node information, the second node information indicating the second node, and the second device transmitting the first message to the first node.

[0162] Referring to the twentieth aspect, in some implementations of the twentieth aspect, the system further includes a first device, wherein the second device generates a second message based on the signed public key of the first node and a communication list, the communication list indicating 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 a first message, and sends the first message to the second device. [Brief explanation of the drawings]

[0163] [Figure 1] FIG. 1 is a functional block diagram of a vehicle according to an embodiment of the present application. [Figure 2] 1 is a diagram of the architecture of a communication system according to an embodiment of the present application; [Figure 3] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 4] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 5] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 6] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 7a] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 7b] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 8a] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 8b] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 9] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 10] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 11]1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 12] 1 is a diagram of an application scenario of a communication method according to an embodiment of the present application; [Figure 13] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 14] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 15] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 16] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 17] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 18] 1 is a block diagram of a communication device according to an embodiment of the present application; [Figure 19] FIG. 2 is another block diagram of a communication device according to an embodiment of the present application. [Figure 20] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 21] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 22] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 23] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 24] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 25] 1 is a schematic flowchart of a communication method according to an embodiment of the present application; [Figure 26] 1 is a block diagram of a communication device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0164] The following describes the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, " / " means "or" unless otherwise specified. For example, A / B may represent A or B. In this specification, "and / or" only describes a related relationship to describe related objects and represents that three relationships may exist. For example, A and / or B may represent the following three cases: when only A exists, when both A and B exist, and when only B exists.

[0165] Prefix terms such as "first" and "second" used in the embodiments of the present application are merely used to distinguish between different described objects and do not limit the position, order, priority, quantity, or content of the described objects. The use of prefix terms such as ordinal numbers used to distinguish between described objects in the embodiments of the present application does not constitute a limitation on the described objects. For an explanation of the described purpose, please refer to the claims or the context description in the embodiments. The use of such prefix terms should not constitute redundant restrictions. Furthermore, in the description of the embodiments, unless there is a clear and specific limitation, "plurality" means two or more.

[0166] 1 is a functional block diagram of a vehicle 100 according to one embodiment of the present application. The vehicle 100 may include a sensing system 120, a display device 130, and a computing platform 150. The sensing system 120 may include multiple types of sensors that sense information about the environment around the vehicle 100. For example, the sensing system 120 may include a positioning system. The positioning system may be a global positioning system (GPS), or one or more of a Beidou system or another positioning system, an inertial measurement unit (IMU), a lidar, a millimeter-wave radar, an ultrasonic radar, and a camera device.

[0167] Some or all functions of vehicle 100 may be controlled by computing platform 150. Computing platform 150 may include processors 151 through 15n (where n is a positive integer). A processor is a circuit having signal processing capabilities. In one implementation, a processor may be a circuit having instruction reading and execution capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which may also be understood as a microprocessor), or a digital signal processor (DSP). In another implementation, a processor may implement a specific function based on the logical relationships of a hardware circuit. The logical relationships of the hardware circuit may be fixed or reconfigurable. For example, a processor may be a hardware circuit implemented by 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 document and implementing the hardware circuit configuration can be understood as the process of the processor loading instructions and implementing some or all of the functions of the above-mentioned units. In addition, the processor may alternatively be a hardware circuit designed for artificial intelligence and can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), or a deep learning processing unit (DPU). In addition, the computing platform 150 may further include a memory. The memory is configured to store instructions.Some or all of processors 151 through 15n can retrieve instructions in memory and execute the instructions to implement the corresponding functions.

[0168] Vehicle 100 may include an ADAS that acquires information from the vehicle's surroundings by using multiple types of sensors (including, but not limited to, lidar, millimeter-wave radar, camera devices, ultrasonic sensors, global positioning systems, and inertial measurement units) in sensing system 120, and analyzes and processes the acquired information to implement functions such as obstacle sensing, target recognition, vehicle positioning, route planning, and driver monitoring / reminders, thereby improving the vehicle's driving security, automation, and comfort.

[0169] 2 is a diagram of a communication system architecture according to one embodiment of the present application. As shown in FIG. 2, an in-vehicle communication network 200 includes layer 0 devices, layer 1 devices, and layer 2 devices. The layer 0 devices include a ZC, a TCU, an IVI, and an ADAS, which are connected to each other via Ethernet cables. The layer 0 devices typically have security hardware, such as a hardware security module (HSM) or a trusted platform module (TPM), so that the layer 0 devices can generate security keys and perform public key cryptography operations. For example, the generated "security keys" include, but are not limited to, a pre-shared key (PSK), a diagnostic key, a security onboard communication (SecOC) key, and another application key.

[0170] Tier 1 devices are typically connected to each other via CAN-FD cables and to Tier 0 devices via CAN-FD. Tier 1 devices include an EPS and EPB, and may also include CDC, etc. Security hardware such as HSM and TPM may also be in Tier 1.

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

[0172] Layer 2 devices are resource-limited ECU devices that do not have security hardware and are connected to each other via a low-bandwidth CAN bus. For example, examples of Layer 2 devices may include CAN ECUs, sensors, executors, etc.

[0173] In some possible implementations, the layer 2 devices may alternatively be devices connected via another bus, such as a local interconnect network (LIN).

[0174] It should be understood that ECUs connected via non-Ethernet (e.g., Layer 1 and Layer 2 devices) do not have transport layer security (TLS) cipher suites that can be used to implement TLS-based security standards.

[0175] Note that a device that has security hardware but is connected via a CAN bus can still perform lightweight public key operations and may be considered a Tier 1 device in this embodiment of the application. A device that does not have security hardware but is connected via CAN-FD cannot perform public key operations and therefore is still considered a resource-limited Tier 2 device in this embodiment of the application. For example, a "public key operation" may include an operation that autonomously generates a public-private key pair.

[0176] It should be understood that the various devices shown in Figure 2 are merely examples. During actual application, devices may be added or removed based on actual requirements. For example, there may be a different number of devices with different names, or the devices may be connected to each other in different topologies in different vehicles.

[0177] As mentioned above, in this application, in-vehicle devices are classified into three types: layer 0 devices, layer 1 devices, and layer 2 devices based on the connection type and processing capability of the in-vehicle devices. In this embodiment of the application, corresponding solutions are provided for each layer to establish secure communication between in-vehicle devices.

[0178] Secure communication between Tier 0 devices: Each Tier 0 device establishes a trust relationship with another Tier 0 device through a trust table that contains information about other Tier 0 devices that communicate with it. Furthermore, based on signature certificate-based public key encryption technology, a device identity verification mechanism and trusted communication are established between Tier 0 devices, resulting in the formation of a "trust ring" between all Tier 0 devices. Any device from the trust ring can further help another device on the trust ring to perform identity verification and secure communication.

[0179] Secure communication between Tier 1 devices: "Trust relationships" between Tier 0 devices and Tier 1 devices, and trust relationships between Tier 1 devices, are established based on the trust tables of the Tier 0 devices, and secure communication is established between the devices based on the trust relationships.

[0180] Secure communication between Tier 2 devices: Tier 0 devices verify trust relationships with Tier 2 devices and establish secure communications with Tier 2 devices using symmetric key cryptographic operations.

[0181] It should be noted that an ECU with security hardware can perform public key cryptography operations (eg, elliptic curve cryptography (ECC)), secure key generation and storage, and the like.

[0182] In the following, a method for communication between in-vehicle devices will be described in detail with reference to FIGS.

[0183] 3 is a schematic flowchart of a communication method according to an embodiment of the present application. More specifically, FIG. 3 shows a method for generating a key and a signature certificate in a tier 0 device. In this embodiment of the present application, a zone controller ZC1 in the tier 0 device is used as an example for illustration. The method may include the following steps:

[0184] S301: The electrical testing device activates public / private key generation.

[0185] For example, when an electrical testing device is connected to a Tier 0 device, the Tier 0 device is activated to generate a public / private key pair.

[0186] S302: ZC 1 generates a first public key and a first private key.

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

[0188] For example, ZC 1 generates a private / public key pair for ZC 1 in security hardware, sends a first public key (e.g., PK_ZC1) to the electrical testing device, and keeps the first private key in the security hardware of ZC 1. It should be understood that a third party cannot obtain or tamper with the private key securely stored in the security hardware.

[0189] S303: ZC 1 sends the first public key to the electrical testing device.

[0190] S304: The electrical testing device sends a first public key to a public key infrastructure (PKI) server.

[0191] Optionally, the electrical inspection device may be connected to the PKI server via wireless communication, for example, the Internet or the Internet of Things, which is not specifically limited in the embodiments of the present application.

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

[0193] For example, the PKI server signs the first public key of ZC1 by using the PKI server's private key to generate a signed certificate (e.g., CERT_PK_ZC1). It should be understood that the certificate includes the public key of ZC1.

[0194] S306: The PKI server sends the first signing certificate to the electrical testing device.

[0195] S307: The electrical testing device sends the first signing certificate to ZC 1.

[0196] S308: ZC 1 stores the first signing certificate.

[0197] It should be noted that a supplier of an in-vehicle device (e.g., a supplier of ZC 1) may perform the steps performed by the electrical test device or PKI server shown in FIG. 3 during device production. In this case, the electrical test device may be the supplier's electrical test device. Furthermore, the supplier's PKI server signs the first signing certificate. Optionally, the method shown in FIG. 3 may alternatively be performed by an original equipment manufacturer (OEM). In this case, the electrical test device is the OEM's electrical test device, and the OEM's PKI server signs the first signing certificate.

[0198] It will be understood that the reception and transmission of the public key and signature certificate performed by the electrical inspection device may affect the vehicle production process and further threaten vehicle security. Taking this into consideration, a communication method is provided in FIG. 20 . To solve the problem that the process of receiving and transmitting the public key and signature certificate affects the vehicle production process and vehicle security, a proxy unit in the vehicle performs the actions of receiving and transmitting the public key and signature certificate performed by the electrical inspection device in the above-described embodiment. It should be noted that the proxy unit in the embodiment of the present application may be a controller such as a CDC or VIU, or software disposed in the controller. It should be noted that the VIU may be a controller, or the VIU may be a gateway, or a unit having the functions of a controller and a gateway.

[0199] As shown in FIG. 20, the method may include the following steps.

[0200] S301': The electrical testing device activates the proxy unit.

[0201] For example, when an electrical inspection device is connected to a vehicle or a proxy unit of the vehicle, the proxy unit is activated. Specifically, the electrical inspection device sends diagnostic information to the proxy unit based on the 27 Service Authentication and Unified Diagnostic Services (UDS) protocol and activates the proxy unit by using the diagnostic information, so that the proxy unit starts receiving and transmitting information. S301": The proxy unit activates the generation of the public key / private key of ZC1.

[0202] For example, the proxy unit sends public key request information to ZC 1 so that ZC 1 generates a public / private key pair.

[0203] S302': ZC 1 generates a first public key and a first private key.

[0204] For example, for the specific method of this step, please refer to the corresponding description of S302 shown in FIG.

[0205] S303': ZC 1 sends the first public key to the proxy unit.

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

[0207] Optionally, the proxy unit may be connected to the PKI server via wireless communication, for example, the Internet or the Internet of Things, which is not specifically limited in the embodiments of the present application.

[0208] S305': The PKI server signs the first public key and generates a first signed certificate including the first public key.

[0209] For example, for the specific method of this step, please refer to the corresponding description of S305 shown in FIG.

[0210] S306': The PKI server sends the first signing certificate to the proxy unit.

[0211] S307': The electrical testing device sends the first signing certificate to ZC1.

[0212] S308': ZC 1 stores the first signing certificate.

[0213] Optionally, the method shown in Figure 20 may be performed by an OEM, in which case the electrical testing device is the OEM's electrical testing device and the OEM's PKI server signs the first signing certificate.

[0214] It should be appreciated that for each Tier 0 device, the method shown in FIG. 3 may be used to generate a private / public key pair and obtain a public key signing certificate.

[0215] 4 is a schematic flowchart of a communication method according to an embodiment of the present application. More specifically, FIG. 4 shows a method for generating a trust table between layer 0 devices. The method may include the following steps:

[0216] S401: The OEM electrical test device requests a certificate from the Tier 0 device.

[0217] In some possible implementations, the OEM electrical testing device may be separately connected to multiple Tier 0 devices and request a signing certificate from each Tier 0 device (e.g., ZC 1, ZC 2, and ZC 3).

[0218] S402: The Tier 0 device sends the signing certificate (and / or SN) to the OEM electrical testing device.

[0219] For example, each Tier 0 device sends its signing certificate to the OEM electrical inspection device. For example, if the Tier 0 devices include ZC 1, ZC 2, and ZC 3, ZC 1, ZC 2, and ZC 3 send their respective signing certificates to the electrical inspection device. For example, ZC 1 sends signing certificate CERT_PK_ZC1 to the OEM electrical inspection device, ZC 2 sends signing certificate CERT_PK_ZC2 to the OEM electrical inspection device, and ZC 3 sends signing certificate CERT_PK_ZC3 to the OEM electrical inspection device.

[0220] In some possible implementations, the Tier 0 device also transmits the Tier 0 device's serial number (SN) to the OEM electrical test device.

[0221] S403: The OEM electrical testing device sends the signing certificate (and / or SN) to the OEM.

[0222] For example, the electrical inspection device sends all the signature certificates to the OEM. The OEM electrical inspection device may send all the signature certificates to the OEM at once, or may send the signature certificates in batches, for example, sending one or more signature certificates each time. This is not specifically limited in the embodiments of the present application.

[0223] In some possible implementations, the OEM electrical test device also transmits the SN of the Tier 0 device to the OEM.

[0224] S404: The OEM verifies the signing certificate and generates a trust table for each Tier 0 device based on the signing certificate.

[0225] In some possible implementations, the OEM stores a communication matrix, which includes information indicating which on-board devices have communication requirements with other on-board devices. Note that device 1 having a communication requirement with device 2 may mean that there may be signaling interaction between device 1 and device 2 during the vehicle driving process. In certain implementations, device 1 and device 2 do not necessarily communicate or have signaling interaction.

[0226] Furthermore, the OEM creates a trust table for each Tier 0 device based on the communication matrix and the signing certificate. For example, the OEM learns based on the communication matrix that ZC 1 has communication requirements with each of ZC 2 and ZC 3. Therefore, the trust table for ZC 1 includes the public key information and VINs of ZC 2 and ZC 3. It should be understood that the identification number is globally unique for each vehicle.

[0227] In one example, the information about ZC2 and ZC3 may be the signing certificate IDs of ZC2 and ZC3, e.g., the signing certificate ID CertID_ZC2 corresponding to ZC2's signing certificate (CERT_PK_ZC2) and the signing certificate ID CertID_ZC3 corresponding to ZC3's signing certificate (CERT_PK_ZC3). Similarly, ZC2's trust table has the signing certificate IDs of ZC1 and any other Layer 0 devices (e.g., ZC4) that need to communicate while the vehicle is running. For example, the trust tables for ZC1 and ZC2 are shown in Table 1 and Table 2, respectively.

[0228] [Table 1]

[0229] [Table 2]

[0230] In another example, the information about ZC 2 and ZC 3 may include the public key hashes of ZC 2 and ZC 3. In other words, the public key hashes of ZC 2 and ZC 3 are listed in ZC 1's trust table.

[0231] In yet another example, the information about ZC 2 and ZC 3 may include the signing certificates of ZC 2 and ZC 3. In other words, the trust table of ZC 1 includes the signing certificates of ZC 2 and ZC 3.

[0232] In yet another example, the information about ZC 2 and ZC 3 may include the SNs of ZC 2 and ZC 3. In other words, the trust table of ZC 1 includes the SNs of ZC 2 and ZC 3.

[0233] In some possible implementations, the trust table of a device may further include the serial numbers (SNs) of other devices that need to communicate with the device. For example, the trust table of ZC 1 may further include the SNs of ZC 2 and ZC 3, and the trust table of ZC 2 may further include the SNs of ZC 1 and ZC 4.

[0234] It should be understood that the OEM prepares a trust table for each Tier 0 device in the vehicle and transmits the trust table for each Tier 0 device to the OEM PKI server.

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

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

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

[0238] For example, the OEM PKI server signs each trust table with the OEM PKI server's private key to generate multiple signed trust tables, with one signed trust table corresponding to one Tier 0 device.

[0239] In some possible implementations, the OEM PKI server can send the OEM PKI server's public key to each Tier 0 device via the OEM and the OEM electrical test device, so that the Tier 0 device verifies the signed trust table based on the public key.

[0240] S407: The OEM PKI server sends the multiple signed trust tables to the OEM.

[0241] S408: The OEM sends the signed trust table to the OEM electrical testing device.

[0242] S409: The OEM electrical test device sends the signed trust table to the tier 0 device.

[0243] It should be understood that the OEM electrical testing device sends the signed trust table to the corresponding tier 0 device, for example, sending ZC 1's signed trust table to ZC 1 and sending ZC 2's signed trust table to ZC 2.

[0244] S410: Each Tier 0 device stores a signed trust table of the Tier 0 device.

[0245] For example, ZC 1's signed trust table is stored in ZC 1, and this rule also applies to other signed trust tables.

[0246] It should be understood that the "OEM" in the embodiments of this application may be the OEM's trust service provider (TSP) or another OEM device capable of generating a trust table.

[0247] It should be noted that in this embodiment of the present application, the steps performed by the OEM may specifically be performed by a telematics service provider (TSP). In some possible implementations, the OEM PKI server and the steps performed by the OEM may alternatively be performed by a third-party server. This is not specifically limited in the embodiment of the present application.

[0248] As described above, in order to solve the problem of the impact on the vehicle production process and vehicle security caused by receiving and sending messages by using the electrical inspection device as a medium, in the above-mentioned embodiment, the steps of sending and receiving the signature certificate and the signed trust table performed by the electrical inspection device may be performed by a proxy unit. As shown in Figure 21, the communication method may include the following steps:

[0249] S401': The proxy unit requests a certificate from the layer 0 device.

[0250] In some possible implementations, the proxy unit may be separately connected to multiple tier 0 devices and request a signing certificate from each tier 0 device (e.g., ZC 1, ZC 2, and ZC 3).

[0251] For example, the proxy unit may include the proxy unit in the above-described embodiment.

[0252] S402': The layer 0 device sends the signing certificate (and / or SN) to the proxy unit.

[0253] For example, each tier 0 device sends its signing certificate to the proxy unit. For example, if the tier 0 devices include ZC 1, ZC 2, and ZC 3, ZC 1, ZC 2, and ZC 3 send their respective signing certificates to the proxy unit. For example, ZC 1 sends its signing certificate CERT_PK_ZC1 to the proxy unit, ZC 2 sends its signing certificate CERT_PK_ZC2 to the proxy unit, and ZC 3 sends its signing certificate CERT_PK_ZC3 to the proxy unit.

[0254] In some possible implementations, the tier 0 device also transmits the SN of the tier 0 device to the proxy unit.

[0255] S403': The proxy unit sends the signing certificate (and / or SN) to the OEM.

[0256] For example, the proxy unit sends all the signing certificates to the OEM. The proxy unit may send all the signing certificates to the OEM at once, or may send the signing certificates in batches, for example, sending one or more signing certificates each time. This is not specifically limited in the embodiment of the present application.

[0257] In some possible implementations, the proxy unit also sends the SN of the Tier 0 device to the OEM.

[0258] S404': The OEM verifies the signing certificate and generates a trust table for each tier 0 device based on the signing certificate.

[0259] For example, for the specific method of this step, please refer to the corresponding description of S404 shown in FIG.

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

[0261] For example, for the specific method of this step, please refer to the corresponding description of S405 shown in FIG.

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

[0263] For example, for the specific method of this step, please refer to the corresponding description of S406 shown in FIG.

[0264] S407': The OEM PKI server sends multiple signed trust tables to the OEM.

[0265] S408': The OEM sends the signed trust table to the proxy unit.

[0266] S409': The proxy unit sends the signed trust table to the tier 0 device.

[0267] It should be understood that the proxy unit sends the signed trust table to the corresponding layer 0 device, for example, sending ZC 1's signed trust table to ZC 1 and sending ZC 2's signed trust table to ZC 2.

[0268] S410': Each Tier 0 device stores a signed trust table of the Tier 0 device.

[0269] In some possible implementations, before S401' is executed, S4 needs to be further executed. Specifically, the electrical inspection device needs to activate a procedure based on a diagnostic protocol. For example, see the description of S301' for a specific method for activating a procedure by the electrical inspection device. The details will not be described again in this specification.

[0270] In some possible implementations, the proxy unit communicates with another device by using a scalable service-oriented middleware over Internet protocol (SOME / IP) protocol.

[0271] In some possible implementations, the OEM PKI server further issues a device management certificate, and when sending the signed trust table to the Tier 0 device, the OEM PKI server also sends the device management certificate to the Tier 0 device. Thus, after determining the validity and revocation status of the device management certificate, the Tier 0 device can verify the signed trust table by using the device management certificate.

[0272] In some possible implementations, the Tier 0 device's signing certificate is signed by the OEM PKI server and transferred by the OEM. In this case, the OEM stores the Tier 0 device's signing certificate. In this case, the Tier 0 device does not need to send the signing certificate to the OEM (via an electrical inspection device or a proxy unit in the vehicle) and can send only the SN to the OEM TSP.

[0273] In the communication method provided in this embodiment of the present application, the trust tables of tier 0 devices are signed by the OEM PKI server, and external devices cannot modify these signed trust tables. Therefore, a "trust relationship" is established between tier 0 devices by using the signed trust tables with the help of signature binding. Furthermore, tier 0 devices form a "trust ring" based on the public key information contained in the trust tables. Based on the signed trust tables, devices on the ring can perform identity verification on other devices that need to communicate with them and establish secure communication with the devices. This process does not require the participation of any other third parties. Furthermore, tier 0 devices help devices on other layers establish secure communication.

[0274] Furthermore, the two Tier 0 devices can calculate a PSK between each other based on the signed trust table. It should be understood that during the vehicle driving phase, the two Tier 0 devices calculate a session key by using the PSK. The calculated PSK is stored in the security hardware of each device to avoid unauthorized access and / or tampering. It should be understood that this process is the same for all Tier 0 devices that need to calculate a PSK.

[0275] For example, based on ZC 1's trust table, ZC 1 needs to communicate with ZC 2, and vice versa. Therefore, ZC 1 and ZC 2 each calculate a PSK. In some possible implementations, both ZC 1 and ZC 2 determine the other party's signing certificate based on their trust tables. Furthermore, ZC 1 and ZC 2 verify each other's signing certificate by using the OEM PKI server's public key (the public key and the key used to sign the tier 0 device's public key are a key pair). For example, ZC 1 verifies ZC 2's signing certificate by using the OEM PKI server's public key. After the verification is successful, the two devices can obtain each other's public keys from the signing certificates. For example, ZC 1 obtains ZC 2's public key from ZC 2's signing certificate, and ZC 2 obtains ZC 1's public key from ZC 1's signing certificate.

[0276] Furthermore, ZC 1 and ZC 2 can use the Diffie-Hellman (DH) key exchange protocol to calculate the PSK. For example, in a Diffie-Hellman key exchange, ZC 1 generates a random value as a key and generates a first temporary public key based on the key, and ZC 2 generates a random value as a key and generates a second temporary public key based on the key. ZC 1 and ZC 2 exchange their temporary public keys and use the temporary public keys and their respective keys to calculate the same shared key. The shared key can then be used to generate a new session key.

[0277] For example, ZC 1 generates a random value v1 as a key and calculates a first temporary public key G^v1, ZC 2 generates a random value v2 as a key and calculates a second temporary public key G^v2, and ZC 1 and ZC 2 send their respective temporary public keys to each other. Furthermore, ZC 1 calculates a shared key G^v2v1 based on v1 and the second temporary public key G^v2, and ZC 2 calculates a shared key G^v2v1 based on v2 and the first temporary public key G^v1.

[0278] It should be appreciated that in addition to the Diffie-Hellman key exchange protocol, other pre-shared key calculation techniques may also be used to calculate the shared key (eg, PSK).

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

[0280] It should be understood that since Layer 0 devices are connected to each other via Ethernet, the devices may alternatively verify each other and calculate the PSK by using a standard TLS solution, for example TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA can be used for this purpose.

[0281] It should be understood that the above steps may be completed during vehicle production, in other words, the steps may be performed in a trusted and controlled environment where all participating entities are trusted.

[0282] The vehicle production stage typically occurs in a controlled and trusted environment, while the vehicle operation stage is an after-market stage where vehicles are more vulnerable to third-party attacks in real-world operation. These devices communicate with each other while the vehicle is running. To protect such communications, devices may require keys to encrypt communication content and / or identity verification keys to implement message integrity. Therefore, vehicle devices establish session keys at this stage according to the requirements of the vehicle devices. The session keys may be generated once, once a day, or when the vehicle engine is started.

[0283] In some possible implementations, ZC 1 and ZC 2 perform mutual authentication by using a PSK, which is securely stored in security hardware of ZC 1 and ZC 2. When two parties need to communicate, one party needs to prove to the other that it knows the PSK; that is, identity verification is performed. After successful identity verification, the two parties can calculate a new session key using the Diffie-Hellman key exchange protocol or other such protocol and use the session key to encrypt communications and / or calculate authentication information.

[0284] Note that because Layer 0 devices are connected to each other via Ethernet, the devices can alternatively 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.

[0285] The useful life of a vehicle can be several decades long, and devices within the vehicle may be damaged and need to be replaced during this time, and the new devices may need more keys for secure communications. Therefore, the trust table needs to be updated for the new device and other devices that have a direct communication relationship with the new device.

[0286] In some possible implementations, when a device is replaced, the vehicle owner or driver may authorize the OEM to perform the component replacement by entering a password / PIN through a graphical user interface on the vehicle or registered mobile phone. To explain this process, it is assumed that ZC 1 is replaced by ZC 1'. ZC 1' generates a private / public key pair and obtains a public key signing certificate.

[0287] 5 is a schematic flowchart of a communication method according to an embodiment of the present application. More specifically, FIG. 5 shows a method for updating the trust tables of a new device and another device that has a direct communication relationship with the new device. The method may include the following steps:

[0288] S501: The OEM electrical testing device requests a signing certificate from ZC 1'.

[0289] For example, an OEM electrical testing device connects to ZC 1' and requests a signing certificate from ZC 1'.

[0290] S502: ZC 1' sends ZC 1's signing certificate (and / or SN) to the OEM electrical testing device.

[0291] S503: The OEM electrical testing device sends the signing certificate (and / or SN) of ZC 1' to the OEM.

[0292] S504: The OEM verifies the signing certificate of ZC 1', generates a trust table for ZC 1' based on the signing certificate of ZC 1', and updates the trust tables of other Layer 0 devices that communicate with ZC 1'.

[0293] In some possible implementations, ZC 1' is used to replace ZC 1, so the OEM simply imports the contents of ZC 1's trust table into ZC 1's trust table and replaces ZC 1's public key information in a trust table that has information about ZC 1 and belongs to another Tier 0 device with ZC 1's public key information.

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

[0295] It should be understood that the trust tables in this step may include the trust table of ZC 1' and the trust tables of other Tier 0 devices that need to communicate with ZC 1'. The OEM may send all trust tables to the OEM PKI server at once, or may send the trust tables in batches.

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

[0297] For example, the OEM PKI server signs each trust table using the OEM PKI server's private key, generating multiple signed trust tables.

[0298] S507: The OEM PKI server sends the signed trust table to the OEM.

[0299] It should be understood that the signed trust tables in this step include the signed trust table of ZC 1' and the signed trust tables of other tier 0 devices that need to communicate with ZC 1'.

[0300] S508: The OEM sends the signed trust table to the OEM electrical testing device.

[0301] S509: The OEM electrical testing device sends ZC 1's signed trust table to ZC 1'.

[0302] S510: ZC 1' stores the signed trust table of ZC 1'.

[0303] It should be noted that the OEM electrical testing device further separately sends the signed trust tables of other Tier 0 devices that need to communicate with ZC 1' to the corresponding Tier 0 devices, and as a result, the Tier 0 devices update their signed trust tables.

[0304] In some possible implementations, a method for updating the trust tables of a new device and another device that has a direct communication relationship with the new device may alternatively be shown in Figure 22. The method may include the following steps.

[0305] S501': The proxy unit requests a signing certificate from ZC 1'.

[0306] For example, the proxy unit connects to ZC 1' and requests a signing certificate from ZC 1'.

[0307] S502': ZC 1' sends the signing certificate (and / or SN) of ZC 1' to the proxy unit.

[0308] S503': The proxy unit sends the signing certificate (and / or SN) of ZC 1' to the OEM.

[0309] S504': The OEM verifies the signing certificate of ZC 1', generates a trust table for ZC 1' based on the signing certificate of ZC 1', and updates the trust tables of other Layer 0 devices that communicate with ZC 1'.

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

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

[0312] S507': The OEM PKI server sends the signed trust table to the OEM.

[0313] S508': The OEM sends the signed trust table to the proxy unit.

[0314] S504' to S508' are the same as the method steps shown in Figure 5. The details will not be described again in this specification.

[0315] S509': The proxy unit sends the signed trust table of ZC 1' to ZC 1'.

[0316] S510': ZC 1' stores the signed trust table of ZC 1'.

[0317] It should be noted that the proxy unit further separately sends the signed trust tables of other layer 0 devices that need to communicate with ZC 1' to the corresponding layer 0 devices, so that the layer 0 devices update their signed trust tables.

[0318] In some possible implementations, before S501′ is executed, S5 needs to be executed. Specifically, the electrical testing device needs to activate a procedure based on a diagnostic protocol.

[0319] In some possible implementations, the OEM PKI server further issues a device management certificate, and when sending the signed trust table to the Tier 0 device, the OEM PKI server also sends the device management certificate to the Tier 0 device. Thus, after determining the validity and revocation status of the device management certificate, the Tier 0 device can verify the signed trust table by using the device management certificate.

[0320] In some possible implementations, the signing certificate of ZC 1' is signed by the OEM PKI server and transferred by the OEM. In this case, the OEM stores the signing certificate of ZC 1'. In this case, ZC 1' does not need to send the signing certificate to the OEM (via an electrical inspection device or a proxy unit in the vehicle) and can send only the SN to the OEM TSP.

[0321] In some possible implementations, the Tier 0 devices affected by the device replacement can then perform authentication based on the signed trust table and / or signed certificate and calculate the pre-shared key. It should be understood that while the vehicle is in motion, the devices calculate new session keys as they normally would.

[0322] 6 is a schematic flowchart of a communication method according to an embodiment of the present application. More specifically, FIG. 6 shows a key generation method in a layer 1 device. This method is similar to the key generation method in a layer 0 device. In this embodiment of the present application, a controller ECU 1 in the layer 1 device is used as an example for explanation. This method may specifically include the following steps:

[0323] S601: OEM electrical test device activates public / private key generation.

[0324] For example, when an electrical testing device is connected to a tier 1 device, the tier 1 device is activated to generate a public / private key pair.

[0325] S602: ECU 1 generates a private key and calculates a public key based on the private key.

[0326] For example, ECU 1 generates a key "s1" and a corresponding public key G^s1 in security hardware.

[0327] S603: ECU 1 sends the public key to the OEM electrical test device.

[0328] For example, ECU 1 sends public key G^s1 to the OEM electrical test device and keeps private key “s1” in its security hardware.

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

[0330] S605: The PKI server signs the public key of ECU 1.

[0331] In some embodiments, the PKI server signs the public key Ĝs1 by using the PKI's private key as a certificate to generate the signed public key CERT_Ĝs1 for ECU 1.

[0332] Note that ECU 1's signed public key CERT_G^s1 is essentially a signing certificate containing the public key of ECU 1. In this specification, the signing certificate of the Tier 1 device is referred to as ECU 1's signed public key to distinguish it from the signing certificate of the Tier 0 device.

[0333] S606: The PKI server sends the signed public key of ECU 1 to the OEM electrical test device.

[0334] S607: The OEM electrical test device sends ECU 1's signed public key to ECU 1.

[0335] S608: ECU 1 stores the signed public key of ECU 1.

[0336] In some possible implementations, the key generation method in the Layer 1 device may alternatively be shown in Figure 23. This method may include the following steps.

[0337] S601': The electrical testing device activates the proxy unit.

[0338] For example, when an electrical testing device is connected to a vehicle or to a proxy unit of a vehicle, the proxy unit is activated.

[0339] For example, the proxy unit may be the proxy unit in the above-described embodiment.

[0340] In some possible implementations, S601' and S301' are the same step.

[0341] S601″: The proxy unit activates the generation of public / private keys for ECU 1.

[0342] For example, the proxy unit sends a public key request to ECU 1, which then generates a public and private key pair.

[0343] S602': ECU 1 generates a private key and calculates a public key based on the private key.

[0344] For example, for the specific method of this step, please refer to the corresponding description of S602 shown in FIG.

[0345] S603': ECU 1 sends the public key to the proxy unit.

[0346] For example, ECU 1 sends the public key G^s1 to the proxy unit and keeps the private key “s1” in the security hardware.

[0347] S604': The proxy unit sends the public key to the PKI server.

[0348] S605: The PKI server signs the public key of ECU 1.

[0349] For example, for the specific method of this step, please refer to the corresponding description of S605 shown in FIG.

[0350] S606': The PKI server sends the signed public key of ECU 1 to the proxy unit.

[0351] S607': The proxy unit sends the signed public key of ECU 1 to ECU 1.

[0352] S608': ECU 1 stores the signed public key of ECU 1.

[0353] Optionally, the OEM may perform the method shown in Figure 6 during vehicle production. It should be understood that for each Tier 1 device, the method shown in Figure 6 may be used to generate a private / public key pair and obtain a public key signing certificate.

[0354] 7a and 7b are schematic flowcharts of a communication method according to an embodiment of the present application. More specifically, FIG. 7a shows a method for generating a trust table by a tier 0 device that includes information about tier 1 devices. The method may include the following steps:

[0355] S701: The OEM electrical test device requests a signed public key from the Tier 1 device.

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

[0357] For example, each Tier 1 device sends its signing certificate to the OEM electrical testing device. For example, if the Tier 1 devices include ECU 1, ECU 2, and ECU 3, ECU 1, ECU 2, and ECU 3 send their respective signing certificates to the testing device. For example, ECU 1 sends its signed public key CERT_G^s1 to the OEM electrical testing device, ECU 2 sends its signing certificate CERT_G^s2 to the OEM electrical testing device, and ECU 3 sends its signing certificate CERT_G^s3 to the OEM electrical testing device.

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

[0359] More specifically, the OEM electrical test device transmits the signed public key to the OEM, so that the OEM then generates a trust table based on the signed public key.

[0360] S704: The OEM electrical test device requests a signing certificate from the Tier 0 device.

[0361] S705: The tier 0 device sends the signing certificate to the OEM electrical testing device.

[0362] For example, each Tier 0 device sends its signing certificate to the OEM electrical inspection device. For example, if the Tier 0 devices include ZC 1, ZC 2, and ZC 3, ZC 1, ZC 2, and ZC 3 send their respective signing certificates to the inspection devices. For example, ZC 1 sends signing certificate CERT_PK_ZC1 to the OEM electrical inspection device, ZC 2 sends signing certificate CERT_PK_ZC2 to the OEM electrical inspection device, and ZC 3 sends signing certificate CERT_PK_ZC3 to the OEM electrical inspection device.

[0363] S706: The OEM electrical testing device sends the signing certificate to the OEM / OEM PKI server.

[0364] More specifically, the OEM electrical test device sends the signing certificate to the OEM, so that the OEM then generates a trust table based on the signing certificate.

[0365] S707: The OEM / OEM PKI server generates a trust table for each tier 0 device based on the signed public key and the signing certificate, and signs the trust table.

[0366] For example, the OEM verifies the signed public key and the signing certificate, and generates a trust table for each Tier 0 device based on the communication matrix, the signed public key, and the signing certificate. It should be understood that the trust table includes public key information of other Tier 0 devices and other Tier 1 devices that have communication requirements with the Tier 0 device. For example, ZC 1 communicates with ZC 2, ZC 3, ECU 1, and ECU 2, and ZC 2 communicates with ZC 1, ZC 4, ECU 3, and ECU 4. Therefore, the trust table of ZC 1 includes the public key information of ZC 2, ZC 3, ECU 1, and ECU 2, as well as the VIN, and the trust table of ZC 2 includes the public key information of ZC 1, ZC 4, ECU 3, and ECU 4, as well as the VIN. The public key information may be in the form of a signature certificate ID, or in the form of a signature certificate, or in the form of a public key hash. In addition, the trust table may further include a constant point G of generation points for calculating the public key based on the private key. In some possible implementations, the trust table may not include the constant point G of generation points. Instead, the constant point G of generation points is stored in the secure environment of the Tier 0 device and / or the Tier 1 device.

[0367] Additionally, for Tier 0 device ZC 1, a trust table may be generated that includes information about the Tier 0 device and the Tier 1 device, as shown in Table 3. For Tier 0 device ZC 2, a trust table may also be generated that includes information about the Tier 0 device and the Tier 1 device, as shown in Table 4. Alternatively, for Tier 0 devices, two trust tables may be generated, one trust table that includes only information about the Tier 0 device (as shown in Table 5) and the other trust table that includes only information about the Tier 1 device (as shown in Table 6). It should be understood that the latter form of trust table is more easily updated when the Tier 0 or Tier 1 device is replaced.

[0368] [Table 3]

[0369] [Table 4]

[0370] [Table 5]

[0371] [Table 6]

[0372] In some possible implementations, the trust table of a Tier 0 device may further include the SNs of Tier 1 devices. For example, the trust table of ZC 1 may further include the SN of ECU 1 and the SN of ECU 2, and the trust table of ZC 2 may further include the SN of ECU 3 and the SN of ECU 4.

[0373] Additionally, the OEM sends the trust table to the OEM PKI server, which signs the trust table and sends the signed trust table back to the OEM.

[0374] S708: The OEM / OEM PKI server sends the signed trust table to the OEM electrical test device.

[0375] The electrical testing device receives the signed trust table of each tier 0 device.

[0376] S709: The OEM electrical test device sends the signed trust table to the tier 0 device.

[0377] It should be understood that the OEM electrical testing device sends the signed trust table to the corresponding tier 0 device, for example, sending ZC 1's signed trust table to ZC 1 and sending ZC 2's signed trust table to ZC 2.

[0378] S710: The tier 0 device stores the signed trust table.

[0379] For example, the trust table of ZC 1 is stored in ZC 1, and this rule also applies to other trust tables.

[0380] In some possible implementations, a trust table containing information about the tier 0 devices may be further generated for the tier 1 devices. A specific method is shown in Figure 7b. The method may include the following steps:

[0381] S701': The OEM electrical test device requests a signed public key from the Layer 1 device.

[0382] S702': The layer 1 device sends the signed public key to the OEM electrical testing device.

[0383] For example, see the description of S702 for this step, and the details will not be described again in this specification.

[0384] S703': The OEM electrical testing device sends the signed public key to the OEM / OEM PKI server.

[0385] For example, see the description of S703 for this step, and the details will not be described again in this specification.

[0386] 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.

[0387] For example, the OEM verifies the signed public key and generates a trust table for each Tier 1 device based on the communication matrix and the signed public key. It should be understood that the trust table includes public key information of another Tier 0 device that has a communication requirement with the Tier 1 device. For example, ECU 1 communicates with ZC 1. Therefore, the trust table of ECU 1 includes ZC 1's public key (e.g., Ĝzc1) and VIN, as shown in Table 7. In addition, the trust table may further include a constant point G of the generation point for calculating the public key based on the private key. In some possible implementations, the trust table may not include the constant point G of the generation point. Instead, the constant point G of the generation point is stored in the secure environment of the Tier 0 device and / or the Tier 1 device.

[0388] [Table 7]

[0389] In some possible implementations, the trust table of a Tier 1 device may further include the SNs of Tier 0 devices that communicate with the Tier 1 device. For example, the trust table of ECU 1 may further include the SN of ZC 1.

[0390] Additionally, the OEM sends the trust table to the OEM PKI server, which signs the trust table and sends the signed trust table back to the OEM.

[0391] S705': The OEM / OEM PKI sends the signed trust table of the Layer 1 device to the OEM electrical testing device.

[0392] S706': The OEM electrical testing device sends the tier 1 signed trust table to the tier 1 device.

[0393] It should be understood that the OEM electrical testing device sends the signed trust table to the corresponding layer 1 device, for example, sending ECU 1's signed trust table to ECU 1 and ECU 2's signed trust table to ECU 2.

[0394] S707': The layer 1 device stores the signed trust table.

[0395] For example, the trust table for ECU 1 is stored in ECU 1, and similarly for the other trust tables.

[0396] S708': The OEM electrical test device requests a signing certificate from the Tier 0 device.

[0397] S709': The tier 0 device sends the signing certificate to the OEM electrical testing device.

[0398] For example, see the description of S705 for this step, and the details will not be described again in this specification.

[0399] S710': The OEM electrical testing device sends the signing certificate to the OEM / OEM PKI server.

[0400] For example, see the description of S706 for this step, and the details will not be described again in this specification.

[0401] S711': The OEM / OEM PKI server generates a trust table for each tier 0 device based on the signed public key and signing certificate, and signs the trust table.

[0402] For example, see the description of S707 for this step, and the details will not be described again in this specification.

[0403] S712': The OEM / OEM PKI server sends the signed trust table of the tier 0 device to the OEM electrical test device.

[0404] The electrical testing device receives the signed trust table of each tier 0 device.

[0405] S713': The OEM electrical test device sends the Tier 0 device's signed trust table to the Tier 0 device.

[0406] It should be understood that the OEM electrical testing device sends the signed trust table to the corresponding tier 0 device, for example, sending ZC 1's signed trust table to ZC 1 and sending ZC 2's signed trust table to ZC 2.

[0407] S714': The layer 0 device stores the signed trust table.

[0408] For example, the trust table of ZC 1 is stored in ZC 1, and this rule also applies to other trust tables.

[0409] It should be understood that in the method shown in FIG. 7b, the trust table (or signed trust table) generated for the tier 0 device may match the trust table generated for the tier 0 device in the method shown in FIG. 7a.

[0410] It should be noted that in some possible implementations, S704'-S706' need to be performed after S710', i.e., after the OEM obtains the signing certificates of the Tier 0 devices. For example, if the trust table generated for the Tier 1 devices needs to include the signing certificates or signing certificate IDs of the Tier 0 devices that need to communicate with the Tier 1 devices, S704'-S706' need to be performed after S710'.

[0411] It is further noted that in the methods shown in Figures 7a and 7b, the steps performed by the electrical testing device may alternatively be performed by the proxy unit in the above-described embodiments, as shown in Figures 24 and 25.

[0412] In the communication method provided in this embodiment of the present application, a layer 0 device or a layer 1 device can establish a "trust relationship" based on a trust table, and by using the public key information contained in the trust table, can perform identity verification on another device that needs to communicate with the layer 0 device or the layer 1 device and establish secure communication with the device. In this process, the participation of other third parties is not required, and the security threats caused by external access can be effectively avoided.

[0413] 8a and 8b are schematic flowcharts of a communication method according to an embodiment of the present application. More specifically, FIG. 8a illustrates a method for calculating a PSK between a Tier 0 device and a Tier 1 device based on the trust table of the Tier 0 device when the Tier 1 device does not have a trust table. The method may include the following steps:

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

[0415] In some possible implementations, based on ZC 1's trust table, ZC 1 needs to communicate with ECU 1, and vice versa. Therefore, a shared key (e.g., PSK) needs to be calculated between ZC 1 and ECU 1 to be used for session encryption in the subsequent communication process. For example, ZC 1 generates a random number v1 as a key, and calculates a first public key as G^v1 based on the random number v1. For example, the key and the public key may be a DH key pair.

[0416] Additionally, ZC 1 generates a Nonce value N1, which is then used to authenticate ECU 1. It should be understood that a Nonce is an arbitrary or non-repeating random value that is used only once.

[0417] S802: ZC 1 sends the first public key and Nonce value N1 to ECU 1.

[0418] It should be understood that ZC 1 may send the first public key and the Nonce value N1 at once, or may send the first public key and the Nonce value N1 separately.

[0419] S803: ECU 1 calculates the shared key SS.

[0420] For example, ECU 1 may calculate a second public key Ĝv1s1 using the first public key and the private key s1 of ECU 1. Furthermore, a shared key SS is calculated based on the second public key, where SS = F(Ĝv1s1). Herein, F may be a key derivation function or a simple hash function.

[0421] S804: ZC 1 calculates the shared key SS.

[0422] In some possible implementations, ZC 1 determines the public key Ĝs1 of ECU 1 based on the trust table, and the shared key SS is calculated based on the public key Ĝs1 of ECU 1 and the random number v2, where SS = F(Ĝv1s1).

[0423] S805: ECU 1 encrypts Nonce N1 using the shared key SS.

[0424] ECU 1 may perform identity verification and encrypt Nonce N1 using the shared key SS generated by both parties to ensure that the shared key SS is the same.

[0425] S806: ECU 1 sends the encrypted Nonce N1 to ZC 1.

[0426] S807: ZC 1 decrypts the encrypted Nonce N1 by using the shared key SS.

[0427] For example, ZC 1 decrypts the encrypted Nonce N1 by using SS to obtain N1. If the decryption is successful, it proves that ZC 1 and ECU 1 have the same shared key SS.

[0428] S808: ECU 1 generates Nonce value N2.

[0429] S809: ECU 1 transmits Nonce value N2 to ZC 1.

[0430] S810: ZC 1 encrypts Nonce N2 using shared key SS.

[0431] S811: ZC 1 sends the encrypted Nonce N2 to ECU 1.

[0432] S812: ECU 1 decrypts the encrypted Nonce N2 using the shared key SS.

[0433] ECU 1 decrypts the encrypted Nonce N2 using SS to obtain N2. If the decryption is successful, the two-way identity verification and shared key confirmation are completed.

[0434] S813: The ECU 1 stores the shared key SS.

[0435] S814: ZC 1 stores the shared key SS.

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

[0437] It should be understood that the above process is the same for all Tier 0 and Tier 1 devices that need to calculate a PSK. The shared key SS is then used to generate new session keys while the vehicle is in motion.

[0438] In some possible implementations, when the Tier 1 device stores a trust table, the method for calculating the PSK between the Tier 0 device and the Tier 1 device may be based on the trust tables of the Tier 0 device and the Tier 1 device. As shown in Figure 8b, the method may include the following steps:

[0439] S801': ZC 1 generates a random number v1 as a key, calculates a first public key based on v1, and signs the first public key by using ZC 1's private key to generate V1'.

[0440] In some possible implementations, based on ZC 1's trust table, ZC 1 needs to communicate with ECU 1, and vice versa. Therefore, a shared key (e.g., PSK) needs to be calculated between ZC 1 and ECU 1 to be used for session encryption in the subsequent communication process. For example, ZC 1 generates a random number v1 as a key and calculates a first public key as Ĝv1 based on the random number v1. For example, the key and the public key may be a DH key pair. Furthermore, ZC 1 signs the first public key by using ZC 1's private key zc1 to generate V1', i.e., V1'=Sign(Ĝv1,zc1).

[0441] S802': ZC1 sends V1' to ECU1.

[0442] S803': ECU 1 verifies V1' using ZC 1's public key.

[0443] For example, ECU 1 may obtain the public key of ZC 1 based on the trust table.

[0444] It should be appreciated that if V1' is successfully verified, then ZC 1's identity is proven to be valid.

[0445] S804': ECU 1 generates a random number v2 as a key, calculates a second public key G^v2 based on v2, and signs the second public key by using ECU 1's private key to generate V2'.

[0446] For example, V2'=Sign(G^v2,s1).

[0447] S805': ECU 1 sends V2' to ZC 1.

[0448] S806': ZC 1 verifies V2' using ECU 1's public key.

[0449] For example, ZC 1 may obtain the public key of ECU 1 based on the trust table.

[0450] It should be appreciated that if V2' is successfully verified, the identity of ECU 1 is proven to be valid.

[0451] S807': ZC 1 uses ECU 1's public key to calculate the shared key SS.

[0452] For example, ZC 1 uses ECU 1's public key and a random number v2 to calculate a shared key SS, where SS=F(G^v1v2).

[0453] S808': ECU 1 uses ZC 1's public key to calculate the shared key SS.

[0454] For example, ECU 1 uses ZC 1's public key and a random number v1 to calculate a shared key SS, where SS=F(Ĝv1v2).

[0455] In some possible implementations, S807' and S808' may be performed simultaneously or sequentially, for example, S808' may be performed before S807', or S808' may be performed before S802 or S804'.

[0456] It should be understood that generating a PSK is used as an illustrative example in Figures 8a and 8b. In some possible implementations, the method steps shown in Figures 8a and 8b can also be used to generate another security key, such as a diagnostic key, a security on-board communications SecOC key, or another application key.

[0457] 9 is a schematic flowchart of a communication method according to an embodiment of the present application. More specifically, FIG. 9 shows a method for calculating a PSK between layer 1 devices. It should be understood that layer 1 device ECU 1 and layer 1 device ECU 2 do not have each other's public key information or other means of mutual authentication, and layer 0 device ZC 1 stores the public key information of ECU 1 and ECU 2 and information indicating that ECU 1 needs to communicate with ECU 2, so ZC 1 can be used as a "middleman" to help ECU 1 and ECU 2 calculate the PSK. The method may include the following steps:

[0458] S901: ZC 1 generates a random number v, calculates a third public key (G^s2.v) for ECU 1 using ECU 2's public key and the random number v, and calculates a fourth public key (G^s1.v) for ECU 2 using ECU 1's public key and the random number v.

[0459] For example, the random number v and the third public key (G^s2.v) form a DH key pair, and the random number v and the fourth public key (G^s1.v) form a DH key pair.

[0460] S902: ZC 1 sends the public key (G^s2.v) to ECU 1.

[0461] S903: ZC 1 sends the public key (G^s1.v) to ECU 2.

[0462] S904: ECU 1 calculates a first key (G^s2.v.s1) based on the third public key (G^s2.v) and ECU 1's key s1.

[0463] S905: ECU 2 calculates a second key (G^s1.v.s2) based on the fourth public key (G^s1.v) and ECU 2's key s2.

[0464] It should be understood that in this case, both ECU 1 and ECU 2 calculate the same key value. Because ZC 1 does not know key s1 of ECU 1 and key s2 of ECU 2, ZC 1 cannot calculate key G^s1.s2.v. In this way, the shared key calculated by ECU 1 and ECU 2 based on the same key value is not known to a third party, and as a result, communication security can be guaranteed.

[0465] S906: ECU 1 exports the shared key SS.

[0466] S907: ECU 2 exports the shared key SS.

[0467] For example, both ECU 1 and ECU 2 may use the F function to calculate the DH key (i.e., the shared key SS), e.g., SS=F(G^s1.s2.v). The shared key SS is used to generate new session keys when the vehicle is running.

[0468] In some possible implementations, ECU 1 and ECU 2 may further complete identity verification and key confirmation by exchanging encrypted Nonce values using SS, and successful decryption completes two-way identity verification and key confirmation.

[0469] Layer 1 and / or Layer 0 devices with the same PSK can verify each other by using the PSK, a pre-shared key securely stored in security hardware and known only to each party. If the two communicating parties prove they both know the PSK, identity verification is complete. Furthermore, both parties can calculate a new session key using the Diffie-Hellman key exchange protocol or any other such protocol. Once this step is complete, both parties have a new session key to encrypt communication content and / or calculate message identity verification information.

[0470] It should be understood that generating a PSK is used as an example for illustration in Figure 9. In some possible implementations, the method steps shown in Figure 9 can also be used to generate another security key, such as a diagnostic key, a security on-board communications SecOC key, or another application key.

[0471] As mentioned above, the useful life of a vehicle can be as long as several decades, during which time devices in the vehicle may be damaged and need to be replaced. The new Layer 1 device still requires keys to perform secure communication, and the trust table needs to be updated for the new device and other devices that have a direct communication relationship with the new device. It should be understood that after the Layer 1 device is replaced, the process of performing key signing and trust table update for the new Layer 1 device is similar to that of the Layer 0 device. For details, please refer to the description in the above embodiment. The details will not be described again in this specification.

[0472] Layer 2 devices are considered to be resource-limited devices and do not have security hardware. Therefore, the encryption capabilities of these devices are limited. Only 8 bytes of data can be exchanged 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 ECU 1 as an example). The method may include the following steps:

[0473] S1010: Activate key generation.

[0474] For example, please refer to the description in S301 or S601 for this step, and the details will not be described again in this specification.

[0475] S1020: ZC 1 generates a trust token.

[0476] For example, ZC 1 generates a trust token s1, which may be a random number or another form of trust token.

[0477] S1030: ZC 1 sends the trust token to the OEM electrical testing device.

[0478] S1040: The OEM electrical test device sends the trust token to the CAN ECU 1.

[0479] S1050: CAN ECU 1 stores the trust token.

[0480] It should be understood that both ZC 1 and CAN ECU 1 store trust token s1.

[0481] In some possible implementation forms, before the trust token is injected into the CAN ECU 1, the ZC 1 can perform authentication on the CAN ECU 1 based on at least one of the SN, physical fingerprint, authentication chip, and security chip of the CAN ECU 1, and inject the trust token into the CAN ECU 1 after the authentication is successful.

[0482] In some possible implementations, the trust token may alternatively be generated by an electrical testing device and then “injected” separately into ZC 1 and CAN ECU 1, in other words, transmitted to ZC 1 and CAN ECU 1.

[0483] According to the communication method provided in this embodiment of the present application, trust tokens can be pre-embedded in layer 2 devices, so that external key injection can be avoided, key generation in the vehicle / component can be kept to a maximum, and security of communication between layer 0 devices and layer 2 devices in the vehicle can be ensured.

[0484] FIG. 11 shows a method for forming a PSK between a layer 0 device and a layer 2 device, which may include the following steps.

[0485] S1110: ZC 1 generates a random number v1 as a key, calculates a shared key SS based on the trust token and the random number v1, and encrypts SS by using the trust token s1 to obtain SS2.

[0486] S1120: ZC 1 sends SS2 to CAN ECU 1.

[0487] S1130: CAN ECU 1 decrypts SS2 using trust token s1 to obtain SS.

[0488] Furthermore, the CAN ECU 1 and the ZC 1 may generate a new session key based on the shared key SS while the vehicle is running.

[0489] Note that after CAN ECU 1 obtains SS, CAN ECU 1 and ZC 1 can further complete identity verification and key confirmation by exchanging the encrypted Nonce value by using SS. If the encrypted Nonce value is successfully decrypted by using SS, the two-way identity verification and key confirmation are completed. In addition, CAN ECU 1 and ZC 1 delete the trust token s1.

[0490] In some possible implementations, the trust table of the in-vehicle device in the above-described embodiment may further include service-oriented architecture (SOA) service information of another device that communicates with the in-vehicle device. For example, ZC 1 needs to communicate with ZC 2 and ZC 3. The SOA services supported by ZC 2 include Service A, Service B, and Service C, but the only service opened by ZC 2 to ZC 1 is Service A. In this case, in addition to the public key information of ZC 2 and ZC 3, the trust table of ZC 1 may further include related information of Service A of ZC 2. In the above case, it should be understood that ZC 1 can access only Service A of ZC 2, but cannot access Service B and Service C of ZC 2. It should be understood that the "service" may be at least one of a device abstraction service, an atomic service, a composite service, or an application service.

[0491] For ease of understanding, the following provides a brief description of concepts related to "services."

[0492] 1. SOA is an architectural design idea that decomposes a system into relatively independent functional units. The relatively independent functional units are externally referred to as services, and the services and abstract interfaces can be encapsulated. Furthermore, these services communicate with each other by using defined interfaces and protocols. The services of a system can be classified based on layers. For example, the lowest layer services include device abstraction services, atomic services, and composite services, and higher layer services are referred to as apps.

[0493] 2. Atomic Services. Typically, abstract hardware resources such as sensors and actuators are encapsulated in atomic services. Typically, atomic services encapsulate the most basic logical functions, e.g., seat control and window control.

[0494] 3. A composite service is a service formed by invoking and combining atomic services.

[0495] 4. Application services (also referred to as apps) are formed by invoking and combining atomic and / or composite services, and are typically customer-oriented services that encapsulate various application scenarios.

[0496] 5. A device abstraction service is a service in which hardware resources such as sensors and executors are abstracted to provide a device access interface for atomic services. A device abstraction service is generally encapsulated with electrical signals such as motor power signals and Hall signals.

[0497] According to the communication method provided in this embodiment of the present application, in the vehicle generation stage, a certificate associated with a vehicle identity (e.g., VIN) is applied to each Tier 0 device and each Tier 1 device to ensure that the device is uniquely associated with the vehicle in which the device is located. Furthermore, to ensure that only authorized devices can access the device, a device trust table is issued for each device based on the device's certificate. In particular, the Tier 0 device forms a Tier 0 device trust ring based on the trust table. As shown in FIG. 12, each device on the ring can provide different services outside the ring. For example, the Tier 0 device trust ring can provide a vehicle integration unit (VIU) atomic service, a VDC enhancement service, an MDC enhancement service, etc. The Tier 0 device can further assist the Tier 1 device and the Tier 2 device in establishing trust rings between the Tier 1 device and the Tier 2 device, respectively. In some possible implementations, the Tier 0 device can further assist devices outside the vehicle in establishing trust rings. In addition, when a device is started, the device's certificate and trust table are used to verify the authenticity of the device. After successful verification, a session key is distributed, and the session key is periodically refreshed to improve the security of the session key. When a service requires secure communication, the session key is used to establish secure communication to ensure the confidentiality and integrity of the communication data. According to the communication method provided in this embodiment of the present application, the processing of the generated session key is a closed loop within the vehicle, so that the risk of key leakage can be greatly reduced and the complexity of key management can be reduced.

[0498] 13 is a schematic flowchart of a communication method 1300 according to an embodiment of the present application. The method 1300 may be applied to the vehicle shown in FIG. 1 or may be performed by a ZC in the system shown in FIG. 2. The method 1300 includes the following steps:

[0499] S1310: A first node receives a first message from a first device, where the first message includes second node information, and the second node information indicates the second node.

[0500] S1320: The first node determines the second node based on the second node information.

[0501] S1330: The first node generates a security key between the first node and the second node.

[0502] S1340: The first node communicates with the second node based on the security key.

[0503] For example, the first node may be any layer 0 device in the above-mentioned embodiments, such as ZC 1. The second node may be a layer 0 device (e.g., ZC 2) in the above-mentioned embodiments, or may be a layer 1 device (e.g., ECU 1) in the above-mentioned embodiments. The first node and the second node may be located in a first terminal. The first terminal may be a vehicle in the above-mentioned embodiments, or may be another terminal.

[0504] For example, the first message may be a signed trust table in the above embodiment, or may be a signed trust list in another format (e.g., a file) containing information about nodes that have communication requirements with the first node.

[0505] For example, the second node information may include at least one of the signature certificate ID of the second node, the signature certificate of the second node, or the public key hash of the second node in the above-described embodiments, or may include public key information of the second node in another form. Note that if the second node information includes the public key hash of the second node, the second node information further includes identity information of the second node. For example, the identity information of the second node may be the SN of the second node, or other information that can indicate the identity of the second node.

[0506] For example, the first device may be the OEM PKI server in the above-described embodiments, or may be a computing platform in the first terminal, such as at least one of a VDC, an MDC, or a CDC, or may be another trusted device, such as a vehicle control server ICAS 1, an intelligent driving server ICAS 2, an infotainment server ICAS 3, a BDC, a SAS, an MGU, an ADAS super core, or a CSC.

[0507] For example, the security key may be the PSK in the above embodiment.

[0508] For example, for a method for generating a first message, please refer to the description in the above embodiment. The details will not be described again in this specification. For a method for generating a security key between a first node and a second node, please refer to the description in the above embodiment. The details will not be described again in this specification.

[0509] For example, the first node communicating with the second node based on the security key may include: the first node generating a session key for communicating with the second node based on the security key, and further encrypting content of the communication between the first node and the second node based on the session key.

[0510] In some possible implementations, the method 1300 may further include other methods performed by the Layer 0 devices of FIGS.

[0511] According to the communication method provided in this embodiment of the present application, communication nodes establish a "trust relationship" between each other by using a first message. Furthermore, the communication nodes can verify the validity of each other's identities by using the first message, and after the verification is successful, negotiate a shared security key and generate a session key for each communication by using the shared security key. If a service requires secure communication, the session key is used to establish the secure communication, which helps to ensure the confidentiality and integrity of the communication data.

[0512] 14 is a schematic flowchart of a communication method 1400 according to an embodiment of the present application. The method 1400 includes the following steps:

[0513] S1410: A second device receives a first message sent by a first device, where the first message includes second node information, and the second node information indicates the second node.

[0514] For example, the second device may be the OEM in the above-described embodiment. More specifically, the second device may be the OEM TSP.

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

[0516] For example, the second device transmits a first message to the first node via the electrical testing device.

[0517] In some possible implementations, the method 1400 may further include other methods performed by the OEM devices of FIGS.

[0518] According to the communication method provided in this embodiment of the present application, the OEM sends a first message containing second node information to the first node, which results in the establishment of a "trust relationship" between the first node and the second node. This helps the first node and the second node generate a session key based on the first message. Furthermore, if the service requires secure communication, the session key is used to establish secure communication. This helps ensure the confidentiality and integrity of the communication data.

[0519] 15 is a schematic flowchart of a communication method 1500 according to an embodiment of the present application. The method 1500 includes the following steps:

[0520] S1510: The first device receives a second message sent by the second device.

[0521] For example, the second message may be a trust table in the above embodiment, or in another form, a trust list containing information about nodes that have communication requirements with the first node.

[0522] For example, the second message is generated by the second device based on the communication list and the signed public key of the first node.

[0523] For example, the communication list may include the communication matrix in the above-described embodiment.

[0524] S1520: The first device signs the second message to generate the first message.

[0525] For example, for a specific method for generating a first message by signing a second message, please refer to the description in the above embodiment, and the details will not be described again in this specification.

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

[0527] In some possible implementations, the method 1500 may further include other methods performed by the OEM PKI servers of FIGS.

[0528] According to the communication method provided in this embodiment of the present application, a first device generates a signed trust table by signing the trust table, so that the signed trust table cannot be easily modified by another device, which helps to further improve communication security.

[0529] 16 is a schematic flowchart of a communication method 1600 according to an embodiment of the present application. The method 1600 includes the following steps:

[0530] S1610: The electrical testing device receives a first message sent by a first device, where the first message includes second node information, and the second node information indicates a second node.

[0531] For example, the electrical testing device may be the electrical testing device in the above-described embodiments.

[0532] S1620: The electrical testing device sends a first message to the first node.

[0533] In some possible implementations, the method 1600 may further include other methods performed by the electrical testing devices of FIGS.

[0534] 26 is a schematic flowchart of a communication method 1600' according to an embodiment of the present application. The method 1600' includes the following steps:

[0535] S1610′: The proxy unit receives a first message sent by a first device, where the first message includes second node information, and the second node information indicates a second node.

[0536] For example, the proxy unit may be the proxy unit in the above-described embodiment.

[0537] S1620': The proxy unit sends a first message to the first node.

[0538] In some possible implementations, the method 1600' may further include other methods performed by the proxy units of FIGS. 20 to 25.

[0539] According to the communication method provided in this embodiment of the present application, an electrical inspection device or a proxy unit sends a first message including second node information to a first node, thereby establishing a "trust relationship" between the first node and the second node. This helps the first node and the second node generate a session key based on the first message. Furthermore, if a service requires secure communication, using the session key for communication helps ensure the confidentiality and integrity of the communication data.

[0540] 17 is a schematic flowchart of a communication method 1700 according to an embodiment of the present application. The method 1700 includes the following steps:

[0541] S1710: Receive a first public key, the first public key being generated by a first node based on a first message, the first message including second node information, and the second node information indicating the second node.

[0542] S1720: The second node generates a security key based on the first public key, and the security key is used for session encryption between the first node and the second node, or the security key is used for session encryption between the second node and a third node.

[0543] For example, the second node may be a tier 1 device having communication requirements with the first node in the above-mentioned embodiment, and the third node may be a tier 1 device having communication requirements with the second node in the above-mentioned embodiment.

[0544] For example, the first public key may be the first public key in the above-mentioned embodiment, or may be the third public key or the fourth public key in the above-mentioned embodiment.

[0545] For example, the security key may be the shared key SS in the above embodiment.

[0546] In some possible implementations, the method 1700 may further include other methods performed by the layer 1 devices of FIGS.

[0547] According to the communication method provided in this embodiment of the present application, the Layer 1 device can generate a security key based on the first public key sent by the Layer 0 device. The security key can be used to generate a session key required for communication with the Layer 0 device or the Layer 1 device. This helps to ensure the confidentiality and integrity of the communication data.

[0548] In the embodiments of the present application, unless otherwise specified or there is no logical contradiction, the terms and / or descriptions in the embodiments are consistent and can be cross-referenced, and the technical features in different embodiments can be combined according to their internal logical relationships to form new embodiments.

[0549] The above describes in detail the method provided in the embodiment of the present application with reference to Figures 3 to 17. The following describes in detail the device provided in the embodiment of the present application with reference to Figures 18 and 19. It should be understood that the description of the device embodiment corresponds to the description of the method embodiment. Therefore, for the contents not described in detail, please refer to the method embodiment. For the sake of brevity, the details will not be described again in this specification.

[0550] 18 is a block diagram of a communication device 2000 according to an embodiment of the present application. The device 2000 includes a transceiver unit 2010 and a processing unit 2020.

[0551] Optionally, the apparatus 2000 may further include a storage unit. The storage unit may be configured to store instructions and / or data. The processing unit 2020 may read the instructions and / or data in the storage unit to enable the apparatus to implement the above-described method embodiments.

[0552] The apparatus 2000 may include units configured to perform the methods of Figures 13 to 17. Furthermore, the units in the apparatus 2000 and other operations and / or functions described above may be used separately to implement corresponding procedures in the method embodiments of Figures 13 to 17.

[0553] When the apparatus 2000 is configured to perform the method 1300 of FIG. 13, the transceiver unit 2010 may be configured to perform S1310 of the method 1300, and the processing unit 2020 may be configured to perform S1320 to S1340 of the method 1300.

[0554] The apparatus 2000 includes a transceiver unit 2010 configured to receive a first message from a first device, the first message including second node information, the second node information indicating the second node; and a processing unit 2020 configured to determine the second node based on the second node information, generate a security key between the first node and the second node, and communicate with the second node based on the security key.

[0555] In some possible implementations, the processing unit 2020 is specifically configured to generate, by the first node, a security key based on the second node information when the second node stores first node information indicating the first node, and the security key is used for session encryption between the first node and the second node.

[0556] In some possible implementations, the processing unit 2020 is further configured to generate a first random number and generate a security key based on the first random number and the second node information.

[0557] In some possible implementations, the processing unit 2020 is further configured to generate a second random number and generate a first public key based on the first random number. The transceiver unit 2010 is further configured to transmit the second random number and the first public key to a second node and receive a first encrypted value, the first encrypted value being obtained by the second node by encrypting the second random number based on a first security key, the first security key being generated based on the key of the second node and the first public key. The processing unit 2020 is further configured to decrypt the first encrypted value based on the security key and store the security key when the first encrypted value is successfully decrypted.

[0558] In some possible implementations, the processing unit 2020 is further configured to generate a third random number and generate a second public key based on the third random number. The transceiver unit 2010 is further configured to send a first signature generated based on the private key and second public key of the first node to the second node and receive a second signature, the second signature being generated based on the private key and third public key of the second node after the second node successfully verifies the first signature, and the third public key being generated based on a fourth random number generated by the second node. The processing unit is further configured to verify the second signature based on the second node information and, when the second signature is successfully verified, generate, by the first node, a security key based on the third public key and the third random number.

[0559] In some possible implementations, the transceiver unit 2010 is further configured to receive, from the first device, third node information indicating the third node and information indicating that the second node and the third node need to communicate. The processing unit 2020 is further configured to generate a fifth random number, generate a fourth public key based on the fifth random number and the second node information, and generate a fifth public key based on the fifth random number and the third node information. The transceiver unit 2010 is further configured to transmit the fifth public key to the second node and the fourth public key to the third node.

[0560] In some possible implementations, the transceiver unit 2010 is further configured to transmit a signed public key of the first node to the second device before receiving the first message, where the signed public key of the first node is used to generate the first message.

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

[0562] In some possible implementations, the second node's public key information includes at least one of the second node's public key signing certificate, the second node's public key signing certificate identity ID, and a hash value of the second node's public key and the second node's identity information.

[0563] In some possible implementations, the transceiver unit 2010 is further configured to receive service information of a second node from the first device, the service information of the second node indicating services that are present in the second node and that can be accessed by the first node.

[0564] In some possible implementations, the security key includes at least one of a pre-shared key, a diagnostic key, a security on-board communications SecOC key, and another application key.

[0565] In some possible implementations, the processing unit 2020 is further configured to generate a trust token. The transceiver unit 2010 is further configured to transmit the trust token to a fourth node. The processing unit 2020 is further configured to generate a sixth random number and generate a second security key based on the trust token and the sixth random number. The transceiver unit 2010 is further configured to transmit the second security key encrypted by using the trust token to the fourth node, so that the fourth node performs decryption based on the trust token pre-stored by the fourth node to obtain the second security key, and the second security key is used for session encryption between the first node and the fourth node.

[0566] In some possible implementations, the processing unit 2020 is further configured to perform authentication on the fourth node based on at least one of a serial number SN, a physical fingerprint, an authentication chip, or a security chip of the fourth node before the transceiver unit 2010 transmits the trust token to the fourth node. The transceiver unit 2010 is specifically configured to transmit the trust token to the fourth node when the authentication is successful.

[0567] In some possible implementations, the processing unit 2020 is further configured to perform identity authentication with the fourth node based on the second security key and delete the trust token when the identity authentication is successful.

[0568] The apparatus 2000 may be further configured to perform the method of Figure 14. When the apparatus 2000 is configured to perform the method 1400 of Figure 14, the transceiver unit 2010 may be configured to perform S1410 and S1420 of the method 1400.

[0569] The apparatus 2000 includes a transceiver unit 2010 configured to receive a first message transmitted by a first device, the first message including second node information, the second node information indicating the second node, and transmit the first message to the first node.

[0570] In some possible implementations, the apparatus 2000 further includes a processing unit configured to generate a second message based on the signed public key of the first node and a communication list before the transceiver unit receives the first message sent by the first device, the communication list indicating that the first node and the second node need to communicate, and the transceiver unit 2010 is further configured to transmit the second message to the first device.

[0571] Apparatus 2000 may be further configured to perform the method of Figure 15. When apparatus 2000 is configured to perform method 1500 of Figure 15, transceiver unit 2010 may be configured to perform S1510 and S1530 of method 1500, and processing unit 2020 may be configured to perform S1520 of method 1500.

[0572] The apparatus 2000 includes a transceiver unit 2010 configured to receive a second message transmitted by a second device and a processing unit 2020 configured to sign the second message to generate a first message. The transceiver unit 2010 is further configured to transmit the first message to the first node.

[0573] The apparatus 2000 may be further configured to perform the method of Figure 16. When the apparatus 2000 is configured to perform the method 1600 of Figure 16, the transceiver unit 2010 may be configured to perform S1610 and S1620 of the method 1600.

[0574] The apparatus 2000 includes a transceiver unit 2010 configured to receive a first message transmitted by a first device, the first message including second node information, the second node information indicating the second node, and transmit the first message to the first node.

[0575] In some possible implementations, the transceiver unit 2010 is further configured to receive a signed public key of the first node transmitted by the third device and transmit the signed public key of the first node to the first node.

[0576] In some possible implementations, the first device and the third device may be the same device. For example, both may be OEM PKI servers. Alternatively, the first device and the third device may be different devices. For example, the first device may be an OEM PKI server and the third device may be a vendor server.

[0577] When the apparatus 2000 is configured to perform the method 1600' of FIG. 16, the transceiver unit 2010 may be configured to perform S1610' and S1620' of the method 1600'.

[0578] The apparatus 2000 includes a transceiver unit 2010 configured to receive a first message transmitted by a first device, the first message including second node information, the second node information indicating the second node, and transmit the first message to the first node.

[0579] In some possible implementations, the transceiver unit 2010 is further configured to receive a signed public key of the first node transmitted by the first node, and transmit the signed public key of the first node to the first device.

[0580] In some possible implementations, the transceiver unit 2010 is further configured to receive a signed public key of the first node transmitted by the first node and transmit the signed public key of the first node to the second device.

[0581] In some possible implementations, the apparatus 2000 further includes a processing unit 2020. The transceiver unit 2010 is further configured to receive a first signal from the electrical testing device. The processing unit 2020 is configured to control the transceiver unit 2010 to send request information to the first node based on the first signal, where the request information is used to request a signed public key of the first node.

[0582] Apparatus 2000 may be further configured to perform the method of Figure 17. When apparatus 2000 is configured to perform method 1700 of Figure 17, transceiver unit 2010 may be configured to perform S1710 of method 1700, and processing unit 2020 may be configured to perform S1720 of method 1700.

[0583] The apparatus 2000 includes: a transceiver unit 2010 configured to receive a first public key, the first public key generated by a first node based on a first message, the first message including second node information, the second node information indicating the second node; and a processing unit 2020 configured to generate a security key based on the first public key, the security key being used for session encryption between the first node and the second node, or the security key being used for session encryption between the second node and a third node.

[0584] In some possible implementations, the first public key is a public key signed by using the private key of the first node, and the processing unit 2020 is further configured to determine the public key of the first node based on the first message, verify the first public key based on the public key of the first node, generate a fifth random number, and if the verification is successful, generate a security key based on the first public key and the fifth random number.

[0585] It should be understood that the division of units in an apparatus is merely a logical division of functions, and that in actual implementation, the units may be fully or partially integrated into physical entities or physically separated. Additionally, the units in the apparatus may be implemented in the form of software called by a processor. For example, the apparatus includes a processor connected to a memory, which stores instructions, and the processor calls the instructions stored in the memory to implement any one of the functions of the above-described methods or units of the apparatus. The processor may be, for example, a general-purpose processor such as a CPU or a microprocessor, and the memory may be memory within the apparatus or memory external to the apparatus. Alternatively, the units in the apparatus may be implemented in the form of hardware circuits, and some or all of the functions of the units may be implemented by designing the hardware circuits. The hardware circuits may be understood as one or more processors. For example, in one implementation, the hardware circuits are ASICs, and some or all of the functions of the units are implemented by designing logical relationships between elements within the circuits. As another example, in another implementation, the hardware circuits may be implemented by using PLDs. An FPGA is used as an example. An FPGA may include a large number of logic gate circuits, and the connections between the logic gate circuits are configured using a configuration file to implement some or all of the functions of the units. All of the units of the device may be implemented in the form of software called by a processor, or in the form of hardware circuits. Alternatively, some of the units may be implemented in the form of software called by a processor, and the remaining units may be implemented in the form of hardware circuits.

[0586] In this embodiment of the present application, the processor is a circuit having signal processing capabilities. In one implementation, the processor may be a circuit capable of reading and executing instructions, such as a CPU, a microprocessor, a GPU, or a DSP. In another implementation, the processor can implement a specific function based on the logical relationships of the hardware circuit, which may be fixed or reconfigurable. For example, the processor is a hardware circuit implemented by an ASIC or a PLD such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and implementing the hardware circuit configuration may be understood as the process of the processor loading instructions and implementing some or all of the functions of the above-mentioned units. In addition, the processor may be a hardware circuit designed for artificial intelligence, such as an ASIC, for example, an NPU, a TPU, or a DPU.

[0587] It may be appreciated that the units within the apparatus may be configured as one or more processors (or processing circuits) for implementing the above-described methods, such as a CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0588] In addition, all or some of the units in the device may be integrated or 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 configured to implement any one of the methods or the functions of the units of the device. The at least one processor may be of different types, for example, a CPU and an FPGA, a CPU and an artificial intelligence processor, or a CPU and a GPU.

[0589] 19 is a block diagram of a communication device according to an embodiment of the present application. The communication device 2100 shown in FIG. 19 may include a processor 2110, a transceiver 2120, and a memory 2130. The processor 2110, the transceiver 2120, and the memory 2130 are connected via an internal connection path. The memory 2130 is configured to store instructions. The processor 2110 is configured to execute the instructions stored in the memory 2130, so that the transceiver 2120 receives / transmits some parameters. Optionally, the memory 2130 may be coupled to the processor 2110 via an interface or may be integrated with the processor 2110.

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

[0591] In the implementation process, the steps of the above-mentioned method may be implemented by using instructions in the form of integrated logic circuits of hardware or software in the processor 2110. The methods disclosed with reference to the embodiments of the present application may be directly executed by a hardware processor or may be executed by using a combination of hardware and software modules in the processor. The software modules may 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, an electrically erasable programmable memory, or a register. The storage medium is located in the memory 2130. The processor 2110 reads information in the memory 2130 and completes the steps of the method in combination with the hardware of the processor. To avoid repetition, the details will not be described again in this specification.

[0592] The processor 2110 may be a general-purpose CPU, a microprocessor, an ASIC, a GPU, or one or more integrated circuits configured to execute associated programs to implement the communication method in the method embodiments of the present application. Alternatively, the processor 2110 may be an integrated circuit chip and have signal processing capabilities. In a specific implementation process, the steps of the communication method in the present application may be completed by using instructions in the form of hardware integrated logic circuits or software within the processor 2110. Alternatively, the processor 2110 may be a general-purpose processor, a DSP, an ASIC, an FPGA or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The methods, steps, and logical block diagrams disclosed in the embodiments of the present application may be implemented or performed. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc. The steps of the methods disclosed with reference to the embodiments of the present application may be performed and completed directly by a hardware decoding processor, or may be performed and completed using a combination of hardware modules and software modules within the decoding processor. The software module can be located in a storage medium that is mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory 2130. The processor 2110 reads information in the memory 2130 and, in combination with the processor hardware, executes the communication method in the method embodiment of the present application.

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

[0594] The transceiver 2120 implements communication between the apparatus 2100 and another device or communication network using a transceiver device, for example, but not limited to, a transceiver.

[0595] An embodiment of the present application further provides a communication system, the system including the device 2000 or the device 2100.

[0596] An embodiment of the present application further provides a vehicle. In some possible implementations, the vehicle may include the device 2000 or the device 2100. For example, if the device 2000 (or the device 2100) is an apparatus for performing the method of FIG. 13 or 17, the vehicle may include the device 2000 (or the device 2100).

[0597] An embodiment of the present application further provides a terminal device. In some possible implementations, the terminal device may include the apparatus 2000 or the apparatus 2100. For example, when the apparatus 2000 (or the apparatus 2100) is an apparatus for performing the method of FIG. 14, FIG. 15, or FIG. 16, the terminal device may include the apparatus 2000 (or the apparatus 2100).

[0598] An embodiment of the present application further provides a computer-readable medium, which stores program code, which, when executed on a computer, enables the computer to perform the methods of Figures 3 to 17.

[0599] An embodiment of the present application further provides a chip including at least one processor and a memory, wherein the at least one processor is coupled to the memory and configured to read and execute instructions in the memory to perform the methods of Figures 3 to 17.

[0600] It should be understood that the sequence numbers of the processes do not mean the execution sequence in various embodiments of the present application. The execution order of the processes should be determined according to the functions and internal logic of the processes, and should not be construed as any limitation on the implementation process of the embodiments of the present application.

[0601] Those skilled in the art may recognize that, in combination with the examples described in the embodiments disclosed herein, the units and algorithm steps may be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether a function is performed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods to implement the described functions for each specific application, but the implementation form should not be considered to exceed the scope of the present application.

[0602] For the sake of convenient and concise description, it can be clearly understood by those skilled in the art that for the detailed operation processes of the above-mentioned systems, devices and units, please refer to the corresponding processes in the above-mentioned method embodiments, and the details will not be described again in this specification.

[0603] In the embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the described device embodiments are merely examples. For example, the division into units is merely a logical division of function, and other divisions may be used in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. In addition, the shown or described mutual couplings or direct couplings or communication connections may be implemented via some interfaces. Indirect couplings or communication connections between devices or units may be implemented electronically, mechanically, or in other forms.

[0604] Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, and may be located in one location or distributed over multiple network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

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

[0606] When a function is implemented in the form of a software functional unit and sold or used as an independent product, the function may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may essentially, or a portion of the technical solution, be implemented in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for instructing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present application. The storage medium includes any medium capable of storing program code, such as a USB flash drive, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0607] The above description is merely a specific implementation form of the present application and is not intended to limit the scope of protection of the present application. Any variations or replacements that can be easily conceived by those skilled in the art within the technical scope disclosed in the present application shall fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the scope of protection of the claims. [Explanation of symbols]

[0608] 1 device 2 Devices 100 vehicles 120 Sensing System 130 Display device 150 Computing Platforms 151 processors 152 processors 15n processor 200 In-vehicle communication network 1300 Communication Methods 1400 Communication Methods 1500 Communication Methods 1600 Communication Methods 1600' Communication Method 1700 Communication Methods 2000 Communication Equipment 2010 Transceiver Unit 2020 Processing Unit 2100 Communication Equipment 2110 processor 2120 transceiver 2130 memory

Claims

1. 1. A communication method comprising: receiving, by a first node, a first message from a first device, the first message including second node information, the second node information indicating the second node; determining, by the first node, the second node based on the second node information; generating, by the first node, a security key between the first node and the second node; communicating, by the first node, with the second node based on the security key; A communication method, including:

2. The step of generating, by the first node, a security key between the first node and the second node includes:

2. The method of claim 1, further comprising: when the second node stores first node information indicating the first node, generating, by the first node, the security key based on the second node information, the security key being used for session encryption between the first node and the second node.

3. The method comprises: generating, by the first node, a first random number; The step of generating, by the first node, a security key between the first node and the second node includes: The method of claim 1 or 2, comprising generating, by the first node, the security key based on the first random number and the second node information.

4. The method comprises: generating, by the first node, a second random number; generating, by the first node, a first public key based on the first random number; transmitting, by the first node, the second random number and the first public key to the second node; receiving, by the first node, a first encrypted value, the first encrypted value being obtained by the second node by encrypting the second random number based on a first security key, the first security key being generated based on a key of the second node and the first public key; decrypting, by the first node, the first encrypted value based on the security key; 4. The method of claim 3, further comprising: upon successful decryption of the first encrypted value, storing, by the first node, the security key.

5. The method comprises: generating, by the first node, a third random number; generating, by the first node, a second public key based on the third random number; sending, by the first node, a first signature generated based on the private key of the first node and the second public key to the second node; receiving, by the first node, a second signature, the second signature being generated based on a private key of the second node and a third public key after the second node successfully verifies the first signature, the third public key being generated based on a fourth random number generated by the second node; and verifying, by the first node, the second signature based on the second node information; The step of generating, by the first node, a security key between the first node and the second node includes:

3. The method of claim 1, further comprising generating, by the first node, the security key based on the third public key and the third random number if the second signature is successfully verified.

6. The method comprises: receiving, by the first node, 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; generating, by the first node, a fifth random number; generating, by the first node, a fourth public key based on the fifth random number and the second node information; generating, by the first node, a fifth public key based on the fifth random number and the third node information; transmitting, by the first node, the fifth public key to the second node; The method of claim 1 , further comprising the step of: transmitting, by the first node, the fourth public key to the third node.

7. Prior to the step of receiving, by the first node, a first message, the method further comprises:

7. The method of claim 1, further comprising the step of transmitting, by the first node, a signed public key of the first node to a second device, wherein the signed public key of the first node is used to generate the first message.

8. Prior to the step of receiving, by the first node, a first message, the method further comprises:

8. The method of claim 1, further comprising the step of transmitting, by the first node, the signed public key of the first node to a fourth device, wherein the signed public key of the first node is used to generate the first message.

9. The method of claim 1 , wherein the second node information includes public key information of the second node.

10. The public key information of the second node is a public key signing certificate of the second node; a public key signing certificate identity ID of the second node; and 10. The method of claim 9, including at least one of a public key of the second node and a hash value of identity information of the second node.

11. The method comprises:

11. The method of claim 1, further comprising receiving, by the first node, service information of the second node from the first device, the service information of the second node indicating services that are present in the second node and that can be accessed by the first node.

12. 12. The method of claim 1, wherein the security keys include at least one of a pre-shared key, a diagnostic key, a security on-board communications SecOC key, and another application key.

13. The method comprises: generating, by the first node, a trust token; transmitting, by the first node, the trust token to a fourth node; generating, by the first node, a sixth random number; generating, by the first node, a second security key based on the trust token and the sixth random number; 13. The method of claim 1, further comprising: sending, by the first node, the second security key encrypted by using the trust token to the fourth node, so that the fourth node performs decryption based on the trust token pre-stored by the fourth node to obtain the second security key, which is used for session encryption between the first node and the fourth node.

14. Prior to the step of transmitting, by the first node, the trust token to a fourth node, the method further comprises: The method further includes performing, by the first node, authentication on the fourth node based on at least one of a serial number SN, a physical fingerprint, an authentication chip, or a security chip of the fourth node; the step of transmitting, by the first node, the trust token to a fourth node comprises:

14. The method of claim 13, comprising transmitting, by the first node, the trust token to the fourth node if the authentication is successful.

15. The method comprises: performing, by the first node, identity authentication with the fourth node based on the second security key; 15. The method of claim 13 or 14, further comprising the step of: deleting, by the first node, the trust token if the identity authentication is successful.

16. 1. A communication method comprising: receiving, by a second device, a first message sent by a first device, the first message including second node information, the second node information indicating a second node; transmitting, by the second device, the first message to a first node; A communication method, including:

17. Before the step of receiving, by the second device, the first message transmitted by the first device, the method further comprises: generating, by the second device, a second message based on the signed public key of the first node and a communication list, the communication list indicating that the first node and the second node need to communicate; 17. The method of claim 16, further comprising the step of: transmitting, by the second device, the second message to the first device.

18. the second device is an electrical testing device, and the method includes: receiving, by the second device, the signed public key of the first node sent by a third device; 17. The method of claim 16, further comprising: transmitting, by the second device, the signed public key of the first node to the first node.

19. 1. A communication method comprising: receiving, by the first device, a second message sent by the second device; signing, by the first device, the second message to generate a first message; transmitting, by the first device, the first message to a first node; A communication method, including:

20. 1. A communication method comprising: receiving, by a second node, a first public key, the first public key generated by the first node based on a first message, the first message including second node information, the second node information indicating the second node; generating, by the second node, a security key based on the first public key, the security key being used for session encryption between the first node and the second node, or the security key being used for session encryption between the second node and a third node; A communication method, including:

21. The first public key is a public key signed by using a private key of the first node, and the method includes: determining, by the second node, a public key of the first node based on the first message; verifying, by the second node, the first public key based on the public key of the first node; generating, by the second node, a fifth random number; generating, by the second node, a security key based on the first public key, 21. The method of claim 20, further comprising, if the verification is successful, generating, by the second node, the security key based on the first public key and the fifth random number.

22. a first node, a transceiver unit configured to receive a first message from a first device, the first message including second node information, the second node information indicating a second node; a processing unit for determining the second node based on the second node information; generating a security key between the first node and the second node; a processing unit configured to communicate with the second node based on the security key; a first node comprising:

23. The processing unit 23. The first node of claim 22, wherein when the second node stores first node information indicating the first node, the first node generates the security key based on the second node information, and the security key is specifically configured to be used for session encryption between the first node and the second node.

24. The processing unit Generate a first random number, 24. The first node of claim 22 or 23, further configured to generate the security key based on the first random number and the second node information.

25. The processing unit Generate a second random number, further configured to generate a first public key based on the first random number; the transceiver unit transmits the second random number and the first public key to the second node; receiving a first encrypted value, the first encrypted value being obtained by the second node by encrypting the second random number based on a first security key, the first security key being generated based on a key of the second node and the first public key; the processing unit decrypts the first encrypted value based on the security key; 25. The first node of claim 24, further configured to store the security key upon successful decryption of the first encrypted value.

26. The processing unit Generate a third random number, further configured to generate a second public key based on the third random number; the transceiver unit transmits to the second node a first signature generated based on the private key of the first node and the second public key; receiving a second signature, the second signature being generated based on a private key and a third public key of the second node after the second node successfully verifies the first signature, the third public key being generated based on a fourth random number generated by the second node; The processing unit Verifying the second signature based on the second node information; 24. The first node of claim 22 or 23, further configured to, if the second signature is successfully verified, generate, by the first node, the security key based on the third public key and the third random number.

27. The transceiver unit further configured to receive, 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 generates a fifth random number; generating a fourth public key based on the fifth random number and the second node information; further configured to generate a fifth public key based on the fifth random number and the third node information; the transceiver unit transmits the fifth public key to the second node; 27. The first node of claim 22, further configured to transmit the fourth public key to the third node.

28. The transceiver unit 28. The first node of claim 22, further configured to: before receiving the first message, send a signed public key of the first node to a second device, the signed public key of the first node being used to generate the first message.

29. The transceiver unit 29. The first node of claim 22, further configured to send a signed public key of the first node to a fourth device, the signed public key of the first node being used to generate the first message.

30. 30. The first node of claim 22, wherein the second node information includes public key information of the second node.

31. The public key information of the second node is a public key signing certificate of the second node; a public key signing certificate identity ID of the second node; and 31. The first node of claim 30, comprising at least one of a public key of the second node and a hash value of identity information of the second node.

32. The transceiver unit 32. The first node of claim 22, further configured to receive service information of the second node from the first device, the service information of the second node indicating services that are present in the second node and that can be accessed by the first node.

33. 33. The first node of claim 22, wherein the security keys include at least one of a pre-shared key, a diagnostic key, a security on-board communications SecOC key, and another application key.

34. The processing unit further configured to generate a trust token; the transceiver unit is further configured to transmit the trust token to a fourth node; the processing unit generates a sixth random number; further configured to generate a second security key based on the trust token and the sixth random number; 34. The first node of claim 22, further configured: the transceiver unit transmits the second security key encrypted by using the trust token to the fourth node, so that the fourth node performs decryption based on the trust token pre-stored by the fourth node to obtain the second security key; and the second security key is used for session encryption between the first node and the fourth node.

35. The processing unit Before the transceiver unit transmits the trust token to the fourth node, the transceiver unit is further configured to perform authentication with the fourth node based on at least one of an authentication code SN, a physical fingerprint, an authentication chip, or a security chip of the fourth node; 35. The first node of claim 34, wherein the transceiver unit is specifically configured to transmit the trust token to the fourth node when the authentication is successful.

36. The processing unit performing identity authentication on the fourth node based on the second security key; 36. The first node of claim 34 or 35, further configured to delete the trust token if the identity authentication is successful.

37. a second device, receiving a first message sent by a first device, the first message including second node information, the second node information indicating a second node; A second device comprising a transceiver unit configured to transmit the first message to the first node.

38. The second device a processing unit configured to generate a second message based on the signed public key of the first node and a communication list before the transceiver unit receives the first message sent by the first device, the communication list indicating that the first node and the second node need to communicate; 38. The second device of claim 37, wherein the transceiver unit is further configured to transmit the second message to the first device.

39. When the second device is an electrical testing device, the transceiver unit receiving a signed public key of the first node sent by a third device; 38. The second device of claim 37, further configured to transmit the signed public key of the first node to the first node.

40. a first device, a transceiver unit configured to receive a second message transmitted by a second device; a processing unit configured to sign the second message to generate a first message; The first device, wherein the transceiver unit is further configured to transmit the first message to a first node.

41. a second node, a transceiver unit configured to receive a first public key, the first public key being generated by a first node based on a first message, the first message including second node information, the second node information indicating the second node; a processing unit configured to generate a security key based on the first public key, the security key being used for session encryption between the first node and the second node, or the security key being used for session encryption between the second node and a third node; and a second node.

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

43. A communication device, a memory configured to store a computer program; A communications device comprising: a processor configured to execute the computer program stored in the memory, such that the device performs the method of any one of claims 1 to 15, or the method of claim 20 or 21.

44. A communication device, a memory configured to store a computer program; A processor configured to execute the computer program stored in the memory, such that the device performs the method of any one of claims 16 to 19.

45. A communication system, said system comprising the first node according to any one of claims 22 to 36 and the second node according to claim 41 or 42.

46. the first node generates a first random number and generates a security key based on the first random number and second node information, the second node information indicating the second node; the first node generates a first public key based on the first random number; the first node transmitting the first public key to the second node; the second node receives the first public key, generates a first security key based on the second node's private key and the first public key, and encrypts a second random number based on the first security key to obtain a first encrypted value; the second node sending 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; 46. The system of claim 45, wherein when the first node successfully decrypts the first encrypted value, the first node stores the security key.

47. the first node generates a third random number and generates a second public key based on the third random number; the first node sends a first signature to the second node, the first signature being generated based on the private key of the first node and the second public key; the second node receives the first signature, generates a fourth random number, and generates a third public key based on the fourth random number; if the first signature is successfully verified, the second node generates a second signature based on the private key and the third public key of the second node and sends the second signature to the first node; the second node generates a third security key based on the fourth random number and the second public key; 47. The system of claim 46, wherein the first node receives the second signature, verifies the second signature based on the second node information, and if the second signature is successfully verified, generates a fourth security key based on the third public key and the third random number.

48. The system further comprises the first device of claim 40, wherein the second node comprises a first apparatus and a second apparatus; the first node receives, from the first device, 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; 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 transmits the fifth public key to the first device; the first node transmitting 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 first device's private key and the fifth public key; 48. The system of claim 45, wherein the second device receives the fourth public key and generates a sixth security key based on the second device's private key and the fourth public key.

49. A vehicle comprising a first node according to any one of claims 22 to 36, and / or a second node according to any one of claims 41 and 42, and / or a communication device according to claim 43.

50. A terminal device comprising a second device according to claims 37 to 39, a first device according to claim 40 or a communication apparatus according to claim 44.

51. 22. A computer-readable storage medium storing a computer program that, when executed by a computer, implements the method of any one of claims 1 to 21.

52. A chip comprising a processor and a data interface, the processor reading instructions stored in a memory via the data interface to perform the method of any one of claims 1 to 21.

53. 1. A communication method comprising: receiving, by a fourth device, a first message sent by a first device, the first message including second node information, the second node information indicating a second node; transmitting, by the fourth device, the first message to a first node; A communication method, including:

54. The method comprises: receiving, by the fourth device, a public key of the first node sent by the first node, the public key of the first node being used to generate a signed public key of the first node; 54. The method of claim 53, further comprising: transmitting, by the fourth device, the public key of the first node to the first device.

55. The method comprises: receiving, by the fourth device, the signed public key of the first node sent by the first node; 55. The method of claim 53 or 54, further comprising the step of: transmitting, by the fourth device, the signed public key of the first node to a second device.

56. Before the step of receiving, by the fourth device, the signed public key of the first node transmitted by the first node, the method further comprises: receiving, by the fourth device, a first signal from an electrical testing device; 56. The method of claim 54 or 55, further comprising: sending, by the fourth device, request information to the first node based on the first signal, the request information being used to request the public key of the first node.

57. a fourth device, receiving a first message sent by a first device, the first message including second node information, the second node information indicating a second node; A fourth device comprising a transceiver unit configured to transmit, by the fourth device, the first message to a first node.

58. The transceiver unit receiving a public key of the first node sent by the first node, the public key of the first node being used to generate a signed public key of the first node; 58. The fourth device of claim 57, further configured to transmit the public key of the first node to the first device.

59. The transceiver unit receiving the signed public key of the first node sent by the first node; 59. The fourth device of claim 57 or 58, further configured to send the signed public key of the first node to a second device.

60. The fourth device further comprises a processing unit, and the transceiver unit further configured to receive a first signal from the electrical testing device; 60. The fourth device of claim 58 or 59, wherein the processing unit is configured to control the transceiver unit to send request information to the first node based on the first signal, the request information being used to request the public key of the first node.

61. 1. A communication system comprising: the communication system comprises a first node and a fourth device; A communication system, wherein the first node sends a signed public key of the first node to the fourth device, the signed public key of the first node is used to generate a first message, the first message includes second node information, the second node information indicates a second node, and the fourth device sends the first message to the first node.

62. 62. The system of claim 61, wherein before the first node transmits the signed public key of the first node to the fourth device, the fourth device receives a first signal from an electrical testing device, and the fourth device transmits request information to the first node based on the first signal, the request information being used to request the signed public key of the first node.

63. A communication system, the communication system comprising a second device; the second device receives a signed public key of the first node sent by the first node, the signed public key of the first node is used to generate a first message, the first message includes second node information, the second node information indicates the second node; The second device transmits the first message to the first node.

64. The system further comprises a first device; the second device generates a second message based on the signed public key of the first node and a communication list, the communication list indicating that the first node and the second node need to communicate; the second device sends the second message to the first device; 64. The system of claim 63, wherein the first device signs the second message to generate the first message and sends the first message to the second device.

Images