Key transmission method and device

Abstract

An embodiment of this application discloses a key transmission method and apparatus. When a first condition is met, a first in-vehicle component sends a random number to a second in-vehicle component. The first condition includes rebooting or waking up the first in-vehicle component. The first in-vehicle component encrypts the random number using a first key stored in the first in-vehicle component to obtain a first ciphertext. The first in-vehicle component receives a second ciphertext from the second in-vehicle component. The second ciphertext is associated with a second key and the random number stored in the second in-vehicle component. If the first ciphertext is different from the second ciphertext, the first in-vehicle component sends a third ciphertext to the second in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key. When the first in-vehicle component is rebooted or woken up, the first in-vehicle component is likely to update the key. Therefore, the above method can resolve key mismatches between different in-vehicle components and improve the reliability of communication between in-vehicle components.

Description

[Technical Field]

[0001] This application relates to the field of communication technology, and in particular to a key transmission method and apparatus. [Background technology]

[0002] Data may be transmitted between different in-vehicle components of a vehicle to cooperatively complete related services for the vehicles. For example, in an autonomous driving scenario, data including geographic location information may be transmitted between different in-vehicle components of a vehicle to cooperatively complete map-related services.

[0003] To ensure secure communication between different in-vehicle components, the in-vehicle components may encrypt or decrypt data using keys, but in practical applications, there may be key mismatches between different in-vehicle components, resulting in low reliability of data transmission between different in-vehicle components. Summary of the Invention

[0004] The embodiments of this application provide a key transmission method and apparatus for resolving key mismatches between different in-vehicle components.

[0005] According to a first aspect, a key transmission method is provided. The method may be applied to a first in-vehicle component or a chip in the first in-vehicle component. For example, the method is applied to the first in-vehicle component. The method includes: when a first condition is met, the first in-vehicle component sends a random number to a second in-vehicle component. The first condition includes restarting or waking up the first in-vehicle component. The first in-vehicle component encrypts the random number using a first key stored in the first in-vehicle component to obtain a first ciphertext. The first in-vehicle component receives a second ciphertext from the second in-vehicle component. The second ciphertext is associated with a second key and the random number stored in the second in-vehicle component. If the first ciphertext differs from the second ciphertext, the first in-vehicle component sends a third ciphertext to the second in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key. The first key is utilized to encrypt data that includes at least the geographic location information.

[0006] When the first in-vehicle component is restarted or woken up, the first in-vehicle component is likely to update the key. Therefore, through the above method, when the second in-vehicle component stores the key, the mismatch of the key between the first in-vehicle component and the second in-vehicle component can be detected in time, and the first in-vehicle component and the second in-vehicle component can be detected in time. No. 2 Key synchronization between the in-vehicle components is performed to avoid data transmission failure due to key mismatch between different in-vehicle components, which can improve the reliability of communication between the in-vehicle components.

[0007] In a possible implementation, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0008] According to a second aspect, a key transmission method is provided. The method may be applied to a second in-vehicle component or a chip in the second in-vehicle component. For example, the method is applied to the second in-vehicle component. The method includes: the second in-vehicle component receives a random number from the first in-vehicle component; the second in-vehicle component transmits a second ciphertext to the first in-vehicle component; the second ciphertext is associated with a second key and the random number stored in the second in-vehicle component; and the second in-vehicle component receives a third ciphertext from the first in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key. The first key is used to encrypt data including at least geographic location information.

[0009] In a possible implementation, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0010] In one possible design, the method further includes: the first in-vehicle component encrypting the random number using the second key to generate a second ciphertext. In this manner, the second ciphertext can be associated with the second key and the random number stored in the second in-vehicle component, whereby the first in-vehicle component determines, based on the second ciphertext, whether the second key matches the first key stored in the first in-vehicle component.

[0011] For the advantageous effects of the implementation of the second aspect, please refer to the advantageous effects of the corresponding implementation of the first aspect, and the details will not be described again here.

[0012] According to a third aspect, a key transmission method is provided. The method may be applied to a first in-vehicle component or a chip in the first in-vehicle component. For example, the method is applied to the first in-vehicle component. The method includes: when a second condition is met, the first in-vehicle component generates a third ciphertext; the first in-vehicle component transmits the third ciphertext to a second in-vehicle component; the third ciphertext includes information obtained by encrypting the first key using a third key; the first key is utilized to encrypt data including at least geographic location information; the second condition includes one or more of restarting the first in-vehicle component, waking up the first in-vehicle component, updating a key by the first in-vehicle component, or receiving key request information from the second in-vehicle component by the first in-vehicle component. The key request information is utilized to request the first in-vehicle component to deliver a key (e.g., the key request information is utilized to request the first in-vehicle component to obtain the first key).

[0013] The first in-vehicle component is likely to update the key when it is restarted, when it is woken up, when it updates the key, etc. When the first in-vehicle component receives key request information from the second in-vehicle component, it is likely that the second in-vehicle component does not have the key. Therefore, through the above method, in order to avoid data transmission failure due to key inconsistency between different in-vehicle components when the second in-vehicle component does not store the key, the first in-vehicle component and the second in-vehicle component can be connected. No. 2Key synchronization between the in-vehicle components can be performed, which can improve the reliability of communication between the in-vehicle components.

[0014] In a possible design, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0015] According to a fourth aspect, a key transmission method is provided. The method may be applied to a second in-vehicle component or a chip in the second in-vehicle component. For example, the method is applied to the second in-vehicle component. The method includes: when a third condition is met, the second in-vehicle component sends key request information to the first in-vehicle component. The key request information is used to request the first in-vehicle component to deliver a key (e.g., the key request information is used to request the first in-vehicle component to obtain a first key). The first key is used to encrypt data including at least geographic location information. The third condition includes one or more of restarting the second in-vehicle component, waking up the second in-vehicle component, or not storing a key in the second in-vehicle component. The second in-vehicle component receives a third ciphertext from the first in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key.

[0016] When the second in-vehicle component is restarted, when the second in-vehicle component is woken up, or when the second in-vehicle component does not store the key, it is highly likely that the second in-vehicle component does not have the key. Therefore, through the above method, the second in-vehicle component can quickly No. 1and a key can be obtained from the first in-vehicle component, and when the second in-vehicle component does not store the key, data transmission failure due to key mismatch between different in-vehicle components can be avoided. No. 2 Key synchronization between the in-vehicle components can be performed, which can improve the reliability of communication between the in-vehicle components.

[0017] In a possible design, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0018] According to a fifth aspect, there is provided a key transmission method. The method may be applied to a first in-vehicle component or a chip in the first in-vehicle component. For example, the method is applied to the first in-vehicle component. The method includes: the first in-vehicle component generates a first public-private key pair. The first public-private key pair includes a first public key and a first private key. The first in-vehicle component sends first request information to a first server. The first request information is used to apply for a second certificate. The first request information includes the first public key and the first certificate. The first request information is signed using the first certificate. The first certificate is used to at least prove that the first in-vehicle component is qualified to obtain data related to the geographic location information. The first in-vehicle component receives first response information from the first server. The first response information includes the second certificate. The second certificate includes the first public key. The second certificate is utilized by the first in-vehicle component to obtain at least a first key, which is utilized to encrypt data including at least the geographic location information.

[0019] In the above method, the first in-vehicle component applies for a second certificate based on the first certificate, and accesses a service provided by a second server based on the second certificate (e.g., obtains a first key from the second server). This can reduce the risk that the first certificate will be leaked or tampered with when the first in-vehicle component accesses a service provided by the second server, and can reduce the frequency of using the first certificate to improve the security performance of the in-vehicle component.

[0020] Additionally, in the above method, the certificate used for service registration (the second certificate) is separated from the certificate used for device validity verification (the first certificate). After the first in-vehicle component loses the original second certificate or the original second certificate is leaked or tampered with, the first in-vehicle component may update the second certificate based on the first certificate to improve efficiency of obtaining services from the second server by the first in-vehicle component.

[0021] In one possible design, the first in-vehicle component may send first request information to the first server through the second server. In response, the first in-vehicle component may receive first response information from the first server through the second server. The first server corresponds to a certificate provider. The second server corresponds to a map provider.

[0022] In this manner, the first in-vehicle component can obtain a certificate from the certificate provider through the map provider. For example, when registering with the map provider to enable a map service, the first in-vehicle component obtains a certificate from the certificate provider through the map provider, thereby triggering a certificate application by the service and reducing the risk of certificate misuse. Additionally, compared to the first server receiving request information from multiple in-vehicle components, the first server receiving request information uniformly from the second server can reduce the risk of communication congestion and improve communication reliability.

[0023] In one possible design, the first response information further includes a third certificate. The first response information is signed using the third certificate. The method further includes: the first in-vehicle component verifying the signature of the first response information using the third certificate. If the verification is successful, the first in-vehicle component stores the second certificate; if the verification is unsuccessful, the first in-vehicle component revokes the second certificate.

[0024] In this way, the first in-vehicle component stores the second certificate only if the second certificate has not been tampered with (i.e., verification is successful), thereby improving the trustworthiness of the certificate.

[0025] In one possible design, the first in-vehicle component may further receive second response information from the first server. The second response information includes the first certificate and a third certificate. The second response information is signed using the third certificate. The first in-vehicle component verifies the signature of the second response information using the third certificate. If the verification is successful, the first in-vehicle component stores the first certificate, and if the verification is unsuccessful, the first in-vehicle component revokes the first certificate.

[0026] In this manner, a first in-vehicle component may obtain a first certificate and then use the first certificate to apply for a second certificate.

[0027] According to a sixth aspect, there is provided a key transmission method. The method may be applied to a first server or a chip in the first server. For example, the method is applied to the first server. The method includes: the first server receives first request information from a first in-vehicle component; the first request information is used to apply for a second certificate; the first request information includes a first public key and a first certificate; the first request information is signed using the first certificate; the first certificate is used to at least prove that the first in-vehicle component is entitled to obtain data related to geographic location information; the first server verifies the signature of the first request information using the first certificate; and if the verification is successful, the first server sends first response information to the first in-vehicle component. The first response information includes a second certificate; the second certificate includes the first public key; and the second certificate is used by the first in-vehicle component to at least obtain the first key. The first key is utilized to encrypt data that includes at least the geographic location information.

