Vehicle cloud collaboration method and device and related products

Abstract

The invention discloses a vehicle cloud cooperation method and device, and a related product. And establishing an encryption tunnel between the vehicle side and the cloud side, and before each service call, performing session key negotiation between the cloud side and the vehicle side through the encryption tunnel to obtain a session key corresponding to a single service call request. And a dynamic negotiation mode is adopted to limit the validity period of the key as single call, so that the risk of long-term key leakage is avoided. And after the service calling request is encrypted by using the session key, request issuing between the cloud end and the vehicle end is carried out through the encryption tunnel, so that the service calling request is executed after the vehicle end decrypts the service calling request by using the session key, and the packaged vehicle function is called. Two-layer encryption of a transmission layer and a service layer is constructed, the outer layer establishes vehicle cloud link encryption based on an encryption tunnel to guarantee transmission security, and the inner layer performs end-to-end encryption on a service request at a service calling level based on a session key. The two layers of encryption mechanisms are mutually independent, deep defense is achieved, and high-safety guarantee is provided for vehicle-cloud cooperation.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and related products for vehicle-cloud collaboration. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards a centralized model, Service-Oriented Architecture (SOA) is gradually becoming the core paradigm for in-vehicle communication. SOA encapsulates vehicle functions into discoverable and invokeable standardized services, enabling vehicle-cloud collaboration. For example, it links intelligent cockpit services on the vehicle with autonomous driving services in the cloud.

[0003] In existing technologies, SOA vehicle-cloud collaboration methods directly expose vehicle-side services through standard protocols, making them vulnerable to malicious scanning and unauthorized access. Vehicle-cloud communication also relies on standard security protocols for encryption, making it difficult to cope with increasingly complex cyberattack threats and potentially leading to serious consequences such as service forgery, data leakage, and system compromise. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a method, apparatus, and related products for vehicle-cloud collaboration, which improves upon existing SOA vehicle-cloud collaboration methods and enhances their security.

[0005] This application discloses a method for vehicle-cloud collaboration, the method comprising:

[0006] Establish an encrypted tunnel between the vehicle and the cloud;

[0007] The session key between the cloud and the vehicle is negotiated through the encrypted tunnel to obtain a session key corresponding to a single service call request; the service call request is used to invoke the encapsulated vehicle functions.

[0008] After encrypting the service call request using the session key, the request is sent between the cloud and the vehicle through the encrypted tunnel, so that the service call request can be executed on the vehicle after being decrypted using the session key.

[0009] Optionally, establishing an encrypted tunnel between the vehicle and the cloud includes:

[0010] The vehicle-mounted device establishes the encrypted tunnel based on a device certificate, a public key, and a private key; the device certificate is obtained by the vehicle-mounted device from the cloud for the vehicle's functions.

[0011] Optionally, the step of executing the service call request on the vehicle side after decryption using the session key includes:

[0012] The vehicle uses the session key to decrypt and obtain the service call request;

[0013] The vehicle verifies the digital signature corresponding to the service call request to obtain a verification result; the digital signature is generated by the cloud based on the single service call request.

[0014] If the verification result is correct, the service call request is executed.

[0015] Optionally, before establishing an encrypted tunnel between the vehicle and the cloud, the method further includes:

[0016] The vehicle-side component encapsulates the vehicle functions as services.

[0017] When the service is enabled, the vehicle obtains the public and private keys from the vehicle's hardware security module or security element for the service.

[0018] The vehicle-mounted device encrypts the device certificate based on the public key and the private key.

[0019] Optionally, the cloud generates the digital signature based on the single service call request, including:

[0020] The cloud generates the digital signature based on the private key and a single service call request; the private key comes from the vehicle's hardware security module or security element.

[0021] Optionally, before negotiating the session key between the cloud and the vehicle through the encrypted tunnel, the method further includes:

[0022] The cloud receives the service call request from the user;

[0023] The cloud verifies the time, geographical location, and user permissions of the service call request, and obtains a verification result; the verification result indicates that the service call request is allowed.

[0024] Optionally, after the service call request is executed on the vehicle side using the session key to decrypt the request, the method further includes:

[0025] The vehicle-side device encrypts the execution result of the service call request using the session key to obtain the returned data;

