In-vehicle service startup methods, electronic devices and media

Abstract

This application relates to the field of vehicle technology and provides a method, electronic device, and medium for starting an in-vehicle service. The method, applied to a server, includes: receiving a signature request from an in-vehicle terminal; signing the startup information of the in-vehicle service to be started in the in-vehicle terminal in response to the signature request, obtaining a startup information signature; sending the startup information signature to the in-vehicle terminal, the startup information signature being used to verify the legality of the startup information of the in-vehicle service; when receiving a data packet request from the in-vehicle terminal, encrypting the requested software data packet of the in-vehicle service, obtaining an encrypted data packet; sending the encrypted data packet to the in-vehicle terminal, the in-vehicle terminal being used to decrypt the encrypted data packet, and starting the in-vehicle service based on the decrypted data packet. Through the method in this application, the security of the in-vehicle service data can be ensured when the in-vehicle terminal starts the in-vehicle service.

Description

Technical Field

[0001] This application belongs to the field of vehicle technology, and in particular relates to an in-vehicle service activation method, electronic device and medium. Background Technology

[0002] A wide range of in-vehicle services can enhance the user experience. For example, smart cars can offer users in-vehicle services such as music streaming, navigation, entertainment content subscriptions, and smart assistant services.

[0003] In-vehicle services provided by smart cars typically require data from third-party entertainment systems. However, during the process of these systems providing data to the vehicle's infotainment system, data leaks can easily occur, potentially leading to hacker attacks or unauthorized use of the services, resulting in financial losses for car owners.

[0004] To ensure data security, the in-vehicle infotainment systems of smart cars need to be adapted to the customized security solutions of each third-party entertainment system, which brings a huge workload to the production of these systems. On the other hand, the security solutions provided by each third-party entertainment system cannot guarantee security. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method for starting an in-vehicle service, an electronic device, and a medium to ensure data security when starting an in-vehicle service.

[0006] A first aspect of this application provides a method for starting an in-vehicle service, applied to a server, the method comprising:

[0007] Receive signature requests from the vehicle terminal;

[0008] In response to the signature request, the startup information of the vehicle service to be started in the vehicle terminal is signed to obtain the startup information signature;

[0009] The startup information signature is sent to the vehicle terminal, and the startup information signature is used to verify the legality of the startup information of the vehicle service;

[0010] When a data packet request is received from the vehicle terminal, the software data packet of the requested vehicle service is encrypted to obtain an encrypted data packet;

[0011] The encrypted data packet is sent to the vehicle terminal, which decrypts the encrypted data packet and starts the vehicle service based on the decrypted data packet.

[0012] A second aspect of this application provides a method for initiating in-vehicle services, applied to an in-vehicle terminal, the method comprising:

[0013] Send a signature request to the server, the signature request being used to request the server to sign the startup information of the vehicle service to be started;

[0014] If a startup information signature is received from the server, the startup information signature is verified based on the stored certificate chain.

[0015] If the startup information signature verification passes, then request the software data package corresponding to the vehicle service from the server;

[0016] When an encrypted data packet is received from the server, the encrypted data packet is decrypted to obtain a software data packet adapted to the vehicle service;

[0017] The in-vehicle service is started based on the software data package of the in-vehicle service.

[0018] A third aspect of this application provides an in-vehicle service initiation device, applied to a server, the device comprising:

[0019] The signature request receiving module is used to receive signature requests from the vehicle terminal.

[0020] The startup information signature module is used to sign the startup information of the vehicle service to be started in the vehicle terminal in response to the signature request, so as to obtain the startup information signature.

[0021] A signature information sending module is used to send the startup information signature to the vehicle terminal, wherein the startup information signature is used to verify the legality of the startup information of the vehicle service;

[0022] The data packet encryption module is used to encrypt the software data packet of the requested vehicle service when a data packet request is received from the vehicle terminal, so as to obtain an encrypted data packet;

[0023] The data packet sending module is used to send the encrypted data packet to the vehicle terminal, and the vehicle terminal is used to decrypt the encrypted data packet and start the vehicle service based on the decrypted data packet.

[0024] A fourth aspect of this application provides an in-vehicle service activation device, applied to an in-vehicle terminal, the device comprising:

[0025] The signature request sending module is used to send a signature request to the server, wherein the signature request is used to request the server to sign the startup information of the vehicle service to be started;

[0026] The signature information verification module is used to verify the startup information signature based on the stored certificate chain if the startup information signature returned by the server is received.

[0027] The data packet request module is used to request a software data packet corresponding to the vehicle service from the server if the startup information signature verification is successful.

[0028] The data packet decryption module is used to decrypt the encrypted data packet received from the server to obtain a software data packet adapted to the vehicle service.

[0029] The vehicle service startup module is used to start the vehicle service based on the software data package of the vehicle service.

[0030] A fifth aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first or second aspect above.

[0031] A sixth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first or second aspect above.

[0032] A seventh aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method described in the first or second aspect.

[0033] Compared with the prior art, the embodiments of this application have the following advantages:

[0034] When starting an in-vehicle service using the method described in this application, the in-vehicle terminal can first send a signature request to the server. Upon receiving the signature request, the server can sign the startup information of the in-vehicle service to be started, obtaining a startup information signature, and then send the startup information signature to the in-vehicle terminal. After receiving the startup information signature, the in-vehicle terminal can verify it. Based on the verification of the startup signature information, the in-vehicle terminal can determine whether the in-vehicle service on the server is legitimate, thereby ensuring the correctness of the subsequently received in-vehicle service data packets. If the startup signature verification passes, the in-vehicle terminal can continue to send data packet requests to the server to request the software data packet for the in-vehicle service. To ensure the security of the software data packet, the server can encrypt the software data packet and send the encrypted software data packet to the in-vehicle terminal. The in-vehicle terminal can decrypt the received data to obtain the software data packet for the in-vehicle service. Based on the obtained software data packet, the in-vehicle terminal can start the in-vehicle service. In this application embodiment, during the process of starting the in-vehicle service, the in-vehicle terminal can first perform a verification based on the signature to ensure the legitimacy of the data on the server; simultaneously, during data transmission, encrypted transmission can be performed to avoid data leakage and ensure data security. When the vehicle terminal initiates any vehicle service, it can obtain the corresponding vehicle service software data package from the server based on the method in this embodiment. It only needs to communicate securely with the server. During the production of the vehicle system, there is no need for hardware configuration and integration for specific security schemes, thus reducing the workload of vehicle system production. Furthermore, when upgrading vehicle services, the vehicle terminal can still initiate the upgraded vehicle service based on the method in this embodiment, without needing to upgrade the vehicle service via over-the-air (OTA) download technology. This allows the vehicle terminal to use vehicle services more conveniently, thereby reducing the pressure on OTA download services in the vehicle and improving the efficiency of OTA download services. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0036] Figure 1 This is a flowchart illustrating the steps of an in-vehicle service startup method provided in an embodiment of this application;

[0037] Figure 2 This is a flowchart illustrating the steps of another in-vehicle service startup method provided in this application embodiment;

[0038] Figure 3 This is a flowchart illustrating a method for starting an in-vehicle service provided in an embodiment of this application;

[0039] Figure 4This is a schematic diagram illustrating an application scenario for starting an in-vehicle service, as provided in an embodiment of this application.

[0040] Figure 5 This is a schematic diagram of an in-vehicle service activation device provided in an embodiment of this application;

[0041] Figure 6 This is a schematic diagram of an in-vehicle service activation device provided in an embodiment of this application;

[0042] Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0043] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0044] With the rapid development of intelligent vehicles, third-party in-vehicle entertainment subscription services have become an important part of enhancing user experience. For example, various third-party in-vehicle entertainment systems can provide intelligent vehicles with music streaming services, navigation services, entertainment content subscriptions, and intelligent assistant services. These in-vehicle services offer car owners and passengers a richer and more convenient in-vehicle entertainment experience.

[0045] However, the security of third-party subscription services faces serious challenges. They are vulnerable to hacking, potentially leading to unauthorized use of in-vehicle entertainment services and resulting in financial losses for both the service developers and car owners. Furthermore, when smart cars use in-vehicle entertainment services through third-party subscriptions, the software and firmware are typically managed by the OEM (Original Equipment Manufacturer), requiring the OEM to ensure the third-party source code is not leaked, which increases their workload.

[0046] Furthermore, current upgrades to in-vehicle entertainment services are generally performed online via Over-the-Air (OTA) technology. However, as in-vehicle entertainment services become increasingly diverse and users utilize more and more of them, relying solely on OTA upgrades would pose a significant challenge to the efficiency of vehicle OTA technology.

[0047] Currently, there is no unified standard or solution to address the above issues. Some in-vehicle entertainment service developers can provide customized security solutions to address safety concerns. OEMs of smart vehicle systems can adapt and integrate their systems according to these customized security solutions during the manufacturing process. However, this approach has the following problems:

[0048] Different in-vehicle entertainment service developers require different security solutions for their in-vehicle systems, resulting in a huge workload for OEMs in customizing and adapting these systems. Furthermore, the security technology levels of different in-vehicle entertainment service developers vary, and some of their customized security solutions cannot guarantee security. Additionally, security upgrades for in-vehicle services still rely on over-the-air (OTA) updates, impacting the efficiency of this technology.

[0049] Based on this, this application provides a method for starting an in-vehicle service to ensure data security during the in-vehicle service startup process.

[0050] The technical solution of this application will be described below through specific embodiments.

[0051] Reference Figure 1 The diagram illustrates a step-by-step flowchart of an in-vehicle service startup method provided in an embodiment of this application, which may specifically include the following steps:

[0052] S101 receives a signature request from the vehicle terminal.

[0053] The method in this embodiment can be applied to a server, which can be a cloud server. This embodiment does not limit the specific type of server. The server can be a vehicle service platform that can communicate with the in-vehicle terminals of multiple vehicles to provide services to the in-vehicle terminals. For example, the server can be a service platform provided by a vehicle manufacturer for vehicles produced in its own factory.