[0028] In one possible design, the first server may receive first request information from the first in-vehicle component through the second server. In response, the first server may send first response information to the first in-vehicle component through the second server. The first server corresponds to a certificate provider. The second server corresponds to a map provider.

[0029] In a possible design, the first response information further includes a third certificate, and the first server may further sign the first response information using the third certificate.

[0030] In a possible design, the first server may further receive second request information from the second server. The second request information is used to apply for the first certificate. The second request information includes a second public key and a fourth certificate. The second request information is signed using the fourth certificate. The fourth certificate is used to at least verify that the second server is qualified to provide data related to the geographic location information. The first server verifies the signature of the second request information using the fourth certificate. If the verification is successful, the first server sends second response information to the second server. The second response information includes the first certificate and a third certificate. The first certificate includes the second public key. The second response information is signed using the third certificate. Alternatively, if the verification fails, the first server discards the second request information.

[0031] In this way, the second server (e.g., a map provider) can apply for a first certificate for the first in-vehicle component. This can avoid the public-private key pair generated by the first in-vehicle component being untrustworthy when the first in-vehicle component applies for the first certificate directly. In addition, when providing services to multiple in-vehicle components (or multiple vehicles) simultaneously, the first server (e.g., a certificate provider) can also apply for certificates for multiple in-vehicle components (or multiple vehicles) simultaneously to improve certificate application efficiency.

[0032] In a possible design, the first server may alternatively receive the second request information directly from the first in-vehicle component and send the second response information directly to the first in-vehicle component. The second response information includes the first certificate and the third certificate. The first certificate includes the second public key. The second response information is signed using the third certificate.

[0033] For the advantageous effects of the implementation of the sixth aspect, please refer to the advantageous effects of the corresponding implementation of the fifth aspect, and the details will not be described again here.

[0034] According to a seventh aspect, there is provided a key transmission method. The method may be applied to a second server or a chip in the second server. For example, the method is applied to the second server. The method includes: the second server receives first request information from a first in-vehicle component; the first request information includes a first public key and a first certificate; the first request information is signed using the first certificate; the first certificate is used to at least prove that the first in-vehicle component is entitled to obtain data related to geographic location information; the second server verifies the signature of the first request information using the first certificate; and if the verification is successful, the second server forwards the first request information to the first server. The second server receives first response information from the first server; the first response information includes a second certificate; the second certificate includes the first public key; and the second certificate is used by the first in-vehicle component to at least obtain the first key. The first key is utilized to encrypt data including at least the geographic location information. The second server transmits first response information to the first in-vehicle component. The first server corresponds to a certificate provider. The second server corresponds to a map provider.

[0035] In one possible design, the first response information may further include a third certificate. The first response information is signed using the third certificate. The method further includes: the second server verifying the signature of the first response information using the third certificate. If the verification is successful, the second server sends the first response information to the first in-vehicle component; or, if the verification is unsuccessful, the second server discards the first response information.

[0036] In a possible design, the second server may further generate a second public-private key pair. The second public-private key pair includes a second public key and a second private key. The second server sends second request information to the first server. The second request information is used to apply for the first certificate. The second request information includes the second public key and a fourth certificate. The second request information is signed using the fourth certificate. The fourth certificate is used to at least verify that the second server is qualified to provide data related to the geographic location information. The second server receives second response information from the first server. The second response information includes the first certificate and a third certificate. The first certificate includes the second public key. The second response information is signed using the third certificate. The second server verifies the signature of the second response information using the third certificate. If the verification is successful, the second server sends second response information to the first in-vehicle component, or if the verification is unsuccessful, the second server discards the second response information. The first server corresponds to a certificate provider. The second server corresponds to a map provider.

[0037] In this way, the map provider can apply for a first certificate for the first in-vehicle component. This can avoid the possibility that the public-private key pair generated by the first in-vehicle component may be untrusted when the first in-vehicle component applies for the first certificate directly. In addition, when providing services to multiple in-vehicle components (or multiple vehicles) simultaneously, the first server may also apply for certificates for multiple in-vehicle components (or multiple vehicles) simultaneously to improve certificate application efficiency.

[0038] For the advantageous effects of the implementation of the seventh aspect, please refer to the advantageous effects of the corresponding implementation of the fifth aspect, and the details will not be described again here.

[0039] According to an eighth aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform the method according to the first aspect or any one of the possible designs of the first aspect.

[0040] For example, the device may include a transceiver module configured to send a random number to a second in-vehicle component when a first condition is met, the first condition including restarting or waking up the first in-vehicle component on which the device is located, and a processing module configured to encrypt the random number using a first key stored in the first in-vehicle component to obtain a first ciphertext. The transceiver unit is further configured to receive a second ciphertext from the second in-vehicle component, the second ciphertext being associated with the second key and the random number stored in the second in-vehicle component, and if the first ciphertext differs from the second ciphertext, send a third ciphertext to the second in-vehicle component, the third ciphertext including information obtained by encrypting the first key using the third key, the first key being used to encrypt data including at least geographic location information.

[0041] In a possible implementation, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0042] According to a ninth aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform the method according to the second aspect or any one of the possible designs of the second aspect.

[0043] For example, the device may include a transceiver module configured to receive a random number from a first in-vehicle component, send a second ciphertext to the first in-vehicle component, the second ciphertext being associated with the random number and a second key stored in the second in-vehicle component on which the device is located, and receive a third ciphertext from the first in-vehicle component, the third ciphertext including information obtained by encrypting a first key using the third key, the first key being used to encrypt data including at least geographic location information.

[0044] In a possible design, the apparatus further includes a processing module configured to encrypt the random number using a second key to generate a second ciphertext.

[0045] In a possible implementation, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0046] According to a tenth aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform the method according to the third aspect or any one of the possible designs of the third aspect.

[0047] For example, the device may include a processing module configured to generate a third ciphertext when a second condition is met and a transceiver module configured to transmit the third ciphertext to a second in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using a third key. The first key is utilized to encrypt data including at least geographic location information. The second condition includes one or more of restarting the first in-vehicle component on which the device is located, waking up the first in-vehicle component, updating a key by the first in-vehicle component, or receiving key request information from a second in-vehicle component by the first in-vehicle component. The key request information is utilized to request the first in-vehicle component to deliver a key (e.g., the key request information is utilized to request the first in-vehicle component to obtain the first key).

[0048] In a possible design, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0049] According to an eleventh aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform the method according to the fourth aspect or any one of the possible designs of the fourth aspect.

[0050] For example, the device may include a transceiver module configured to send key request information to a first in-vehicle component when a third condition is met. The key request information is used to request the first in-vehicle component to deliver a key (e.g., the key request information is used to request the first in-vehicle component to obtain a first key). The first key is used to encrypt data including at least geographic location information. The third condition includes one or more of restarting a second in-vehicle component on which the device is located, waking up the second in-vehicle component, or not storing a key on the second in-vehicle component. The transceiver module is further configured to receive a third ciphertext from the first in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key.

[0051] In a possible design, the first in-vehicle component is an in-vehicle computing platform or in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component.

[0052] According to a twelfth aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform a method according to the fifth aspect or any one of the possible designs of the fifth aspect.

[0053] For example, the apparatus may include a processing module configured to generate a first public-private key pair, the first public-private key pair including a first public key and a first private key; and a transceiver module configured to send first request information to a first server, the first request information being used to apply for a second certificate, the first request information including the first public key and the first certificate, the first request information being signed using the first certificate, and the first certificate being used at least to prove that a first in-vehicle component on which the apparatus is located is entitled to obtain data related to the geographic location information; and receive first response information from the first server, the first response information including the second certificate, the second certificate including the first public key, and the second certificate being used at least by the first in-vehicle component to obtain a first key, the first key being used at least to encrypt the data including the geographic location information.

[0054] In one possible design, the transceiver module is configured to send first request information to a first server through a second server and receive first response information from the first server through the second server, the first server corresponding to a certificate provider, and the second server corresponding to a map provider.

[0055] In one possible design, the first response information further includes a third certificate. The first response information is signed using the third certificate. The processing module is further configured to verify the signature of the first response information using the third certificate and store the second certificate if the verification is successful or discard the second certificate if the verification is unsuccessful.

[0056] In one possible design, the transceiver module is further configured to receive second response information from the first server, the second response information including the first certificate and a third certificate, the second response information being signed using the third certificate, and the processing module is further configured to verify the signature of the second response information using the third certificate and store the first certificate if the verification is successful or discard the first certificate if the verification is unsuccessful.

[0057] According to a thirteenth aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform a method according to the sixth aspect or any one of the possible designs of the sixth aspect.

[0058] For example, the apparatus may include a transceiver module configured to receive first request information from a first in-vehicle component, the first request information being used to apply for a second certificate, the first request information including a first public key and a first certificate, the first request information being signed using the first certificate, and the first certificate being used at least to prove that the first in-vehicle component is entitled to obtain data related to the geographic location information, and a processing module configured to verify the signature of the first request information using the first certificate. If the verification is successful, the transceiver module is further configured to send first response information to the first in-vehicle component, the first response information including the second certificate, the second certificate including the first public key, and the second certificate being used by the first in-vehicle component to at least obtain a first key, and the first key being used to encrypt the data including the geographic location information.

[0059] In one possible design, the transceiver module is configured to receive first request information from the first in-vehicle component through the second server and transmit first response information to the first in-vehicle component through the second server, the first server on which the device is located corresponds to a certificate provider, and the second server corresponds to a map provider.

[0060] In a possible design, the first response information further includes a third certificate. The processing module is further configured to sign the first response information using the third certificate.