[0026] The vehicle sends the returned data to the cloud through the secure tunnel;

[0027] After receiving the returned data, the cloud decrypts it using the session key and records the process of executing the service call request.

[0028] Based on the above-mentioned vehicle-cloud collaboration method, this application also discloses a vehicle-cloud collaboration device, including: an establishment unit, a negotiation unit, and a distribution unit;

[0029] The establishment unit is used to establish an encrypted tunnel between the vehicle and the cloud.

[0030] The negotiation unit is used to negotiate the session key between the cloud and the vehicle through the encrypted tunnel to obtain a session key corresponding to a single service call request; the service call request is used to call the encapsulated vehicle function.

[0031] The sending unit is used to encrypt the service call request using the session key, and then send the request between the cloud and the vehicle through the encrypted tunnel, so that the vehicle can execute the service call request after decrypting it using the session key.

[0032] Optionally, the establishment unit includes:

[0033] A subunit is established for the vehicle-side to establish the encrypted tunnel based on the device certificate, public key, and private key; the device certificate is obtained by the vehicle-side from the cloud for the vehicle functions.

[0034] Optionally, the sending unit includes:

[0035] The decryption subunit is used by the vehicle-side to decrypt the service call request using the session key;

[0036] The verification subunit is used by the vehicle to verify the digital signature corresponding to the service call request and obtain the verification result; the digital signature is generated by the cloud based on the single service call request.

[0037] An execution subunit is used to execute the service call request if the verification result is correct.

[0038] Optionally, the device further includes:

[0039] An encapsulation unit is used by the vehicle to encapsulate the vehicle functions into services.

[0040] An activation unit is used to, when the service is enabled, obtain a public key and a private key from the hardware security module or security element of the vehicle for the service.

[0041] The acquisition unit is used by the vehicle terminal to encrypt the device certificate based on the public key and the private key.

[0042] Optionally, the verification subunit includes:

[0043] A generation subunit is used by the cloud to generate the digital signature based on the private key and a single service call request; the private key comes from the hardware security module or security element of the vehicle.

[0044] Optionally, the device further includes:

[0045] The receiving unit is used to receive the service call request from the user in the cloud.

[0046] The verification unit is used by the cloud to verify the time, geographical location, and user permissions of the service call request, and obtain a verification result; the verification result indicates that the service call request is allowed.

[0047] Optionally, the device further includes:

[0048] An encryption unit is used by the vehicle to encrypt the execution result of the service call request using the session key to obtain the returned data;

[0049] A return unit is used by the vehicle to send the returned data to the cloud through the secure tunnel;

[0050] The recording unit is used to decrypt the returned data through the session key after the cloud receives it, and to record the process of executing the service call request.

[0051] Based on the above-mentioned vehicle-cloud collaboration method, this application also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-mentioned method.

[0052] Based on the above-mentioned vehicle-cloud collaboration method, this application also discloses a vehicle, including: a processor, a memory, and a system bus;

[0053] The processor and the memory are connected via the system bus;

[0054] The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform the steps of the method described above.

[0055] This application discloses a method, apparatus, and related products for vehicle-cloud collaboration. An encrypted tunnel is established between the vehicle and the cloud. Before each service call, a session key is negotiated between the cloud and the vehicle through the encrypted tunnel to obtain a session key corresponding to a single service call request. A dynamic negotiation method limits the key's validity to a single call, avoiding the risk of long-term key leakage. Even if the session key is cracked at some point, its short validity period has a limited impact on the overall system security. The service call request is encrypted using the session key and then sent between the cloud and the vehicle through the encrypted tunnel. The vehicle then decrypts the request using the session key and executes the service call, invoking the encapsulated vehicle functions. A two-layer encryption system (transport layer and service layer) is built on the vehicle-cloud SOA architecture. The outer layer establishes vehicle-cloud link encryption based on the encrypted tunnel to ensure transmission security, while the inner layer performs end-to-end encryption of the service request at the service call level based on the session key. The two encryption mechanisms are independent of each other, achieving defense in depth. Even if the outer encryption is cracked, the inner encryption can still ensure data security, providing a high level of security for vehicle-cloud collaboration. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0057] Figure 1 This is a flowchart illustrating a vehicle-cloud collaboration method disclosed in an embodiment of this application;