[0054] The aforementioned vehicle-mounted terminal can be a smart device installed in a vehicle. For example, the vehicle-mounted terminal can be a vehicle infotainment system or other electronic components; this embodiment does not limit the specific type of vehicle-mounted terminal. Each vehicle-mounted terminal can have unique identification information. When communicating with the server, the vehicle-mounted terminal can carry the identification information, thereby enabling the server to determine the identity of the vehicle-mounted terminal based on the identification information.

[0055] The aforementioned signature request can be sent to the server by the in-vehicle terminal when starting the in-vehicle service. The signature request is used to request a signature for the startup information of the in-vehicle service to be started. The in-vehicle service to be started can be an in-vehicle service that has never been used in the in-vehicle terminal, or an in-vehicle service that is currently in use but needs an upgrade. Each in-vehicle service can also have unique identification information to identify its type, version, etc.

[0056] The signature request can carry the identification information of the vehicle terminal and the identification information of the vehicle service to be started.

[0057] S102, in response to the signature request, the startup information of the vehicle service to be started in the vehicle terminal is signed to obtain the startup information signature.

[0058] Based on the identification information of the vehicle service carried in the signature request, the server can find the startup information of the vehicle service. Based on the identification information of the vehicle terminal carried in the signature request, the server can find the signing private key of the vehicle terminal.

[0059] When the server signs the startup information of the vehicle service, it can calculate the hash value of the first startup information, and then encrypt the hash value of the first startup information using the signing private key to obtain the startup information signature.

[0060] The aforementioned signing private key can be pre-generated by the server. The server can pre-generate a signing key pair for signing, which may include a signing private key and a signing public key. The signing key pair can be generated based on asymmetric encryption technology. The vehicle terminal can obtain the signing public key and thus verify the signature of the startup information based on the signing public key.

[0061] The signing public key can reside in the certificate chain of the vehicle terminal. The certificate chain of the vehicle terminal can be pre-sent to the vehicle terminal by the server. The server can generate a root key pair and a signing key pair. The root key pair can include a root public key and a root private key, and the signing key pair can include a signing public key and a signing private key.

[0062] Based on the root public key, the server can generate a root certificate; based on the root certificate and the signing public key, the server can generate a signing certificate. After generating the root certificate, the server can calculate its hash value, obtain a first hash value, and send it to the third-party manufacturer producing the in-vehicle terminal. During the production process of the in-vehicle terminal, the third-party manufacturer can burn this first hash value into the chip of the in-vehicle terminal. Each in-vehicle terminal may include a chip; for example, the chip may be located within a sub-component in the vehicle's cockpit area. This sub-component can be a hardware unit for in-vehicle services provided by the third-party manufacturer. The chip in the in-vehicle terminal can be a dedicated function chip provided by the third-party service provider, a Qualcomm chip common to the cockpit domain, or a chip developed by the OEM. This chip has secure storage and computing capabilities and supports fuse operations. The first hash value is burned into the fuse bits within the chip; the in-vehicle terminal can only read the first hash value and cannot modify it.

[0063] The root certificate and signing certificate generated by the server can form a certificate chain. The server can send the certificate chain offline to the vehicle terminal. For example, the certificate chain can be sent via removable storage media. After the server sends the certificate chain to the vehicle terminal, the vehicle terminal can obtain the root certificate in the certificate chain, and then perform a hash calculation to obtain a second hash value. The vehicle terminal can read the first hash value from the fuse bit, and then compare the first hash value with the second hash value. If the first hash value is the same as the second hash value, it can be determined that the certificate chain has been verified, and the vehicle terminal can store the certificate chain.

[0064] The first hash value stored in the vehicle terminal is burned into the system during production. Therefore, the vehicle terminal can only read this first hash value and cannot modify it. External attacks cannot tamper with the first hash value stored in the vehicle terminal. This first hash value comes from the server and is the hash value of the root certificate. Therefore, after receiving the certificate chain, if the calculated second hash value of the root certificate in the certificate chain is the same as the first hash value read by the vehicle terminal, it indicates that the certificate chain verification is successful. Based on the fact that the first hash value cannot be modified and can only be read, the certificate chain verification process is protected from interference by external attacks, ensuring the legitimacy of the certificate chain verification.

[0065] The server can deploy Public Key Infrastructure (PKI) services and a hardware security module (HSM). By calling the HSM service, the server can generate a root key pair and a signing key pair. By calling the PKI service, the server can generate a root certificate based on the root public key. After generating the root certificate, the server can issue a signing certificate based on the signing public key.

[0066] S103, the startup information signature is sent to the vehicle terminal, and the startup information signature is used to verify the legality of the startup information of the vehicle service.

[0067] After receiving the startup information signature, the vehicle terminal can first decrypt the startup information signature based on the signing public key in the signing certificate in the certificate chain, thereby obtaining the first startup information hash value. The vehicle terminal can then calculate the hash value of the startup information to obtain the second startup information hash value.

[0068] If the hash values ​​of the first and second startup information are different, it may be due to incorrect startup information on the server or tampering with the startup signature information. In this case, the vehicle terminal cannot communicate securely with the service or cannot request the correct vehicle service data packet from the server. Therefore, the startup process of the current vehicle service can be interrupted.