[0061] In one possible design, the transceiver module is further configured to receive second request information from the second server. The second request information is used to apply for a first certificate. The second request information includes a second public key and a fourth certificate. The second request information is signed using the fourth certificate. The fourth certificate is used to at least verify that the second server is qualified to provide data related to geographic location information. The processing module is further configured to verify the signature of the second request information using the fourth certificate. The transceiver module is further configured to: send second response information to the second server if the verification is successful, the second response information including the first certificate and a third certificate, the first certificate including the second public key, and the second response information signed using the third certificate; or discard the second request information if the verification is unsuccessful.

[0062] According to a fourteenth aspect, there is provided a key transmission device, the device comprising a module / unit / technical means configured to perform the method according to the seventh aspect or any one of the possible designs of the seventh aspect.

[0063] For example, the apparatus may include a transceiver module configured to receive first request information from a first in-vehicle component, the first request information including a first public key and a first certificate, the first request information being signed using the first certificate, and the first certificate being utilized at least to prove that the first in-vehicle component is entitled to obtain data related to the geographic location information, and a processing module configured to verify the signature of the first request information using the first certificate. If the verification is successful, the transceiver module is further configured to forward the first request information to a first server and receive first response information from the first server, the first response information including a second certificate, the second certificate including the first public key, the second certificate being utilized by the first in-vehicle component at least to obtain a first key, and the first key being utilized at least to encrypt the data including the geographic location information, and to transmit the first response information to the first in-vehicle component. The first server corresponds to a certificate provider. The second server on which the device is located corresponds to a map provider.

[0064] In one possible design, the first response information further includes a third certificate. The first response information is signed using the third certificate. The processing module is further configured to verify the signature of the first response information using the third certificate. The transceiver module is further configured to transmit the first response information to the first in-vehicle component if the verification is successful. The processing module is further configured to discard the first response information if the verification is unsuccessful.

[0065] In one possible design, the processing module is further configured to generate a second public-private key pair, the second public-private key pair including a second public key and a second private key. The transceiver module is further configured to send second request information to the first server, the second request information being used to apply for a first certificate, the second request information including the second public key and a fourth certificate, the second request information being signed using the fourth certificate, and the fourth certificate being used to at least verify that the second server on which the device is located is qualified to provide data related to the geographic location information; and receive second response information from the first server, the second response information including the first certificate and a third certificate, the first certificate including the second public key, and the second response information being signed using the third certificate. The processing module is further configured to verify the signature of the second response information using the third certificate. The transceiver module is further configured to transmit second response information to the first in-vehicle component if the verification is successful, and the processing module is further configured to discard the second response information if the verification is unsuccessful.

[0066] According to a fifteenth aspect, there is provided a computer-readable storage medium configured to store instructions that, when executed, perform a method according to the first aspect or any one of the possible designs of the first aspect, the second aspect or any one of the possible designs of the second aspect, the third aspect or any one of the possible designs of the third aspect, the fourth aspect or any one of the possible designs of the fourth aspect, the fifth aspect or any one of the possible designs of the fifth aspect, the sixth aspect or any one of the possible designs of the sixth aspect, or the seventh aspect or any one of the possible designs of the seventh aspect.

[0067] According to a sixteenth aspect, there is provided a key transmission device including at least one processor and an interface circuit, the interface circuit configured to receive code instructions and transmit the code instructions to the at least one processor, the at least one processor executing the code instructions for performing a method according to the first aspect or any one of its possible designs, the second aspect or any one of its possible designs, the third aspect or any one of its possible designs, the fourth aspect or any one of its possible designs, the fifth aspect or any one of its possible designs, the sixth aspect or any one of its possible designs, or the seventh aspect or any one of its possible designs.

[0068] According to a seventeenth aspect, there is provided a key transmission apparatus including at least one processor and at least one memory, wherein the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions stored in the memory to enable the apparatus to perform a method according to the first aspect or any one of its possible designs, the second aspect or any one of its possible designs, the third aspect or any one of its possible designs, the fourth aspect or any one of its possible designs, the fifth aspect or any one of its possible designs, the sixth aspect or any one of its possible designs, or the seventh aspect or any one of its possible designs.

[0069] According to an eighteenth aspect, there is provided a chip coupled to a memory and configured to read and execute program instructions stored in the memory to perform a method according to the first aspect or any one of the possible designs of the first aspect, the second aspect or any one of the possible designs of the second aspect, the third aspect or any one of the possible designs of the third aspect, the fourth aspect or any one of the possible designs of the fourth aspect, the fifth aspect or any one of the possible designs of the fifth aspect, the sixth aspect or any one of the possible designs of the sixth aspect, or the seventh aspect or any one of the possible designs of the seventh aspect.

[0070] According to a 19th aspect there is provided an in-vehicle terminal comprising an apparatus according to the 8th aspect or any one of the possible designs of the 8th aspect, the 9th aspect or any one of the possible designs of the 9th aspect, the 10th aspect or any one of the possible designs of the 10th aspect, the 11th aspect or any one of the possible designs of the 11th aspect or any one of the possible designs of the 12th aspect.

[0071] According to a twentieth aspect, there is provided a vehicle comprising an apparatus according to the eighth aspect or any one of the possible designs of the eighth aspect, the ninth aspect or any one of the possible designs of the ninth aspect, the tenth aspect or any one of the possible designs of the tenth aspect, the eleventh aspect or any one of the possible designs of the eleventh aspect, or the twelfth aspect or any one of the possible designs of the twelfth aspect.

[0072] According to a twenty-first aspect, there is provided a server, the server comprising an apparatus according to the thirteenth aspect or any one of the possible designs of the thirteenth aspect.

[0073] According to a twenty-second aspect, there is provided a server, the server comprising an apparatus according to the fourteenth aspect or any one of the possible designs of the fourteenth aspect. [Brief explanation of the drawings]

[0074] [Figure 1] FIG. 1 is a schematic diagram of a scenario in which embodiments of the present application are applicable. [Figure 2] 1 is a schematic diagram of a possible configuration of a vehicle according to an embodiment of the present application; [Figure 3] 1 is a flowchart of a key transmission method according to an embodiment of the present application; [Figure 4] 1 is a schematic flowchart of obtaining a first key by a first in-vehicle component according to an embodiment of the present application. [Figure 5] 1 is a schematic flowchart of installing a first certificate on a first in-vehicle component by a production line tool according to an embodiment of the present application. [Figure 6A] 1 is a schematic flowchart of applying for a first certificate online by a first in-vehicle component according to an embodiment of the present application. [Figure 6B] 1 is a schematic flowchart of applying for a first certificate online by a first in-vehicle component according to an embodiment of the present application. [Figure 7A] 1 is a schematic flowchart of applying online for a first certificate for a first in-vehicle component with a map provider according to an embodiment of the present application; [Figure 7B] 1 is a schematic flowchart of applying online for a first certificate for a first in-vehicle component with a map provider according to an embodiment of the present application; [Figure 8] 4 is a flowchart of another key transmission method according to an embodiment of the present application. [Figure 9] 4 is a flowchart of another key transmission method according to an embodiment of the present application; [Figure 10] 1 is a schematic diagram of a possible structure of a key distribution device 100 according to an embodiment of the present application. [Figure 11] 1 is a schematic diagram of a possible structure of another key distribution device 110 according to an embodiment of the present application. [Figure 12] FIG. 10 is a schematic diagram of a possible structure of another key distribution device 120 according to an embodiment of the present application. DETAILED DESCRIPTION OF THE INVENTION

[0075] Hereinafter, embodiments of the present application will be described in detail with reference to the accompanying drawings.

[0076] An embodiment of this application provides a key transmission solution. This solution mainly implements the following two aspects: secure key distribution from a server to in-vehicle components of a vehicle (including key transmission from the server to the in-vehicle components) and key integrity between different in-vehicle components of a vehicle (including key transmission between different in-vehicle components of a vehicle). It should be understood that the above two aspects can be implemented separately or in combination with each other. This is not limited in this application. In this solution, the key that needs to be transmitted is used to encrypt at least data including or related to geographic location information and transmitted between different in-vehicle components. For example, data including geographic location information includes, but is not limited to, latitude and longitude, altitude (the height of a point above a reference surface), and geographic trajectory. For example, data related to geographic location information includes, but is not limited to, images and point clouds.

[0077] 1 is a schematic diagram of a scenario to which the embodiments of this application are applicable. A vehicle and a server are included in the scenario. There may be multiple servers. In FIG. 1, an example in which a first server and a second server are included is used, but the present invention is not limited thereto.

[0078] In the following, some nouns or terms in the embodiments of this application will be explained with reference to FIG.

[0079] (1) Vehicle: alternatively referred to as an automobile or a car. A vehicle in this specification may be an intelligent vehicle or a non-intelligent vehicle. This is not limited to the embodiments of this application.

[0080] It should be noted that the embodiments in which a vehicle is used as an example in the embodiments of this application may further be applied to other types of terminal devices, provided that the terminal device can execute the relevant service processes performed by the vehicle in the embodiments of this application through the internal functional units or devices of the terminal device.

[0081] The vehicle in the embodiment of this application includes a plurality of in-vehicle components.

[0082] (2) In-Vehicle Component: An electronic device that needs to use a key to encrypt and / or decrypt data containing or related to geographic location information in a component (e.g., a chip or integrated circuit) in a vehicle or electronic device, or that needs to transmit or receive a key in a component (e.g., a chip or integrated circuit) in a vehicle or electronic device.

[0083] For example, Figure 2 is a schematic diagram of a possible configuration of a vehicle. The vehicle includes multiple in-vehicle components. The in-vehicle components may communicate with each other wired or wirelessly. For example, different in-vehicle components may be connected and communicate with each other through a Controller Area Network (CAN) bus.

[0084] The in-vehicle components are described as follows:

[0085] A. In-Vehicle Computing Platform: Configured to provide various computing and control functions, for example, computing and control functions related to autonomous driving. The specific type of in-vehicle computing platform is not limited in this application. In an example, the in-vehicle computing platform may be a Mobile Data Center (MDC). The MDC is a local computing platform for the autonomous vehicle. The MDC may run autonomous driving software and may further perform some simple operations such as motor control.