[0058] Figure 2a This is a flowchart illustrating another vehicle-cloud collaboration method disclosed in an embodiment of this application;

[0059] Figure 2b This is a timing diagram of the vehicle-cloud collaboration disclosed in the embodiments of this application;

[0060] Figure 3 This is a schematic diagram of the structure of a vehicle-cloud collaborative device disclosed in an embodiment of this application. Detailed Implementation

[0061] This application's embodiments can be specifically applied to SOA communication between the vehicle and the cloud. SOA communication powerfully supports cross-domain collaborative work, such as enabling the linkage between autonomous driving and smart cockpits. Simultaneously, it supports the dynamic deployment of Over-the-Air (OTA) technology and the access of third-party ecosystems, greatly expanding the functional boundaries and application scenarios of vehicles.

[0062] Current SOA vehicle-cloud collaboration solutions have many serious security risks, which are as follows:

[0063] Service exposure risk: Vehicle services are exposed through IP-based Scalable Service-Oriented Middleware over IP (SOME / IP) or data-centric middleware DDS (Data Distribution Service). This makes the services encapsulated by vehicle functions vulnerable to malicious scanning and unauthorized invocation, posing a potential threat to vehicle security.

[0064] Lack of identity and permission management: During service calls, the lack of fine-grained authentication and authorization mechanisms makes it impossible to accurately identify and control the identity and permissions of the caller, resulting in significant security risks in service calls.

[0065] Vulnerable communication links: Communication between the vehicle and the cloud mostly uses the standard Transport Layer Security (TLS) protocol. This protocol lacks vehicle-level identity binding mechanisms and anti-replay mechanisms, making the communication links vulnerable to attacks and making it difficult to guarantee data transmission security.

[0066] Lack of a trusted execution environment: For sensitive services, such as remote vehicle control, running on a regular operating system is vulnerable to attacks due to the numerous security vulnerabilities inherent in such systems, which in turn affect the secure operation of these sensitive services.

[0067] Static policies: Current security policies, such as access control policies, are often fixed and cannot be dynamically adjusted according to the actual state of the vehicle. This makes it difficult to adapt to the complex and ever-changing vehicle operating environment and reduces the effectiveness of security protection.

[0068] Given the aforementioned problems, there is an urgent need for a vehicle-cloud collaborative solution that can deeply integrate SOA architecture with a defense-in-depth security system. Therefore, the two core objectives of this application are as follows:

[0069] Firstly, a highly secure vehicle-cloud collaborative system and method based on SOA is provided. Through service gateway proxy, two-way identity authentication, dynamic access control policies, Trusted Execution Environment (TEE) protection of critical services, and security audit logs, an end-to-end secure communication closed loop from the vehicle to the cloud is constructed to comprehensively ensure the authenticity, integrity, confidentiality and traceability of service calls.

[0070] Secondly, it provides a highly secure vehicle-cloud collaboration solution based on SOA. By constructing a comprehensive security system of "service-level authentication + dynamic key negotiation + hardware secure storage + anti-replay verification", it effectively solves the security problems such as identity forgery, data leakage, unauthorized access and replay attacks faced in the process of vehicle-cloud service invocation in existing technologies, and provides a solid and reliable security guarantee for vehicle-cloud collaboration.

[0071] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0072] Example 1: This application discloses a method for vehicle-cloud collaboration.

[0073] For details, please refer to Figure 1 The vehicle-cloud collaboration method disclosed in this embodiment includes the following steps:

[0074] Step 101: Establish an encrypted tunnel between the vehicle and the cloud.

[0075] The method in this embodiment is based on a comprehensive architecture including a vehicle-side system, a communication network, and a cloud system. As one feasible solution, the vehicle-side system includes a service-oriented functional module, an in-vehicle security middleware, and an in-vehicle communication module. Specifically, the service-oriented functional module encapsulates vehicle functions into standardized services through multiple domain controllers, which may include vehicle control services, status awareness services, and user interaction services. The in-vehicle security middleware integrates the SOME / IP protocol stack and a security proxy, supporting secure encapsulation of service registration, service discovery, and service invocation. The in-vehicle communication module supports 5G or C-V2X communication, and its built-in Hardware Security Module (HSM) or Secure Element (SE) is used to store root certificates, private keys, and perform encryption operations.