[0069] If the hash value of the first startup information is the same as the hash value of the second startup information, the vehicle terminal can determine that the startup information signature verification is successful, and can then continue to request software data packets for vehicle services from the server.

[0070] S104, when a data packet request is received from the vehicle terminal, the software data packet of the requested vehicle service is encrypted to obtain an encrypted data packet.

[0071] After successfully verifying the startup signature information, the vehicle-mounted terminal can send a data packet request to the server, thereby requesting the software data packet for the vehicle-mounted service to be started. This data packet request may carry the vehicle-mounted terminal's identification information.

[0072] After receiving the data packet request, the server can find the data packet key of the vehicle terminal based on the identification information of the vehicle terminal. The data packet key is pre-generated by the server and sent to the vehicle terminal. Based on the data packet key of the vehicle terminal, the software data packet of the vehicle service request is encrypted to obtain an encrypted data packet.

[0073] The server can pre-generate a unique data packet key for each vehicle terminal, which is used to encrypt or decrypt data packets. This data packet key can be a symmetric key; the server can use this key to encrypt data packets, and the vehicle terminal can use it to decrypt them.

[0074] To ensure the security of the data packet key, the server can encrypt the data packet key during transmission when sending it to the vehicle terminal.

[0075] For example, the server can call the HSM to generate data packet keys for the vehicle terminal and associate each data packet key with the vehicle terminal's identification information for storage. Before starting the vehicle service, the vehicle terminal can send a key request to the server, which can carry the vehicle terminal's identification information. If a key request is received from the vehicle terminal, the server can look up the vehicle terminal's device certificate based on the vehicle terminal's identification information. The vehicle terminal's device certificate may include the vehicle terminal's public key. Based on the vehicle terminal's public key, the server can encrypt the data packet key and send the encrypted data packet key to the vehicle terminal. After receiving the encrypted data packet key, the vehicle terminal can decrypt it using its private key to obtain the decrypted data packet key.

[0076] Among them, the device certificate of the vehicle terminal can be written to the server during the vehicle production process.

[0077] S105, the encrypted data packet is sent to the vehicle terminal, the vehicle terminal is used to decrypt the encrypted data packet, and start the vehicle service based on the decrypted data packet.

[0078] The server can send encrypted data packets to the in-vehicle terminal, which can then decrypt the encrypted data packets using a stored data packet key to obtain the software data packets from the in-vehicle server. The in-vehicle terminal can then launch the in-vehicle service based on these software data packets.

[0079] In this embodiment, when the vehicle terminal starts the vehicle service, it can directly obtain data from the server, thereby avoiding the need for adaptation with multiple third-party entertainment systems and reducing the adaptation workload in the vehicle terminal production process. When starting or upgrading the vehicle service, the vehicle terminal can perform legality verification based on the startup information signature. Verification based on the signature information can further verify communication security and ensure the legality of the vehicle service information. When sending data packets, the vehicle terminal and the server can encrypt the data transmission, thereby ensuring the security of the data packets, preventing the theft of software data packets, and thus protecting the rights and interests of vehicle owners and vehicle service developers. The method in this embodiment is also applicable to upgrading vehicle services, allowing vehicle services to be upgraded without over-the-air (OTA) technology, thereby reducing the pressure on OTA technology in vehicles and improving the efficiency of OTA technology.

[0080] Reference Figure 2 This illustration shows a flowchart of another in-vehicle service startup method provided in an embodiment of this application, which may specifically include the following steps:

[0081] S201, a signature request is sent to the server, the signature request being used to request the server to sign the startup information of the vehicle service to be started.

[0082] In this embodiment, the executing entity can be an in-vehicle terminal. The in-vehicle terminal can be a front-end device for intelligent vehicle management. The in-vehicle terminal can connect to a server to obtain server data.

[0083] The aforementioned in-vehicle services to be activated can be software provided by entertainment service providers or software developed by the car manufacturer itself. In-vehicle services may include weather services, music services, game services, recording services, video services, etc., but this embodiment does not limit the in-vehicle services.

[0084] The aforementioned startup information may include version information, type information, etc., of the in-vehicle service. The startup information can be a startup image of the in-vehicle service. The startup information can be sent to the in-vehicle terminal by an intermediate service. When starting the in-vehicle service, it is first necessary to ensure that the startup information in the in-vehicle terminal and the server are identical. Therefore, the in-vehicle terminal can send a signature request to the server to verify the startup information.

[0085] During communication between the vehicle-mounted terminal and the server, to ensure data security, the vehicle-mounted terminal can proactively initiate a bidirectional Transport Layer Security (TLS) connection with the server. Based on the bidirectional TLS connection, the vehicle-mounted terminal can call the server's HSM to obtain the startup information signature.

[0086] S202, if the startup information signature returned by the server is received, the startup information signature is verified based on the stored certificate chain.

[0087] The certificate chain of the vehicle terminal may include a signature certificate, which may include a signature public key. The signature public key and the signature private key on the server side are an asymmetric key pair, and the signature public key can decrypt the information encrypted by the signature private key.