[0086] B. Communications Component: Configured to communicate with off-vehicle devices. The specific type of communications component is not limited in this application. In an example, the communications component may be a telematics box (T-Box), or sometimes referred to as a black box, configured primarily to provide information exchange between the vehicle and the Internet, and may be configured to provide functions such as positioning, communications, and diagnostics.

[0087] C. Cockpit Domain Component: Configured to provide functions related to the intelligent cockpit. In an example, the cockpit domain component may be an intelligent cockpit domain controller (CDC). The CDC is an electronic control unit (ECU) configured to control elements in the intelligent cockpit. Elements in the intelligent cockpit include, but are not limited to, an instrument panel, a central control panel (CCP for short), a head-up display, a microphone, a camera, a speaker (i.e., a loudspeaker), a Bluetooth module, etc. The intelligent cockpit may control the driving situation and driving trajectory of the autonomous vehicle through human-machine interaction based on passenger requests, such that both human-machine interaction and remote management in the intelligent cockpit can send the same commands to control the vehicle's driving.

[0088] D. Autonomous Driving Domain Components: Configured to provide functionality related to autonomous driving, including, for example, but not limited to, Autonomous Driving Integrated Positioning (ADIP) and In-vehicle Infotainment (IVI).

[0089] E. Chassis Power Domain Components: Configured to provide functionality related to chassis power. For example, chassis power domain components include, but are not limited to, a Transmission Control Unit (TCU), a Motor Control Unit (MCU), a Vehicle Control Unit (VCU), and a Body Control Module (BCM).

[0090] It should be understood that the above several types of in-vehicle components are merely examples, not specific limitations. In some technical scenarios, the names of devices with similar key transmission functions in the vehicle may not be called components. However, for ease of explanation, electronic devices with key transmission functions in the vehicle will be called components in the embodiments of this application.

[0091] (3) Keys: Includes symmetric and asymmetric keys.

[0092] Symmetric Key: The sender and receiver use the same key to encrypt and decrypt plaintext. The same key is a symmetric key. For example, in this specification, the key (e.g., the first key) used to encrypt data containing geographic location information between different in-vehicle components is a symmetric key.

[0093] Asymmetric Keys: A sender and a receiver use a pair of keys to encrypt and decrypt data. One key is a public key that is publicly released, and the other key is a private key that is kept secret by the user. When sending data, the sender may use the receiver's public key to encrypt the data. After receiving the ciphertext, the receiver uses its own private key to decrypt the data. When sending data, the sender may use the sender's private key to sign the data, and the receiver uses the sender's public key to verify the signature. The private key and the public key are asymmetric keys. In general, a public key and a private key pair may be referred to as a public-private key pair (or asymmetric key pair). For example, in this specification, both a first public-private key pair used to apply for a second certificate and a second public-private key pair used to apply for the first certificate are asymmetric key pairs. Correspondingly, the first public key and the first private key included in the first public-private key pair are asymmetric keys, and the second public key and the second private key included in the second public-private key pair are asymmetric keys.

[0094] (5) Signature: Alternatively called a digital signature or public key digital signature, it is a digital string that can only be generated by the sender and cannot be forged by others. The digital string is also a valid proof of the authenticity of the information sent by the sender. A digital signature is similar to a physical signature written on paper, but is implemented based on techniques from the field of public key cryptography and is used to authenticate digital information.

[0095] Signature-related operations include signing and signature verification. For example, during signing, a sender uses a hash function to generate digest information of an original text to be transmitted, encrypts the digest information using the sender's private key, and transmits the encrypted digest information to a receiver along with the original text. During signature verification, a receiver uses the sender's public key to decrypt the encrypted digest information and uses a hash function to generate digest information about the received original text. If the generated digest information is the same as the decrypted digest information, the received information is intact and has not been modified during transmission. If the generated digest information is different from the decrypted digest information, the information has been modified. Therefore, a digital signature can verify information integrity. It can be understood from the above description that signing is an encryption process and signature verification is a decryption process.

[0096] (6) Certificate: Alternatively called a digital certificate or digital identifier, it is a digital certificate that marks the identity of a communicating party. A user may use a certificate to identify another user on a communication network. Each certificate corresponds to a public-private key pair. A certificate contains a public key and may also contain user information, etc. A digital certificate may be used to prove that the user named in the certificate legitimately owns the public key in the certificate.

[0097] For example, in this specification, a first certificate corresponds to a second public-private key pair. The first certificate includes a second public key. The second certificate may certify that a user (e.g., a first in-vehicle component) identified in the second certificate legitimately owns the second public key. The second certificate corresponds to a first public-private key pair. The second certificate includes a first public key. The second certificate may certify that a user (e.g., a first in-vehicle component) identified in the second certificate legitimately owns the first public key.

[0098] It should be understood that in this specification, signing plaintext using a certificate means signing the plaintext using the private key corresponding to the certificate, and verifying a signature on the plaintext using a certificate means verifying the signature on the plaintext using the public key corresponding to the certificate.

[0099] (5) Issuance: Generally refers to certificate issuance. For example, a certificate issuer (i.e., a certificate issuing authority such as the China Academy of Geospatial Information and Communications Technology) uses its private key to sign information, such as the public key, provided by the certificate requester to generate the certificate requested by the certificate requester.

[0100] For example, Table 1 shows some possible certificates and their associated descriptions.

[0101] [Table 1]

[0102] (6) First Server: A server of a certificate provider (or certificate issuing authority). The server is capable of issuing certificates to at least the in-vehicle components of the vehicle.

[0103] (7) Second Server: A server of a map provider. The server can provide at least services related to geographic location information for vehicles, such as map services or surveying and mapping services. For example, the second server can distribute a key to the vehicle that is used to encrypt data including geographic location information.

[0104] It may be understood that the first server and the second server may be deployed on different devices or the same device, which is not a limitation in this application.

[0105] (8) Digital Envelope: A technology that comprehensively utilizes the advantages of symmetric encryption technology and asymmetric encryption technology for secure information transmission.

[0106] Specifically, the sender encrypts the information content using a symmetric key to obtain an information ciphertext, and encrypts the symmetric key using the recipient's public key to obtain a key ciphertext, where the information ciphertext and the key ciphertext constitute a digital envelope, and then sends the key ciphertext and the information ciphertext (i.e., the digital envelope) to the recipient. The recipient opens the digital envelope using its private key to obtain the symmetric key, and then decrypts the information ciphertext using the symmetric key.

[0107] It should be understood that the above two servers are merely examples and are not limiting in nature.

[0108] It should be noted that the system architecture and service scenarios described in the embodiments of this application are intended to more clearly explain the technical solutions provided in this application, and do not constitute limitations on the technical solutions provided in this application. Those skilled in the art may know that with the development of system architectures and the emergence of new service scenarios, the technical solutions provided in this application can also be applied to similar technical problems.

[0109] Below we describe a solution where a server distributes keys to in-vehicle components.

[0110] Figure 3 shows a key transmission method according to an embodiment of this application. For example, the method is applied to the scenario shown in Figure 1. The method includes the following steps:

[0111] S301: A first in-vehicle component generates a first public-private key pair, the first public-private key pair including a first public key and a first private key.

[0112] The first in-vehicle component may be an in-vehicle computing platform. The in-vehicle computing platform may communicate with another in-vehicle component. For example, the first in-vehicle component may be an MDC. Alternatively, the first in-vehicle component may be an in-vehicle component configured to communicate with an out-vehicle device, such as a T-Box. Of course, the first in-vehicle component may alternatively be another in-vehicle component that may communicate with the first server. This is not a limitation of this application.

[0113] S302: The first in-vehicle component sends first request information to the first server. In response, the first server receives the first request information from the first in-vehicle component. The first request information is used to apply for a second certificate from the first server. The first request information includes a first public key and a first certificate. The first request information is signed using the first certificate.

[0114] Optionally, the first request information may further include an identifier of the first in-vehicle component.

[0115] The first certificate is used to prove the validity of the first in-vehicle component, for example, to prove that the first in-vehicle component is at least entitled to obtain data related to geographic location information or to prove that the first in-vehicle component is at least entitled to transmit a map service (or transmit data related to a map service). The first in-vehicle component may sign the first request information using the first certificate. For example, the first in-vehicle component may calculate the first request information using a hash function to generate first digest information, encrypt the first digest information using a second private key corresponding to the first certificate to generate ciphertext A, and send ciphertext A to the first server as a signature of the first request information and the first request information.

[0116] For example, the first certificate may be the Survey and Mapping Plug-in certificate shown in Table 1.

[0117] Optionally, the first certificate may be issued to the first in-vehicle component after the first server verifies the validity of the first in-vehicle component, and is utilized to prove the validity of the first in-vehicle component.

[0118] The second certificate may be used by the first in-vehicle component to access a service provided by the second server or to prove that the first in-vehicle component is entitled to access a service provided by the second server. For example, the second certificate may be used by the first in-vehicle component to at least obtain a first key from the second server, or the second certificate may be used to prove that the first in-vehicle component is entitled to obtain the first key from the second server. The first key may be used to encrypt data including at least the geographic location information.

[0119] For example, the second certificate may be a Survey and Mapping Registration Certificate as shown in Table 1.

[0120] Optionally, the first in-vehicle component may apply for a second certificate from the first server when registering and enabling a service related to the geographic location information with the second server, or the second certificate may be issued to the first in-vehicle component after the first server registers and enables a service related to the geographic location information for the first in-vehicle component. The second certificate may be used as proof that the first in-vehicle component has registered and enabled a service related to the geographic location information. That is, the first in-vehicle component may use the second certificate to access a service related to the geographic location information provided by the second server. For example, the service may include obtaining a first key from the second server.

[0121] In this case, the first request information may be forwarded to the first server through the second server.