[0076] As a feasible solution, the communication network includes a two-layer encrypted tunnel module and a dynamic key negotiation module. Specifically, the two-layer encrypted tunnel module comprises an outer tunnel and an inner tunnel. The outer tunnel establishes a transport layer encrypted channel between the vehicle and the cloud based on Internet Protocol Security (IPSec) or TLS 1.3. The inner tunnel, at the service call level, employs end-to-end encryption based on the elliptic curve public key cryptography algorithm SM2 or the block cipher algorithm SM4 developed by the State Cryptography Administration of China, along with a hybrid encryption algorithm combining asymmetric and symmetric encryption, ECC-AES, to perform secondary encryption on the service request and response payloads. The dynamic key negotiation module allows the vehicle and the cloud to negotiate a session key before service calls, based on a pre-shared key (PSK) or certificate chain, via the Elliptic Curve Diffie-Hellman Key Exchange (ECDH) protocol. The validity period of this session key is set to a single call or a fixed time window.

[0077] As a feasible solution, the cloud system includes a secure communication gateway, a service permission policy center, a cloud service cluster, and a security audit module. Specifically, the secure communication gateway includes an Application Programming Interface (API) gateway, a Message Queuing Telemetry Transport Broker (MQTT Broker), and a service routing module. This cloud system has a built-in service authentication engine used to verify the digital signature and access permissions of vehicle-side service call requests. The service permission policy center stores service-level access control policies (ACLs), defining "which vehicle-side services can call which cloud services" and "which cloud services can call vehicle-side services in return," supporting dynamic authorization based on roles, time windows, and geofences. The cloud service cluster is used to deploy OTA services, remote diagnostic services, and artificial intelligence model services. It is important to note that all service calls must be authenticated through the permission policy center. The security audit module supports logging all service calls, including caller identity, service name, parameters, timestamps, and authentication results, for security traceability.

[0078] In this embodiment, the vehicle first encapsulates each vehicle function as a service. For example, the intelligent driving domain controller on the vehicle encapsulates the "autonomous driving mode switching" function as the Vehicle.ControlService::SetAutonomousMode service. Subsequently, the vehicle registers this service in its local service directory through the SOME / IP-based service discovery mechanism (Scalableservice-Oriented Middleware over IP - Service Discovery, SOME / IP-SD) in the automotive field.

[0079] In this embodiment, before or during the activation of a service, the vehicle can apply for a device certificate from the cloud to prove the vehicle's trustworthiness. Subsequently, upon service activation, the vehicle can retrieve the public and private keys stored in the HSM for the service, and then encrypt the service using these keys, specifically by digitally signing the service with the private key. After encryption, the vehicle sends the device certificate, the service information, the public key, and the digital signature containing the hidden private key to the cloud secure communication gateway.

[0080] As a feasible solution, taking the "autonomous driving mode switching" function as an example, the in-vehicle security middleware can generate a digital signature through the following:

[0081] "service":"Vehicle.ControlService","method":"SetAutonomousMode","pub_key":"0xABCDEF...","signature":"0x123456...".

[0082] In this embodiment, the cloud-based secure communication gateway verifies the trustworthiness of the device certificate and its digital signature. Upon successful verification, it returns information indicating successful service registration to the vehicle. Subsequently, the vehicle begins establishing an encrypted tunnel with the cloud based on the device certificate, public key, and private key. Specifically, this can be done using the TLS 1.3 protocol, whereby the cloud verifies the device certificate again, completes the TLS handshake, and establishes the encrypted tunnel.

[0083] Step 102: Negotiate the session key between the cloud and the vehicle through the encrypted tunnel to obtain the session key corresponding to a single service call request.

[0084] In the method of this embodiment, the cloud service cluster can receive service call requests from users, which may include an anti-replay field with timestamps and random numbers, used to verify the validity of the service call request in the cloud and avoid duplicate or expired requests.