[0088] The vehicle-mounted terminal can obtain the signing public key from the signing certificate and decrypt the startup information signature based on the signing public key to obtain the first startup information hash value from the server. The vehicle-mounted terminal can calculate the second startup information hash value of the stored startup information of the vehicle service; then compare the first startup hash value and the second startup hash value to verify the startup information signature.

[0089] If the hash value of the first startup information is the same as the hash value of the second startup information, it can be determined that the startup information signature verification is successful, and the vehicle terminal can continue to start the vehicle service based on the subsequent steps.

[0090] The certificate chain in the vehicle terminal can be pre-sent by the server. The vehicle terminal may include a chip that supports fuse functionality. During the manufacturing process of the vehicle terminal, the manufacturer can receive the first hash value of the root certificate sent by the server and fuse the chip, i.e., burn the first hash value into the fuse bit of the chip. After the first hash value is burned into the fuse bit, the vehicle terminal can only read the first hash value of that fuse bit and cannot modify it. That is, the first hash value is determined during vehicle manufacturing, and hacker attacks cannot change it.

[0091] Based on the stored first hash value, when the vehicle terminal receives a certificate chain from the server, it can first verify the certificate chain. The certificate chain includes a root certificate and a signing certificate; the vehicle terminal can perform a hash calculation on the root certificate in the certificate chain to obtain a second hash value. The vehicle terminal can read the immutable first hash value from the fuse bits. Then, it compares the first hash value with the second hash value to determine whether the certificate chain is valid. If the first hash value and the second hash value are the same, it indicates that the certificate chain verification is successful, and the vehicle terminal can store the certificate chain. The signing certificate in the certificate chain is issued by the root certificate, and the root certificate can be used to guarantee the validity of the signing certificate. Therefore, the vehicle terminal only needs to verify the root certificate to determine the validity of the certificate chain.

[0092] S203, if the startup information signature verification passes, then request the software data packet corresponding to the vehicle service from the server.

[0093] After the startup information signature verification is successful, the vehicle terminal can request software data packets for vehicle services from the server based on a two-way TLS connection.

[0094] S204, when an encrypted data packet is received from the server, the encrypted data packet is decrypted to obtain a software data packet adapted to the vehicle service.

[0095] The vehicle terminal may include main control software and a secure storage module (Trust Zone), which can store data packet keys.

[0096] The vehicle terminal can decrypt encrypted data packets based on the stored data packet key to obtain the software data packets for vehicle services.

[0097] The aforementioned data packet key can be pre-sent by the server to the vehicle terminal. Before initiating vehicle services, the vehicle terminal can send a key request to the server, which can carry the vehicle terminal's identification information. Upon receiving the key request from the vehicle terminal, the server can locate the vehicle terminal's device certificate based on the identification information. The device certificate may include the vehicle terminal's public key. Based on the vehicle terminal's public key, the server can encrypt the data packet key and send the encrypted data packet key to the vehicle terminal. After receiving the encrypted data packet key, the vehicle terminal can decrypt it using the vehicle terminal's private key from the device certificate, thereby obtaining the decrypted data packet key. The vehicle terminal's device certificate can be installed into the vehicle terminal during vehicle production.

[0098] S205, based on the software data package of the vehicle service, start the vehicle service.

[0099] The method in this embodiment can be executed when starting the in-vehicle service or when upgrading the in-vehicle service. In other words, the method in this embodiment can be used to start and upgrade the in-vehicle service.

[0100] Through the method in this embodiment, the vehicle terminal can launch and upgrade vehicle services via encrypted communication with the server, ensuring the security of the vehicle service software data packets and preventing the theft of vehicle services, thereby protecting the rights and interests of service providers and vehicle owners. When launching any vehicle service, the terminal device can obtain the software data packets for the vehicle service from the server based on the method in this embodiment, requiring only secure communication with the server. During the production process of the vehicle system, there is no need for hardware configuration and integration for specific security schemes, thus reducing the workload of vehicle system production. Simultaneously, when upgrading vehicle services, the vehicle terminal can still launch the upgraded vehicle service based on the method in this embodiment, without needing to upgrade the vehicle service via over-the-air (OTA) technology. This allows the vehicle terminal to use vehicle services more conveniently, thereby reducing the pressure on OTA services in vehicles and improving the efficiency of OTA services.

[0101] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0102] To more clearly illustrate the solution in this application, a specific embodiment is provided below. Figure 3 This is a flowchart illustrating a method for starting an in-vehicle service provided in an embodiment of this application.

[0103] Figure 3 The vehicle's ECU (electronic control unit) is the aforementioned in-vehicle terminal, which contains the main control software and a secure storage module (Trust Zone). Figure 3 The cloud in this context refers to the aforementioned servers, where secure PKI services and HSM secure storage can be deployed.

[0104] like Figure 3As shown, the cloud can generate a root key pair root_pri+root_pub and a signing key pair sign_pri+sign_pub. The server calls the PKI service and can generate a root certificate root_cert based on the root public key root_pub. Based on the root certificate root_cert, a signing certificate sign_cert can be issued on the signing public key sign_pub. root_cert+sign_cert form a certificate chain. In this embodiment, the certificate chain may only include two layers of certificate trust chains: root_cert+sign_cert. Those skilled in the art should understand that any number of trust chains can be added to the certificate chain based on the actual scenario.