[0122] Example 1: A first in-vehicle component sends first request information to a second server. After receiving the first request information, the second server directly forwards the first request information to the first server without verifying or processing the first request information.

[0123] Example 2: The first in-vehicle component sends first request information to the second server. The second server verifies the signature of the first request information using the first certificate (e.g., the second server calculates the first request information using a hash function to generate second digest information, decrypts the signature using a second public key corresponding to the first certificate to obtain the first digest information, and compares the first digest information with the second digest information; if the first digest information is the same as the second digest information, the verification is successful; if the first digest information is different from the second digest information, the verification is unsuccessful). If the verification is successful, the second server forwards the first request information to the first server.

[0124] Optionally, the second server may further sign the first request information using its own certificate.

[0125] Example 3: The first in-vehicle component sends first request information to the second server. After receiving the first request information, the second server converts the first request information to obtain the converted first request information, and then forwards the converted first request information to the first server. For example, data is transmitted between the first server and the second server based on a data transmission format corresponding to a first communication protocol. Data is transmitted between the first server and the second server based on a data transmission format corresponding to a second communication protocol. The first communication protocol is different from the second communication protocol. After receiving the first request information in the data transmission format corresponding to the first communication protocol, the second server converts the first request information to obtain the first request information in the data transmission format corresponding to the second communication protocol, and then sends the first request information in the data transmission format corresponding to the second communication protocol to the first server. Example 4: The first in-vehicle component sends first request information to the second server. After receiving the first request information, the second server verifies the signature of the first request information using the first certificate, and if the verification is successful, the second server converts the first request information to obtain the converted first request information, and then forwards the converted first request information to the first server.

[0126] It should be understood that the above are examples only, not limitations, and of course other specific transfer methods may exist.

[0127] S303: The first server verifies the signature of the first request information using the first certificate. If the verification is successful, S304A is executed, and if the verification is unsuccessful, S304B is executed.

[0128] For example, the first server calculates the first request information using a hash function to generate third digest information, decrypts the signature using a second public key corresponding to the first certificate to obtain the first digest information, and compares the first digest information with the third digest information. If the first digest information is the same as the third digest information, the verification is successful; or if the first digest information is different from the third digest information, the verification is unsuccessful.

[0129] S304A: The first server transmits first response information to the first in-vehicle component. In response, the first in-vehicle component receives first response information from the first server. The first response information includes the second certificate.

[0130] In response, the first server may return first response information to the first in-vehicle component through the second server (i.e., the first server sends the first response information to the second server, and the second server forwards the first response information to the first in-vehicle component).

[0131] Example 1: A first server sends first response information to a second server. After receiving the first response information, the second server directly forwards the first response information to a first in-vehicle component without verifying or processing the first response information.

[0132] Example 2: When returning the first response information, the first server may sign the first response information. For example, the first response information further includes a third certificate. The third certificate is a certificate owned by the first server. The first server signs the first response information using the third certificate. Correspondingly, after receiving the first response information, the second server verifies the signature of the first response information using the third certificate, and if the verification is successful, sends the first response information to the first in-vehicle component, or discards the first response information if the verification is unsuccessful. Correspondingly, after receiving the first response information, the first in-vehicle component uses the third certificate to verify the signature added to the first response information by the first server, and if the verification is successful, stores the second certificate (i.e., considers the second certificate to be valid), or discards the first response information (i.e., discards the second certificate and considers the second certificate to be invalid) if the verification fails.

[0133] For example, the third certificate may be the Surveying and Mapping Services Certificate shown in Table 1.

[0134] Optionally, the second server may further sign the first response information using its own certificate. Correspondingly, after receiving the first response information, the first in-vehicle component may further verify the signature added to the first response information by the second server using the certificate of the second server. If the verification of both the signature added by the first server and the signature added by the second server is successful, the first in-vehicle component stores the second certificate (i.e., considers the second certificate to be valid).

[0135] Example 3: A first server transmits first response information to a second server. After receiving the first response information, the second server converts the first response information to obtain the converted first response information, and then forwards the converted first response information to a first in-vehicle component. For example, data is transmitted between the first server and the second server based on a data transmission format corresponding to a first communication protocol. Data is transmitted between the first server and the second server based on a data transmission format corresponding to a second communication protocol. The first communication protocol is different from the second communication protocol. After receiving the first response information in the data transmission format corresponding to the second communication protocol, the second server converts the first response information to obtain the first response information in the data transmission format corresponding to the first communication protocol, and then transmits the first response information in the data transmission format corresponding to the first communication protocol to the first in-vehicle component.

[0136] Example 4: A first in-vehicle component sends first request information to a second server. After receiving the first request information, the second server verifies the signature of the first request information using the first certificate. If the verification is successful, the second server converts the first request information to obtain converted first request information, and then forwards the converted first request information to the first server.

[0137] It should be understood that the above are examples only, not limitations, and of course other specific transfer methods may exist.

[0138] S304B: The first server discards the first request information.

[0139] If the verification at S303 fails, the first server does not issue the second certificate, directly discards the first request information, and does not respond to the first request information. Optionally, if the verification at S303 fails, the first server may further return information indicating that the application for the second certificate has failed to the first in-vehicle component, or the first server may return information indicating that the application for the second certificate has failed to the first in-vehicle component through the second server.

[0140] It should be understood that in addition to performing the method shown in FIG. 3 when registering and activating a service related to geographic location information with the second server, the first in-vehicle component may further perform the method shown in FIG. 3 after the first in-vehicle component loses the original second certificate or after the original second certificate is compromised or tampered with, to obtain an updated second certificate using the first certificate.

[0141] After obtaining the second certificate, the first in-vehicle component may obtain the first key from the second server using the second certificate. For example, Figure 4 is a schematic flowchart of obtaining the first key by the first in-vehicle component. The method includes the following steps.

[0142] S401: A first in-vehicle component generates a fourth public-private key pair (a fourth private key and a fourth public key).

[0143] In an optional design, when the first in-vehicle component does not have a key used to encrypt data including geographic location information, or when the first in-vehicle component's original key used to encrypt data including geographic location information expires, the first in-vehicle component generates a fourth public-private key pair.

[0144] S402: The first in-vehicle component sends third request information to the second server. The third request information carries a fourth public key and a second certificate. The third request information is signed using the second certificate. In response, the second server receives the third request information.

[0145] S403: The second server verifies whether the second certificate is valid, and verifies the signature of the third request information using the second certificate.

[0146] For example, the second certificate may include a validity period indication, and the second server may verify whether the first certificate is within the validity period based on the indication. If not, the second certificate may be deemed to have expired and be invalid.

[0147] For example, the first certificate carries the signature of the certificate provider. The second server verifies the signature using the certificate provider's public key. If the verification fails, the second certificate may be considered invalid as it was not issued by the certificate provider.

[0148] For example, the first certificate carries information about the certificate issuer (e.g., information about the certificate provider), and the second server verifies whether the information about the certificate issuer is valid.

[0149] Of course, the above are merely examples and not limitations.

[0150] Conversely, if the second certificate meets conditions such as being within the validity period, being issued by a certificate provider, and being issued by a valid certificate issuer, the second certificate may be determined to be valid.

[0151] S404: If the second server verifies that the second certificate is valid and the verification of the signature of the third request information is successful, the second server generates a first key (the content of the first key includes one or more of a key identifier, a validity period, and a key value) and a fourth key (the fourth key is a symmetric key).

[0152] S405: The second server encrypts the first key using a fourth key to obtain ciphertext B, and encrypts the fourth key using a fourth public key to obtain ciphertext C, where ciphertext C and ciphertext B constitute a digital envelope, and signs the digital envelope using a fifth certificate to generate a signature of the digital envelope.

[0153] The fifth certificate is owned by the second server and is used to sign the digital envelope. For example, the fifth certificate may be the online certificate for the surveying and mapping service shown in Table 1.

[0154] S406: The second server sends fourth response information to the first in-vehicle component. The fourth response information carries the digital envelope, the signature of the digital envelope, and the fifth certificate. In response, the first in-vehicle component receives the fourth response information.

[0155] S407: The first in-vehicle component verifies the signature of the digital envelope using the fifth certificate.

[0156] S408: If the verification of the signature on the digital envelope is successful, the first in-vehicle component decrypts the digital envelope using the fourth private key to obtain the fourth key.

[0157] S409: The first in-vehicle component decrypts the ciphertext B using the fourth key to obtain the first key.

[0158] S410: A first in-vehicle component stores a first key.

[0159] Optionally, the first in-vehicle component may encrypt and store the first key using a root key stored in the first in-vehicle component, where the root key is used to encrypt a key in the first in-vehicle component that is used to encrypt data including the geographic location information.

[0160] It can be understood from the above that in this embodiment of the present application, device validity verification and service registration are separated (i.e., the first certificate is used to prove the validity of the first in-vehicle component, and the second certificate is used by the first in-vehicle component to access the service provided by the second server), whereby the first in-vehicle component applies for the second certificate based on the first certificate and accesses the service provided by the second server based on the second certificate (e.g., obtains the first key from the second server). This can reduce the risk that the first certificate is leaked or tampered with when the first in-vehicle component accesses the service provided by the second server, and can reduce the frequency of using the first certificate to improve the security performance of the in-vehicle component. Furthermore, after the first in-vehicle component loses its original second certificate or the original second certificate is leaked or tampered with, the first in-vehicle component can further update the second certificate using the first certificate to further improve the security performance of the in-vehicle component.

[0161] 3, the first in-vehicle component needs to obtain a first certificate in advance. The following describes several methods for the first in-vehicle component to obtain the first certificate.

[0162] Method 1: A production line tool installs a first certificate on a first in-vehicle component. Referring to Figure 5, the method includes the following steps.

[0163] S501: A production line tool installs an information security package on a first in-vehicle component.