[0085] As a feasible solution, upon receiving a service call request, the cloud can first verify the time, geographical location, and user permissions of the request to determine whether the service call request is allowed. If the service call request is not allowed, it is ignored or a message indicating that the request is not allowed is returned to the user. If the service call request is allowed, a session key is negotiated with the vehicle through an established encrypted tunnel.

[0086] Specifically, a session key negotiation request containing "service":"Vehicle.ControlService", "method":"SetParkingMode","params":{"type":"remote"},"timestamp":"20250903100000","nonce":"a1b2c3d4","signature":"sig_with_session_key" can be constructed and sent to the vehicle.

[0087] In the method of this embodiment, the vehicle responds to the session key negotiation request, generates a digital signature for this service call based on the private key, and negotiates with the cloud to obtain the session key for this service call.

[0088] Step 103: After encrypting the service call request using the session key, the request is sent between the cloud and the vehicle through the encrypted tunnel, so that the service call request can be executed on the vehicle after being decrypted using the session key.

[0089] In this embodiment, the cloud encrypts the service call request using a private key (i.e., digitally signs it), then encrypts it again using a negotiated session key, and finally sends it to the vehicle through an established encrypted tunnel. The vehicle then decrypts the request using the session key to obtain the service call request. Subsequently, the vehicle verifies the digital signature corresponding to the service call request, as well as the validity of the timestamp and random number. If the verification results are correct, the vehicle executes the service call request.

[0090] In this embodiment, as an feasible solution, after the vehicle executes the service call request, the execution process, execution result, and other information can be encrypted again using a session key to obtain the returned data. Subsequently, the returned data is sent to the cloud through a secure tunnel, so that the cloud can receive the returned data, decrypt it using the session key, and record the information of this service call request.

[0091] The method described in this embodiment employs a dual-layer encryption communication mechanism of transport layer encrypted tunnel and service call layer session key to enhance data confidentiality. Service requests include timestamps and random numbers, effectively defending against replay attacks and ensuring the timeliness and uniqueness of service calls. A dynamic key negotiation and storage system based on HSM / SE is constructed. The vehicle and cloud negotiate session keys before each service call, and the root key and private key are stored in the HSM / SE, achieving hardware-level protection to prevent software-layer theft and improve key security. Session keys are limited to single calls or short time windows to avoid the risk of long-term key leakage and achieve call-level security isolation. Fine-grained service authentication is supported; each service call carries a digital signature to verify call permissions. Dynamic authorization based on roles, time windows, and geofences is supported, implementing the principle of least privilege to prevent unauthorized service access and unauthorized operations. Simultaneously, complete service call logs are recorded to meet functional safety and information security compliance requirements, facilitating auditing and tracing of service call behavior.

[0092] Example 2: This application discloses another method for vehicle-cloud collaboration; please refer to [link / reference]. Figure 2a This embodiment describes the process of calling vehicle functions from the cloud.

[0093] Step 201: The vehicle end encapsulates the vehicle functions into services, obtains the device certificate corresponding to the service, and enables the service.

[0094] Step 202: The vehicle-side HSM generates a public key and a private key, and uses the public key and private key to encrypt the device certificate.

[0095] Step 203: The vehicle sends the encrypted device certificate to the cloud for verification.

[0096] Step 204: After the cloud verifies the device certificate, an encrypted tunnel is established with the vehicle.

[0097] Step 205: The cloud receives the service call request and verifies the user's permissions, time, and geographical location.

[0098] Step 206: After the verification is successful, the cloud negotiates the session key with the vehicle through an encrypted tunnel for this service call request.

[0099] Step 207: After obtaining the session key, the cloud uses the session key to encrypt the service call request and obtain the encrypted packet.

[0100] Step 208: The cloud sends the encrypted packet to the vehicle through an encrypted tunnel.

[0101] Step 209: The vehicle terminal decrypts the encrypted packet using the session key and verifies the received service call request.

[0102] Step 210: After the vehicle verifies the service call request, it executes the service call request.

[0103] Step 211: The vehicle encrypts the execution information of the service call request using the session key to obtain the returned information.

[0104] Step 212: The vehicle sends the returned information to the cloud through an encrypted tunnel.

[0105] Step 213: Decrypt the returned information using the session key in the cloud to obtain execution information for recording in the audit log.