[0105] The cloud can calculate the hash value (hash_root) of root_cert and provide it to the third-party vendor. When the third-party vendor manufactures customized chips for the OEM, they can perform a fuse, which involves writing the hash_root into the fuse bits. After the fuse is used, the content written to the chip's fuse bits cannot be changed, but it can be queried repeatedly. The third-party vendor only writes the hash_root and does not need to participate in other processes.

[0106] The cloud can send the certificate chain to the vehicle's ECU. The ECU can calculate the hash value (hash_root) of the root CA in the built-in chain and read the hash_root of the fuse bit. If the two hash values ​​are equal, it indicates that the fuse bit verification is successful, and the ECU can write the certificate chain into the ECU; otherwise, the chain cannot be written to the ECU.

[0107] The cloud also needs to send a key k to the vehicle's ECU for encrypting data packets. Key k is the same as the data packet key mentioned above.

[0108] The cloud can call the HSM to generate a key k, which can be a symmetric key. The main control software of the vehicle's ECU can initiate a two-way TLS connection to the cloud to transmit the vehicle ID and request the encryption key enc_k from the cloud PKI service. The vehicle ID is the identification information of the aforementioned in-vehicle terminal.

[0109] The cloud-based PKI service can query the device certificate dvc_cert corresponding to the vehicle's ECU based on the vehicle ID. The PKI service then calls the cloud-based encryption machine HSM service to export the key k of the vehicle's ECU, and then encrypts the key k using the device public key dvc_pub within dvc_cert to generate the encryption key enc_k. Afterward, the cloud-based PKI service returns enc_k to the vehicle's ECU.

[0110] After the vehicle's ECU obtains enc_k, the main control software can call the Trust Zone interface, use the Trust Zone's device certificate private key dvc_pri to decrypt enc_key, and obtain the decrypted key k; and write k into Trust Zone for secure storage.

[0111] When starting up and upgrading in-vehicle services, the vehicle's ECU can proactively initiate a two-way TLS connection with the cloud, thereby calling the cloud's HSM service and using the cloud's signing key sign_pri to obtain the startup information signature signed_data. The cloud can then send the startup information signature signed_data to the vehicle's ECU.

[0112] After receiving the signed_data, the vehicle's ECU can use the ECU's built-in chain to verify the signature validity of the signed_pack.

[0113] After the signed_data verification is successful, the vehicle's ECU can request the encryption software enc_pack from the cloud. The vehicle's ECU can proactively initiate a two-way TLS connection with the cloud, call the cloud's HSM service, use the key k within the HSM to encrypt the software data packet pack, and obtain enc_pack.

[0114] After receiving the encrypted software data packet `enc_pack`, the vehicle's ECU can call the TrustZone interface through the KM Service, use the 'k' within the TrustZone to decrypt `enc_pack`, and obtain the plaintext software data packet `pack`. Based on this plaintext `pack`, the vehicle's services can be successfully started or upgraded.

[0115] The method in this embodiment provides a unified, end-to-end security scheme based on cryptography. In this embodiment, the server generates a root key pair and a signature key pair, and sends the root key certificate (i.e., the root certificate hash value) to a third-party manufacturer. During chip manufacturing, the third-party manufacturer writes the root certificate into the chip of the vehicle terminal using a fuse. Then, during the vehicle manufacturing phase, the vehicle terminal can flash the certificate chain after successfully verifying the fuse bit. Afterward, the vehicle terminal can obtain the data packet key from the server. The server can encrypt the data packet key based on the vehicle terminal's device certificate and transmit it to the vehicle terminal, thus ensuring secure transmission of the data packet key and guaranteeing a unique key for each vehicle. Based on the certificate chain and the data packet key, when starting or upgrading vehicle services, the vehicle terminal can first verify the signature of the startup information with the server. After the startup information's legitimacy is verified, the software data packet is obtained based on the data packet key, thereby ensuring data security during the startup or upgrade process of vehicle services.

[0116] Figure 4 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. The in-vehicle terminal can obtain the vehicle-supported entertainment services from the intermediate service and display them on the display interface. Users can select the in-vehicle service they wish to use based on the content displayed on the interface.

[0117] like Figure 4 As shown, the display interface can show in-vehicle services such as video, music, weather, and voice recorder. When a user needs to activate or upgrade the video service, the in-vehicle terminal can send a signature request for the video activation information to the cloud. The cloud can use a signing private key to sign the video activation information, thus obtaining the activation information signature, and then send the activation information signature to the in-vehicle terminal.

[0118] The in-vehicle terminal can verify the startup signature information. After successful verification, it can request the video software data package from the cloud. The cloud can encrypt the software data package and send it to the cloud. The cloud then decrypts the encrypted software data to obtain the video software data package. Based on this software data package, the in-vehicle terminal can launch the video software, which can then be displayed on the screen. Figure 4 The interface shown.