[0164] The production line tool may be an execution management system deployed on a production line for in-vehicle components, or may be an electronic device or software running on an electronic device. This is not a limitation of this application. For example, the production line tool may be a Manufacturing Execution System (MES). The PKI is a system deployed on a production line for in-vehicle components that manages public keys using a digital certificate mechanism and is configured to issue certificates to the in-vehicle components. The PKI may be an electronic device or software integrated into an electronic device. This is not a limitation of this application.

[0165] The information security package includes a fourth certificate. The fourth certificate is used to verify the validity of the first in-vehicle component. For example, the fourth certificate may be a secondary root certificate for surveying and mapping shown in Table 1.

[0166] S502: The first in-vehicle component generates a second public-private key pair, the second public-private key pair including a second public key and a second private key.

[0167] S503: The first in-vehicle component sends certificate request information to the PKI through a production line tool. The certificate request information carries the second public key.

[0168] Optionally, the certificate request information further carries an identifier of the first in-vehicle component.

[0169] Optionally, the certificate request information is signed using a fourth certificate.

[0170] S504: After receiving the certificate request information, the PKI issues the first certificate using the sixth certificate.

[0171] The sixth certificate may be a certificate issued to the PKI by the map provider. The sixth certificate is used by the PKI to issue certificates to in-vehicle components. For example, the sixth certificate may be a production line certificate for the surveying and mapping service shown in Table 1.

[0172] It should be understood that if the certificate request information is signed using the fourth certificate, the PKI must verify the signature of the fourth certificate before issuing the first certificate to the first in-vehicle component.

[0173] S505: The PKI sends the certificate response information to the in-vehicle component through the production line tool, and the production line tool installs the first certificate in the first in-vehicle component.

[0174] Through the above method, the first certificate can be obtained on the production line. The method is applicable to a scenario in which the in-vehicle component cannot connect to an external network. The in-vehicle component can obtain the first certificate offline and then apply for a second certificate based on the first certificate to ensure data transmission efficiency.

[0175] Method 2: A first in-vehicle component applies for a first certificate online. Referring to Figures 6A and 6B, the method includes the following steps.

[0176] S601: A production line tool triggers a first in-vehicle component to generate a second public-private key pair.

[0177] S602: The first in-vehicle component generates a second public-private key pair, the second public-private key pair including a second public key and a second private key.

[0178] S603: The first in-vehicle component sends the second public key to the production line tool.

[0179] Optionally, an identifier of the first in-vehicle component is also transmitted.

[0180] S604: The production line tool sends certificate request information to a second server, where the certificate request information carries the second public key and the fourth certificate and is signed using the fourth certificate.

[0181] S605: The second server verifies the signature of the certificate request information. If the verification fails, the certificate request information is discarded. If the verification is successful, the following steps are performed:

[0182] S606: The second server transfers the certificate request information to the first server.

[0183] S607: The first server verifies the signature of the certificate request information, and if the verification fails, discards the certificate request information. If the verification succeeds, the first server issues the first certificate using the third certificate.

[0184] The third certificate is utilized by at least the first server to issue the first certificate.

[0185] S608: The first server sends a first certificate response to the second server. The first certificate response carries the first certificate and the third certificate. The first certificate response is signed using the third certificate.

[0186] S609: The second server verifies the signature of the first certificate response information, and discards the first certificate response information if the verification fails. If the verification is successful, the following steps are performed:

[0187] S610: The second server sends second certificate response information to the production line tool. The second certificate response information carries the first certificate. The second certificate response information is signed using the fourth certificate.

[0188] S611: The production line tool verifies the signature of the second certificate response information, and discards the second certificate response information if the verification fails. If the verification is successful, the following steps are performed:

[0189] S612: The production line tool installs the first certificate into the first in-vehicle component, and the first in-vehicle component stores the first certificate.

[0190] It should be understood that in the method illustrated in Figures 6A and 6B, the production line tool may be optional. If the production line tool is not present, the first in-vehicle component may interact directly with the second server.

[0191] Through the above method, the first in-vehicle component can obtain the first certificate online. The method is applicable to a scenario in which the in-vehicle component can connect to an external network.

[0192] Method 3: A map provider applies for a first certificate online for a first in-vehicle component. As shown in Figures 7A and 7B, the method includes the following steps.

[0193] S701: A second server generates a second public-private key pair, the second public-private key pair including a second public key and a second private key.

[0194] S702: The second server sends second request information to the first server. The second request information is used to apply for a first certificate. The second request information includes a second public key and a fourth certificate. The second request information is signed using the fourth certificate. The fourth certificate is used to prove the validity of the second server, for example, to prove at least that the second server is qualified to provide data related to geographic location information. In response, the first server receives second request information from the second server.

[0195] For example, the fourth certificate may be the secondary root certificate for surveying and mapping shown in Table 1.

[0196] S703: The first server verifies the signature of the second request information using the fourth certificate. If the verification is successful, execute S704A; if the verification is unsuccessful, execute S704B.

[0197] S704A: The first server sends second response information to the second server. The second response information includes the first certificate and a third certificate. The first certificate includes a second public key. The second response information is signed using the third certificate. The third certificate is used by the first server to issue at least the first certificate. In response, the second server receives second response information from the first server.

[0198] S705: The second server verifies the signature of the second response information using the third certificate. If the verification is successful, execute S706A; if the verification is unsuccessful, execute S706B.

[0199] S706A: The second server sends third response information to the first in-vehicle component. In response, the first in-vehicle component receives the third response information. The third response information includes the first certificate and a fourth certificate. The first certificate includes the second public key. The third response information is signed using the fourth certificate.

[0200] S707: The first in-vehicle component verifies the signature of the third response information using the fourth certificate. If the verification is successful, execute S708A; if the verification is unsuccessful, execute S708B.

[0201] S708A: A first in-vehicle component stores a first certificate.

[0202] S704B: The first server discards the second request information.

[0203] S706B: The second server discards the second response information.

[0204] S708B: The first in-vehicle component discards the third response information (ie, discards the first certificate).

[0205] It should be understood that the above process utilizes an example in which the first server distributes the first certificate to the first in-vehicle component through the second server, and the second server further verifies and signs the second response information. Of course, the second server may not verify or sign the second response information, or the second server may further convert the second response information (e.g., perform format conversion based on a different communication protocol). Alternatively, the first server may distribute the first certificate to the first in-vehicle component without going through the second server (e.g., the first server distributes the first certificate directly to the first in-vehicle component). The specific method of distributing the first certificate is not limited by this application.

[0206] Through the above method, the map provider applies for a first certificate online for a first in-vehicle component. The method is applicable to a scenario in which the first in-vehicle component can connect to an external network. The above method can avoid the public-private key pair generated by the first in-vehicle component being untrustworthy when the first in-vehicle component directly applies for the first certificate. In addition, when providing services to multiple in-vehicle components (or multiple vehicles) simultaneously, the first server may also apply for certificates for multiple in-vehicle components (or multiple vehicles) simultaneously to improve certificate application efficiency.

[0207] It should be understood that the above three methods are merely examples and not limitations.

[0208] Below we describe a solution for maintaining key integrity between different in-vehicle components of a vehicle.

[0209] 8 is a flowchart of another key transmission method according to an embodiment of the present application. For example, the method is applied to the vehicle shown in FIG. 2. The method assumes that both the first in-vehicle component and the second in-vehicle component have the capability to store at least a key (referred to as a key for ease of explanation) used to encrypt data including geographic location information. For example, after the second in-vehicle component is shut down and restarted, the key used before shut down is still stored. The method includes the following steps:

[0210] S801: When a first condition is satisfied, a first in-vehicle component transmits a random number to a second in-vehicle component, and in response, the second in-vehicle component receives the random number.

[0211] The first in-vehicle component may be an in-vehicle computing platform. The in-vehicle computing platform may communicate with another in-vehicle component. For example, the first in-vehicle component is an MDC. Alternatively, the first in-vehicle component may be an in-vehicle component configured to communicate with an out-vehicle device, for example, a T-Box. Of course, the first in-vehicle component may alternatively be another in-vehicle component. This is not limited in this application. For ease of explanation, the following mainly uses an example in which the first in-vehicle component is an MDC.

[0212] The second in-vehicle component may be another component that communicates with the first in-vehicle component, including, for example, but not limited to, one or more of a cockpit domain component (e.g., CDC), an autonomous driving domain component (e.g., ADIP and IVI), or a chassis power domain component (e.g., TCU, MCU, VCU, and BCM), which is not limited in this application.

[0213] The first condition may be any condition that may cause an inconsistency between the key stored in the first in-vehicle component and the key stored in the second in-vehicle component.

[0214] For example, the keys in different in-vehicle components will not match when the following two scenarios occur:

[0215] 1. A first in-vehicle component updates its key, but the key stored in a second in-vehicle component is the same as the key in the first in-vehicle component before the update. Therefore, the key stored in the first in-vehicle component does not match the key stored in the second in-vehicle component. In most cases, when the first in-vehicle component updates its key, the first in-vehicle component is restarted or woken up.

[0216] 2. The keys in the first in-vehicle component and the second in-vehicle component of the vehicle are initially consistent. However, when the user replaces the second in-vehicle component with a new one, the new second in-vehicle component does not have the key, so the keys in the first in-vehicle component and the new second in-vehicle component do not match. In most cases, when the second in-vehicle component of the vehicle (e.g., ADIP) is replaced, the first in-vehicle component (e.g., MDC) is restarted.

[0217] In this regard, the first condition may include, but is not limited to, restarting or waking up a first in-vehicle component.

[0218] S802: The first in-vehicle component encrypts the random number using a first key stored in the first in-vehicle component to obtain a first ciphertext.

[0219] The first key is stored in a first in-vehicle component and is utilized to encrypt data including at least the geographic location information.

[0220] S803: The second in-vehicle component transmits a second ciphertext to the first in-vehicle component, and in response, the first in-vehicle component receives the second ciphertext from the second in-vehicle component.

[0221] The second ciphertext is associated with a second key stored in the second in-vehicle component and a random number. For example, the second in-vehicle component encrypts the random number using the second key stored in the second in-vehicle component to generate the second ciphertext. The second key is stored in the second in-vehicle component and is used to encrypt at least data including the geographic location information.