[0106] In the method of this embodiment, the data communication timing diagram between the vehicle and the cloud is as follows: Figure 2b As shown, Figure 2b The vehicle and HSM belong to the vehicle-side system, while the cloud-based security communication gateway, service permission policy center, cloud service cluster, and security audit module belong to the cloud-based system.

[0107] The vehicle first sends service startup information a1 to the HSM. At this point, the vehicle function has been encapsulated as a service, and the vehicle has obtained the device certificate for that service. The HSM responds to a1, retrieving the public and private keys k1 stored in the hardware. The vehicle then uses k1 to encrypt the device certificate, with the private key used to generate a digital signature.

[0108] The vehicle sends the encrypted device certificate a2 to the cloud-based secure communication gateway. The cloud-based secure communication gateway verifies the device certificate and digital signature of a2. If the verification is successful, it replies with a service registration success message b1 to the vehicle. The vehicle responds to b1 by sending an encrypted tunnel establishment request a3 to the cloud-based secure communication gateway. The cloud-based secure communication gateway verifies the device certificate again, and if the verification is successful, it establishes the encrypted tunnel.

[0109] The cloud service cluster sends service call request b2 to the cloud service permission policy center. The service permission policy center verifies b2 for user permissions, time, and geographical location. After successful verification, it returns an approved call message b3 to the cloud service cluster. The cloud service cluster responds to b3 by sending a session key exchange request b4 to the cloud secure communication gateway. The cloud secure communication gateway negotiates with the HSM through an encrypted tunnel and generates a session key k2.

[0110] The cloud uses k2 to encrypt b2 to obtain b5, which is then sent to the vehicle through an encrypted tunnel. The vehicle decrypts b5, verifies its timestamp, random number, and digital signature. If the verification is successful, it executes the service call request in b5, obtaining execution information a4. Following the same steps, a4 is encrypted and sent to the cloud secure communication gateway through the encrypted tunnel. The cloud secure communication gateway decrypts and verifies a4, then returns the execution result to the cloud service cluster based on a4, and sends the execution information to the security audit module for recording in the audit log.

[0111] Based on the vehicle-to-cloud collaboration method disclosed in the above embodiments, this embodiment correspondingly discloses a vehicle-to-cloud collaboration device. Please refer to... Figure 3 The vehicle-cloud collaborative device includes: an establishment unit 301, a negotiation unit 302, and a distribution unit 303;

[0112] The establishment unit 301 is used to establish an encrypted tunnel between the vehicle and the cloud.

[0113] The negotiation unit 302 is used to negotiate the session key between the cloud and the vehicle through the encrypted tunnel to obtain a session key corresponding to a single service call request; the service call request is used to call the encapsulated vehicle function.

[0114] The sending unit 303 is used to encrypt the service call request using the session key, and then send the request between the cloud and the vehicle through the encrypted tunnel, so that the vehicle can execute the service call request after decrypting it using the session key.

[0115] Optionally, the establishment unit 301 includes:

[0116] A subunit is established for the vehicle-side to establish the encrypted tunnel based on the device certificate, public key, and private key; the device certificate is obtained by the vehicle-side from the cloud for the vehicle functions.

[0117] Optionally, the sending unit 303 includes:

[0118] The decryption subunit is used by the vehicle-side to decrypt the service call request using the session key;

[0119] The verification subunit is used by the vehicle to verify the digital signature corresponding to the service call request and obtain the verification result; the digital signature is generated by the cloud based on the single service call request.

[0120] An execution subunit is used to execute the service call request if the verification result is correct.

[0121] Optionally, the device further includes:

[0122] An encapsulation unit is used by the vehicle to encapsulate the vehicle functions into services.

[0123] An activation unit is used to, when the service is enabled, obtain a public key and a private key from the hardware security module or security element of the vehicle for the service.

[0124] The acquisition unit is used by the vehicle terminal to encrypt the device certificate based on the public key and the private key.

[0125] Optionally, the verification subunit includes:

[0126] A generation subunit is used by the cloud to generate the digital signature based on the private key and a single service call request; the private key comes from the hardware security module or security element of the vehicle.

[0127] Optionally, the device further includes:

[0128] The receiving unit is used to receive the service call request from the user in the cloud.