[0119] Reference Figure 5 The diagram illustrates an in-vehicle service startup device according to an embodiment of this application. This device is applied to a server and specifically may include a signature request receiving module 51, a startup information signing module 52, a signature information sending module 53, a data packet encryption module 54, and a data packet sending module 55, wherein:

[0120] The signature request receiving module 51 is used to receive signature requests from the vehicle terminal.

[0121] The startup information signature module 52 is used to sign the startup information of the vehicle service to be started in the vehicle terminal in response to the signature request, so as to obtain the startup information signature.

[0122] The signature information sending module 53 is used to send the startup information signature to the vehicle terminal, and the startup information signature is used to verify the legality of the startup information of the vehicle service;

[0123] The data packet encryption module 54 is used to encrypt the software data packet of the requested vehicle service when a data packet request is received from the vehicle terminal, so as to obtain an encrypted data packet;

[0124] The data packet sending module 55 is used to send the encrypted data packet to the vehicle terminal, and the vehicle terminal is used to decrypt the encrypted data packet and start the vehicle service based on the decrypted data packet.

[0125] In one possible implementation, the aforementioned startup information signature module 52 includes:

[0126] The public key retrieval submodule is used to obtain the signing private key;

[0127] The signing submodule is used to sign the startup information of the vehicle service based on the signing private key to obtain the startup information signature; the signing private key has a corresponding signing certificate, the signing certificate is sent to the vehicle terminal in advance, and the vehicle terminal is used to verify the startup information signature based on the signing certificate.

[0128] In one possible implementation, the above-mentioned device further includes:

[0129] A key generation module is used to generate a root key pair and a signature key pair, wherein the root key pair includes a root public key and a root private key, and the signature key pair includes a signature public key and a signature private key;

[0130] The certificate chain generation module is used to generate a root certificate and a signature certificate based on the root public key and the signature public key, wherein the root certificate and the signature certificate constitute the certificate chain;

[0131] The certificate chain sending module is used to send the certificate chain to the vehicle terminal, and the vehicle terminal is used to verify the certificate chain according to the root certificate, and store the certificate chain after the certificate chain is verified.

[0132] In one possible implementation, the above-mentioned device further includes:

[0133] The first hash value generation module is used to generate a first hash value for the vehicle terminal to be burned into the vehicle terminal; wherein, the first hash value is the hash value of the root certificate, so that the vehicle terminal can verify the certificate chain from the server based on the first hash value;

[0134] The burning characteristic indicates that the first hash value can be read by the vehicle terminal, but cannot be modified by the vehicle terminal.

[0135] In one possible implementation, the aforementioned data packet encryption module 54 includes:

[0136] The data packet key lookup submodule is used to look up the data packet key of the vehicle terminal based on the identification information of the vehicle terminal. The data packet key is pre-generated by the server and sent to the vehicle terminal.

[0137] The encryption submodule is used to encrypt the software data packet of the vehicle service request based on the data packet key of the vehicle terminal to obtain an encrypted data packet.

[0138] Reference Figure 6 The diagram illustrates an in-vehicle service startup device according to an embodiment of this application. This device is applied to an in-vehicle terminal and specifically includes a signature request sending module 61, a signature information verification module 62, a data packet request module 63, a data packet decryption module 64, and an in-vehicle service startup module 65, wherein:

[0139] The signature request sending module 61 is used to send a signature request to the server, the signature request being used to request the server to sign the startup information of the vehicle service to be started.

[0140] The signature information verification module 62 is used to verify the startup information signature based on the stored certificate chain if the startup information signature returned by the server is received.

[0141] The data packet request module 63 is used to request a software data packet corresponding to the vehicle service from the server if the startup information signature verification is successful.

[0142] The data packet decryption module 64 is used to decrypt the encrypted data packet received from the server to obtain a software data packet adapted to the vehicle service.

[0143] The vehicle service startup module 65 is used to start the vehicle service based on the software data package of the vehicle service.

[0144] In one possible implementation, the certificate chain includes a signing certificate, which includes a signing public key, and the aforementioned signature information verification module 62 includes:

[0145] The first startup information hash value decryption submodule is used to decrypt the startup information signature based on the signature public key to obtain the first startup information hash value from the server;

[0146] The second startup information hash value calculation submodule is used to calculate the second startup information hash value of the vehicle service startup information.

[0147] The verification submodule is used to verify the startup information signature if the first startup information hash value and the second startup information hash value are the same.

[0148] In one possible implementation, the above-mentioned device further includes:

[0149] The certificate link receiving module is used to receive a certificate chain from the server, the certificate chain including a root certificate and a signing certificate;

[0150] The first hash value acquisition module is used to acquire a first hash value pre-burned into the vehicle terminal, wherein the first hash value is the hash value of the root certificate from the server;

[0151] The second hash value calculation module is used to perform hash calculation on the root certificate in the certificate chain to obtain the second hash value;

[0152] A certificate chain storage module is used to store the certificate chain if the first hash value and the second hash value are the same.

[0153] In one possible implementation, the burning indicates that the first hash value can be read by the vehicle terminal, but cannot be modified by the vehicle terminal.

[0154] The first hash value acquisition module includes:

[0155] The read submodule is used to read the first hash value.

[0156] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0157] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 7 of this embodiment includes: at least one processor 70 ( Figure 7 (Only one is shown in the diagram), memory 71, and computer program 72 stored in said memory 71 and executable on said at least one processor 70, which, when executed, implements the steps in any of the above method embodiments.

[0158] The electronic device can be the aforementioned server or vehicle-mounted terminal, and may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 7 This is merely an example of electronic device 7 and does not constitute a limitation on electronic device 7. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0159] The processor 70 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0160] In some embodiments, the memory 71 may be an internal storage unit of the electronic device 7, such as a hard disk or memory of the electronic device 7. In other embodiments, the memory 71 may be an external storage device of the electronic device 7, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 7. Furthermore, the memory 71 may include both internal and external storage units of the electronic device 7. The memory 71 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 71 can also be used to temporarily store data that has been output or will be output.

[0161] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0162] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0163] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method of initiating a vehicle service, characterized by, Applied to a server, the method comprises: generating a root key pair and a signature key pair, the root key pair comprising a root public key and a root private key, and the signature key pair comprising a signature public key and a signature private key; generating a root certificate and a signature certificate based on the root public key and the signature public key, the root certificate and the signature certificate constituting the certificate chain; sending the certificate chain to the vehicle terminal, the vehicle terminal being configured to verify the certificate chain based on the root certificate and store the certificate chain after the certificate chain is verified; receiving a signature request from the vehicle terminal; in response to the signature request, signing start information of a vehicle service to be started in the vehicle terminal to obtain start information signature; sending the start information signature to the vehicle terminal, the start information signature being used to verify the legality of the start information of the vehicle service; when receiving a data packet request from the vehicle terminal, encrypting software data packet of the requested vehicle service to obtain an encrypted data packet; sending the encrypted data packet to the vehicle terminal, so that the vehicle terminal decrypts the encrypted data packet and starts the vehicle service based on the decrypted data packet; the signing of the start information of the vehicle service to be started in the vehicle terminal in response to the signature request to obtain the start information signature comprises: obtaining the signature private key; signing the start information of the vehicle service based on the signature private key to obtain the start information signature; the signature private key has a corresponding signature certificate, and the signature certificate is sent to the vehicle terminal in advance, and the vehicle terminal is configured to verify the start information signature based on the signature certificate.

2. The method of claim 1, wherein, Further comprising: generating a first hash value for the vehicle terminal, which is burned into the vehicle terminal; wherein the first hash value is a hash value of the root certificate, so that the vehicle terminal verifies the certificate chain from the server based on the first hash value; the burning indicates that the first hash value can be read by the vehicle terminal but cannot be modified by the vehicle terminal.

3. The method according to any one of claims 1 to 2, wherein, the encryption of the software data packet of the requested vehicle service to obtain the encrypted data packet comprises: finding a data packet key of the vehicle terminal according to identification information of the vehicle terminal, the data packet key being generated by the server in advance and sent to the vehicle terminal; encrypting the software data packet of the vehicle service request based on the data packet key of the vehicle terminal to obtain the encrypted data packet.

4. The method of claim 1, wherein, Before receiving the signature request from the vehicle terminal, the method further comprises: generating a data packet key of the vehicle terminal; if a key request is received from the vehicle terminal, finding a device certificate of the vehicle terminal according to identification information of the vehicle terminal, the device certificate comprising a public key of the vehicle terminal; encrypting the data packet key based on the public key of the vehicle terminal; sending the encrypted data packet key to the vehicle terminal.

5. A method of starting a vehicle service, characterized by Applied to a vehicle terminal, the method comprises: receiving a certificate chain from a server, the certificate chain comprising a root certificate and a signature certificate; obtaining a first hash value pre-burned in the vehicle terminal, the first hash value being a hash value of a root certificate from the server; hashing the root certificate in the certificate chain to obtain a second hash value; storing the certificate chain if the first hash value and the second hash value are the same; sending a signature request to the server, the signature request being used to request the server to sign start information of a vehicle service to be started; verifying the start information signature based on the stored certificate chain if the start information signature returned by the server is received; requesting software data packets corresponding to the vehicle service from the server if the start information signature is verified; decrypting the encrypted data packets to obtain software data packets adapted to the vehicle service when the encrypted data packets from the server are received; starting the vehicle service based on the software data packets of the vehicle service. The certificate chain includes a signature certificate, the signature certificate including a signature public key, and the verifying the start information signature based on the stored certificate chain includes: decrypting the start information signature based on the signature public key to obtain a first start information hash value from the server; calculating a second start information hash value of the start information of the vehicle service; the start information signature is verified if the first start information hash value and the second start information hash value are the same.

6. The method of claim 5, wherein, The burn indicates that the first hash value can be read by the vehicle terminal but cannot be modified by the vehicle terminal. The obtaining the first hash value pre-burned in the vehicle terminal includes: reading the first hash value.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method of any one of claims 1-6.

8. A computer-readable storage medium storing a computer program, the computer-readable storage medium comprising: The computer program is executed by the processor to implement the method of any one of claims 1-6.

Images