[0222] S804: The first in-vehicle component sends a first key to the second in-vehicle component based on the first ciphertext and the second ciphertext. In response, the second in-vehicle component receives and stores the first key.

[0223] For example, the second intra-vehicle component may encrypt a random number using a second key stored in the second intra-vehicle component to generate a second ciphertext. After receiving the second ciphertext, the first intra-vehicle component may compare the first ciphertext with the second ciphertext. If the first ciphertext is different from the second ciphertext, the second key stored in the second intra-vehicle component is different from the first key stored in the first intra-vehicle component. Therefore, the first intra-vehicle component distributes the first key to the second intra-vehicle component, thereby causing the second intra-vehicle component to store the same key as the first intra-vehicle component, thereby achieving key integrity between the first intra-vehicle component and the second intra-vehicle component. If the first ciphertext is the same as the second ciphertext, the second key stored in the second intra-vehicle component is the same as the first key stored in the first intra-vehicle component. In this case, the first intra-vehicle component does not need to transmit the first key.

[0224] Optionally, the first in-vehicle component may encrypt the first key and then transmit the encrypted first key to the second in-vehicle component. For example, the first in-vehicle component may transmit a third ciphertext to the second in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key. In this manner, security of the key transmission may be improved.

[0225] Optionally, the second in-vehicle component further deletes the second key to avoid multiple keys conflicting with each other in the first in-vehicle component.

[0226] Through the above method, when the second in-vehicle component stores the key, the first in-vehicle component and the second in-vehicle component can store the key in order to avoid data transmission failure due to key mismatch between different in-vehicle components. No. 2 Key synchronization between the in-vehicle components can be performed, which can improve the reliability of communication between the in-vehicle components.

[0227] 9 is a flowchart of another key transmission method according to an embodiment of the present application. For example, the method is applied to the vehicle shown in FIG. 2. In the method, it is assumed that a first in-vehicle component has the capability to store at least a key (referred to as a key for ease of explanation) used to encrypt data including geographic location information, and a second in-vehicle component does not have the capability to store a key. For example, after the second in-vehicle component is shut down and restarted, the key used before the shutdown is lost. The method includes the following steps:

[0228] S901: When a second condition is met, the first in-vehicle component generates a third ciphertext.

[0229] The third ciphertext includes information obtained by encrypting the first key with the third key, the first key being used to encrypt data including at least the geographic location information.

[0230] For the first in-vehicle component, please refer to the relevant description above, and the details will not be described again here.

[0231] The second condition may be any condition that causes an inconsistency between the key stored in the first intra-vehicle component and the key stored in the second intra-vehicle component. It should be understood that the loss of the key in the second intra-vehicle component may be considered as the key stored in the first intra-vehicle component not matching the key stored in the second intra-vehicle component.

[0232] For example, the second condition includes one or more of restarting the first intra-vehicle component, waking up the first intra-vehicle component, or updating a key by the first intra-vehicle component. This is because when the first intra-vehicle component updates a key (e.g., the first key is an updated key), the key stored in the first intra-vehicle component does not match the key stored in the second intra-vehicle component. When the first intra-vehicle component is restarted or woken up, it is likely that the first intra-vehicle component will update the key. Therefore, restarting or waking up the first intra-vehicle component also causes an inconsistency between the key stored in the first intra-vehicle component and the key stored in the second intra-vehicle component.

[0233] The second condition may further include receiving, by the first in-vehicle component, key request information from the second in-vehicle component. The key request information is used to request the first in-vehicle component to deliver a key. For example, the key request information is used to request obtaining the first key.

[0234] Optionally, when a third condition is met, the second in-vehicle component may send key request information to the first in-vehicle component. The third condition includes one or more of restarting the second in-vehicle component, waking up the second in-vehicle component, or not storing the key in the second in-vehicle component. After the second in-vehicle component is restarted or woken up, the key in the second in-vehicle component is lost. Therefore, when the third condition is met, the second in-vehicle component may send key request information to the first in-vehicle component.

[0235] For the second in-vehicle component, please refer to the relevant description above, and the details will not be described again here.

[0236] S902: The first in-vehicle component transmits the first key to the second in-vehicle component, and in response, the second in-vehicle component receives the first key from the first in-vehicle component.

[0237] Optionally, the first in-vehicle component may encrypt the first key and then transmit the encrypted first key to the second in-vehicle component. For example, the first in-vehicle component may transmit a third ciphertext to the second in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key. In response, the second in-vehicle component receives the third ciphertext from the first in-vehicle component and obtains the first key after decrypting the third ciphertext using the third key.

[0238] Through the above method, when the second in-vehicle component does not store the key, the first in-vehicle component and the second in-vehicle component can be connected to each other to avoid data transmission failure due to key mismatch between different in-vehicle components. No. 2 Key synchronization between the in-vehicle components may be performed, which may improve the reliability of communication between the in-vehicle components.

[0239] It should be understood that the above embodiments can be combined with each other to achieve different technical effects.

[0240] The above describes the method provided in the embodiments of this application with reference to the accompanying drawings. The following describes the apparatus provided in the embodiments of this application with reference to the accompanying drawings.

[0241] To implement the functions in the above embodiments, it can be understood that the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. include corresponding hardware structures and / or software modules for performing the functions. Those skilled in the art should easily recognize that, in combination with the units, modules, and method steps in the examples described in the embodiments disclosed in this application, this application can be implemented through hardware or a combination of hardware and computer software. Whether the functions are performed through hardware or through hardware driven by computer software depends on the specific application scenario and design constraints of the technical solution.

[0242] 10 is a schematic diagram of a possible structure of a key transmission device 100 according to an embodiment of the present application, including a processing module 1001 and a transceiver module 1002. The device 100 may be configured to perform functions of the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. in the above method embodiments, and thus can also achieve the advantageous effects of the above method embodiments. In this embodiment of the present application, the device 100 may be the first server, the second server, the first in-vehicle component, or the second in-vehicle component, or may be a module (e.g., a chip) in the first server, the second server, the first in-vehicle component, or the second in-vehicle component.

[0243] When the apparatus 100 is configured to perform the functions of the first in-vehicle component in the method embodiment shown in FIG. 3, the following occurs.

[0244] The processing module 1001 is configured to generate a first public-private key pair, the first public-private key pair including a first public key and a first private key.

[0245] The transceiver module 1002 is configured to send first request information to a first server and receive first response information from the first server. The first request information is used to apply for a second certificate. The first request information includes a first public key and a first certificate. The first request information is signed using the first certificate. The first certificate is used at least to verify that the first in-vehicle component is entitled to obtain data related to the geographic location information. The first response information includes a second certificate. The second certificate includes the first public key. The second certificate is used by the first in-vehicle component to at least obtain a first key. The first key is used to encrypt data including the geographic location information.

[0246] When the apparatus 100 is configured to perform the functions of the first server in the method embodiment shown in FIG.

[0247] The transceiver module 1002 is configured to receive first request information from a first in-vehicle component. The first request information is used to apply for a second certificate. The first request information includes a first public key and a first certificate. The first request information is signed using the first certificate. The first certificate is used to at least verify that the first in-vehicle component is entitled to obtain data related to the geographic location information.

[0248] The processing module 1001 is configured to verify the signature of the first request information using the first certificate.

[0249] The transceiver module 1002 is further configured to, if the verification is successful, send first response information to the first in-vehicle component. The first response information includes a second certificate. The second certificate includes a first public key. The second certificate is utilized by the first in-vehicle component to obtain at least a first key. The first key is utilized to encrypt data including at least the geographic location information.

[0250] For a more detailed description of the processing module 1001 and the transceiver module 1002, please directly refer to the relevant description in the method embodiment shown in Figure 3. The details will not be described again here.

[0251] When the apparatus 100 is configured to perform the functions of the first in-vehicle component in the method embodiment shown in FIG. 8, the following occurs.

[0252] The transceiver module 1002 is configured to transmit a random number to a second in-vehicle component when a first condition is met, the first condition including rebooting or waking up the first in-vehicle component.

[0253] The processing module 1001 is configured to encrypt the random number using a first key stored in a first in-vehicle component to obtain a first ciphertext.

[0254] The transceiver module 1002 is further configured to receive a second ciphertext from the second in-vehicle component, where the second ciphertext is associated with a second key and a random number stored in the second in-vehicle component, and if the first ciphertext is different from the second ciphertext, send a third ciphertext to the second in-vehicle component, where the third ciphertext includes information obtained by encrypting the first key using the third key, and the first key is used to encrypt data including at least geographic location information.

[0255] When the apparatus 100 is configured to perform the functions of the second in-vehicle component in the method embodiment shown in FIG. 8, the following occurs.

[0256] The transceiver module 1002 is configured to receive a random number from the first in-vehicle component and transmit a second ciphertext to the first in-vehicle component, where the second ciphertext is associated with a second key stored in the second in-vehicle component and the random number, and to receive a third ciphertext from the first in-vehicle component, where the third ciphertext includes information obtained by encrypting the first key using the third key, and where the first key is used to encrypt data including at least geographic location information.

[0257] For a more detailed description of the processing module 1001 and the transceiver module 1002, please directly refer to the relevant description in the method embodiment shown in Figure 8. The details will not be described again here.

[0258] When the apparatus 100 is configured to perform the functions of the first in-vehicle component in the method embodiment shown in FIG. 9, the following occurs.

[0259] The processing module 1001 is configured to generate, by the first in-vehicle component, a third ciphertext when a second condition is met.

[0260] The transceiver module 1002 is configured to transmit a third ciphertext to the second in-vehicle component. The third ciphertext includes information obtained by encrypting the first key using the third key. The first key is utilized to encrypt data including at least geographic location information. The second condition includes one or more of restarting the first in-vehicle component, waking up the first in-vehicle component, updating a key by the first in-vehicle component, or receiving key request information from the second in-vehicle component by the first in-vehicle component. The key request information is utilized to request the first in-vehicle component to deliver a key (e.g., the key request information is utilized to request the first in-vehicle component to obtain the first key).