[0129] The verification unit is used by the cloud to verify the time, geographical location, and user permissions of the service call request, and obtain a verification result; the verification result indicates that the service call request is allowed.

[0130] Optionally, the device further includes:

[0131] An encryption unit is used by the vehicle to encrypt the execution result of the service call request using the session key to obtain the returned data;

[0132] A return unit is used by the vehicle to send the returned data to the cloud through the secure tunnel;

[0133] The recording unit is used to decrypt the returned data through the session key after the cloud receives it, and to record the process of executing the service call request.

[0134] Based on the above-mentioned vehicle-cloud collaboration method, this application also discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-mentioned method.

[0135] Based on the above-mentioned vehicle-cloud collaboration method, this application also discloses a vehicle, including: a processor, a memory, and a system bus;

[0136] The processor and the memory are connected via the system bus;

[0137] The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform the steps of the method described above.

[0138] The embodiments in this specification are described in a progressive manner. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant details can be found in the method section.

[0139] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0140] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0141] The features described in the embodiments of this specification can be substituted for or combined with each other, so that those skilled in the art can implement or use this application.

[0142] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for vehicle-cloud collaboration, characterized in that, include: Establish an encrypted tunnel between the vehicle and the cloud; The session key between the cloud and the vehicle is negotiated through the encrypted tunnel to obtain a session key corresponding to a single service call request; The service call request is used to invoke the encapsulated vehicle functions; After encrypting the service call request using the session key, the request is sent between the cloud and the vehicle through the encrypted tunnel, so that the service call request can be executed on the vehicle after being decrypted using the session key.

2. The method according to claim 1, characterized in that, The establishment of an encrypted tunnel between the vehicle and the cloud includes: The vehicle-mounted device establishes the encrypted tunnel based on a device certificate, a public key, and a private key; the device certificate is obtained by the vehicle-mounted device from the cloud for the vehicle's functions.

3. The method according to claim 1, characterized in that, The step of executing the service call request on the vehicle side after decryption using the session key includes: The vehicle uses the session key to decrypt and obtain the service call request; The vehicle verifies the digital signature corresponding to the service call request to obtain a verification result; the digital signature is generated by the cloud based on the single service call request. If the verification result is correct, the service call request is executed.

4. The method according to claim 2, characterized in that, Before establishing an encrypted tunnel between the vehicle and the cloud, the method further includes: The vehicle-side component encapsulates the vehicle functions as services. When the service is enabled, the vehicle obtains the public and private keys from the vehicle's hardware security module or security element for the service. The vehicle-mounted device encrypts the device certificate based on the public key and the private key.

5. The method according to claim 3, characterized in that, The cloud generates the digital signature based on the single service call request, including: The cloud generates the digital signature based on the private key and a single service call request; the private key comes from the vehicle's hardware security module or security element.

6. The method according to any one of claims 1-5, characterized in that, Before negotiating the session key between the cloud and the vehicle through the encrypted tunnel, the method further includes: The cloud receives the service call request from the user; The cloud verifies the time, geographical location, and user permissions of the service call request, and obtains a verification result; the verification result indicates that the service call request is allowed.

7. The method according to any one of claims 1-5, characterized in that, After the service call request is executed on the vehicle side using the session key for decryption, the method further includes: The vehicle-side device encrypts the execution result of the service call request using the session key to obtain the returned data; The vehicle sends the returned data to the cloud through the secure tunnel; After receiving the returned data, the cloud decrypts it using the session key and records the process of executing the service call request.

8. A vehicle-cloud collaborative device, characterized in that, include: Establishing units, negotiating units, and issuing units; The establishment unit is used to establish an encrypted tunnel between the vehicle and the cloud. The negotiation unit is used to negotiate the session key between the cloud and the vehicle through the encrypted tunnel to obtain the session key corresponding to a single service call request; The service call request is used to invoke the encapsulated vehicle functions; The sending unit is used to encrypt the service call request using the session key, and then send the request between the cloud and the vehicle through the encrypted tunnel, so that the vehicle can execute the service call request after decrypting it using the session key.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-7.

10. A vehicle, characterized in that, include: Processor, memory, system bus; The processor and the memory are connected via the system bus; The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform the steps of the method according to any one of claims 1-7.

Images