[0261] When the apparatus 100 is configured to perform the functions of the second in-vehicle component in the method embodiment shown in FIG. 9, the following occurs.

[0262] The transceiver module 1002 is configured to send key request information to the first in-vehicle component when a third condition is met, where the key request information is used to request the first in-vehicle component to deliver a key (e.g., the key request information is used to request the first in-vehicle component to obtain a first key), and the first key is used to encrypt data including at least geographic location information, and the third condition includes one or more of restarting the second in-vehicle component, waking up the second in-vehicle component, or not storing a key in the second in-vehicle component, and to receive a third ciphertext from the first in-vehicle component, where the third ciphertext includes information obtained by encrypting the first key using the third key.

[0263] For a more detailed description of the processing module 1001 and the transceiver module 1002, please directly refer to the relevant description in the method embodiment shown in Figure 9. The details will not be described again here.

[0264] In a specific implementation, the device 100 may have multiple product forms, some possible product forms are described below.

[0265] 11, an embodiment of the present application provides a key transmission device 110. The device includes at least one processor 1101 and an interface circuit 1102. The interface circuit 1102 is configured to receive code instructions and transmit the code instructions to the at least one processor 1101. The at least one processor 1101 executes the code instructions to perform the methods performed by the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. in the above method embodiments.

[0266] 12, an embodiment of the present application further provides a key transmission device 120 including at least one processor 1201 and at least one memory 1202. The memory 1202 is configured to store computer-executable instructions. The processor 1201 is configured to execute the computer-executable instructions stored in the memory 1202 to enable the device to perform the methods performed by the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. in the above method embodiments.

[0267] It should be understood that the processors described in the embodiments of this application can be implemented through hardware or software. When the processor is implemented through hardware, the processor can be a logic circuit, an integrated circuit, etc. When the processor is implemented through software, the processor can be a general-purpose processor and is implemented by reading software code stored in a memory.

[0268] For example, a processor may be a Central Processing Unit (CPU), another general-purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), another programmable logic device, discrete gates, transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor, or the processor may be any conventional processor, etc.

[0269] It should be understood that the memory described in the embodiments of this application may be volatile memory or nonvolatile memory, or may include volatile memory and nonvolatile memory. Nonvolatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM) used as an external cache. By way of example and not limitation, many forms of RAM may be utilized, such as static random access memory (Static RAM, SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), Synchlink dynamic random access memory (Synchlink DRAM, SLDRAM), and direct Rambus random access memory (Direct Rambus RAM, DR RAM).

[0270] It should be noted that when the processor is 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 memory (storage module) may be integrated into the processor.

[0271] Note that memory as described herein is intended to include, without being limited to, these and any other suitable types of memory.

[0272] Based on the same technical concept, an embodiment of the present application further provides a chip, coupled to a memory, configured to read and execute program instructions stored in the memory to implement the methods performed by the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. in the above method embodiments.

[0273] Based on the same technical concept, an embodiment of this application further provides an in-vehicle terminal, including the device shown in FIG. 10, FIG. 11, or FIG.

[0274] Based on the same technical concept, an embodiment of the present application further provides a computer-readable storage medium configured to store instructions that, when executed, perform the method performed by the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. in the above method embodiments.

[0275] Based on the same technical concept, an embodiment of the present application further provides a computer program product including instructions, which, when executed on a computer, enable the computer to execute the method performed by the first server, the second server, the first in-vehicle component, the second in-vehicle component, etc. in the above method embodiments.

[0276] Those skilled in the art should understand that the embodiments of this application may be provided as a method, a system, or a computer program product. Therefore, this application may utilize the form of a hardware-only embodiment, a software-only embodiment, or an embodiment having a combination of software and hardware. In addition, this application may utilize the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0277] This application is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to this application. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or block diagrams, and combinations of processes and / or blocks in the flowcharts and / or block diagrams. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or any other programmable data processing device to create a machine, whereby the instructions executed by the processor of the computer or any other programmable data processing device create an apparatus for implementing the specific functionality of one or more processes in the flowcharts and / or one or more blocks in the block diagrams.

[0278] These computer program instructions may be stored in a computer-readable memory that can instruct a computer or any other programmable data processing device to operate in a particular manner, whereby the instructions stored in the computer-readable memory produce an artifact that includes an instruction apparatus that implements a particular function in one or more processes in the flowcharts and / or one or more blocks in the block diagrams.

[0279] These computer program instructions may alternatively be loaded onto a computer or other programmable data processing device, whereby a sequence of operations and steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide steps for implementing a particular function in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0280] It is apparent that those skilled in the art may make various modifications and variations to this application without departing from the scope of this application. This application intends to cover these modifications and variations of this application as long as they fall within the scope of protection defined by the claims of this application and their equivalent technologies.

Claims

1. transmitting, by a first in-vehicle component, a random number to a second in-vehicle component when a first condition is met, the first condition including restarting or waking up the first in-vehicle component; encrypting, by the first in-vehicle component, the random number using a first key stored in the first in-vehicle component to obtain a first ciphertext; receiving, by the first in-vehicle component, a second ciphertext from the second in-vehicle component, the second ciphertext being associated with a second key stored in the second in-vehicle component and the random number; if the first ciphertext is different from the second ciphertext, sending, by the first in-vehicle component, a third ciphertext to the second in-vehicle component, the third ciphertext including information obtained by encrypting the first key using a third key, the first key being used to encrypt data including at least geographic location information; A key transmission method comprising:

2. The first in-vehicle component is an in-vehicle computing platform or an in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component. The method of claim 1.

3. generating, by the first in-vehicle component, a third ciphertext when the second condition is satisfied; transmitting, by the first in-vehicle component, the third ciphertext to a second in-vehicle component; Including, the third cryptogram includes information obtained by encrypting a first key using a third key, the first key being utilized to encrypt data including at least geographic location information; the second condition including one or more of restarting the first in-vehicle component, waking up the first in-vehicle component, updating a key by the first in-vehicle component, or receiving key request information by the first in-vehicle component from the second in-vehicle component; the key request information being utilized to request obtaining the first key from a second server, the second server providing a service related to the geographic location information of the vehicle; Key transmission method.

4. The first in-vehicle component is an in-vehicle computing platform or an in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component. The method of claim 3.

5. sending, by a second in-vehicle component, key request information to a first in-vehicle component when a third condition is satisfied, the key request information being utilized to request obtaining a first key from a second server, the second server providing a service related to geographic location information of a vehicle, the first key being utilized to encrypt at least data including the geographic location information, and the third condition including one or more of restarting the second in-vehicle component, waking up the second in-vehicle component, or not storing a key in the second in-vehicle component; receiving, by the second in-vehicle component, a third ciphertext from the first in-vehicle component, the third ciphertext including information obtained by encrypting the first key using a third key; A key transmission method comprising:

6. The first in-vehicle component is an in-vehicle computing platform or an in-vehicle component configured to communicate with an off-vehicle device, and the second in-vehicle component is a cockpit domain component, an autonomous driving domain component, or a chassis power domain component. The method of claim 5.

7. A key transmission device, a transceiver module configured to transmit a random number to a second in-vehicle component when a first condition is met, the first condition including rebooting or waking up the first in-vehicle component on which the device is located; a processing module configured to encrypt the random number using a first key stored in the first in-vehicle component to obtain a first ciphertext; Equipped with The transceiver module includes: receiving a second ciphertext from the second in-vehicle component, the second ciphertext being associated with a second key stored in the second in-vehicle component and the random number; If the first ciphertext differs from the second ciphertext, sending a third ciphertext to the second in-vehicle component, the third ciphertext including information obtained by encrypting the first key with a third key, the first key being used to encrypt at least data including geographic location information. further configured as follows: Key transmission device.

8. A key transmission device, a processing module configured to generate a third ciphertext when a second condition is met; a transceiver module configured to transmit the third cryptogram to a second in-vehicle component; and Equipped with The third cryptogram includes information obtained by encrypting a first key using a third key, and the first key is used to encrypt data including at least geographic location information. The second condition includes one or more of rebooting a first in-vehicle component in which the device is located, waking up the first in-vehicle component, updating a key by the first in-vehicle component, or receiving key request information by the first in-vehicle component from the second in-vehicle component. The key request information is used to request obtaining the first key from a second server, and the second server provides a service related to the geographic location information of the vehicle. Key transmission device.

9. A key transmission device, a transceiver module configured to: send key request information to a first in-vehicle component when a third condition is met, the key request information being utilized to request obtaining a first key from a second server, the second server providing a service related to geographic location information of a vehicle, and the first key being utilized to encrypt at least data including the geographic location information; and the third condition including one or more of rebooting a second in-vehicle component on which the device is located, waking up the second in-vehicle component, or not storing a key in the second in-vehicle component; The transceiver module is further configured to receive a third ciphertext from the first in-vehicle component, the third ciphertext including information obtained by encrypting the first key with a third key. Key transmission device.

10. 10. A computer-readable storage medium configured to store instructions that, when executed, perform a method according to claim 1 or 2, claim 3 or 4, claim 5 or 6.

11. 10. A key transmission device comprising at least one processor and an interface circuit, wherein the interface circuit is configured to receive code instructions and transmit the code instructions to the at least one processor, and the at least one processor executes the code instructions to perform the method of any one of claims 1 or 2, 3 or 4, 5 or 6.

12. 1. A key transmission device comprising at least one processor and at least one memory, wherein the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions stored in the memory to enable the device to perform a method according to any one of claims 1 or 2, 3 or 4, 5 or 6.

13. A chip coupled to a memory and configured to read and execute program instructions stored in the memory to perform the method of any one of claims 1 or 2, 3 or 4, 5 or 6.

14. Equipped with a device according to any one of claims 7 to 9, In-vehicle terminal.

15. Equipped with a device according to any one of claims 7 to 9, vehicle.

Images