Digital key management method and device

Abstract

The invention provides a digital key management method and device, and the method comprises the steps: receiving a digital key activation request initiated by friend equipment after a target vehicle deletes a public key of vehicle owner equipment; obtaining a first public key certificate of the friend equipment according to the digital key activation request, and sending the first public key certificate to a cloud server; and receiving a signature verification result of the first public key certificate sent by the cloud server, and authorizing the friend equipment to be activated under the condition that the signature verification result has the activation permission. Under the situation that the public key of the vehicle owner equipment is deleted from the target vehicle, the cloud server uses the second public key certificate corresponding to the vehicle owner digital key to verify the first public key certificate of the friend equipment, so that only the legal and trusted friend equipment can initiate an activation request; and illegal equipment is effectively prevented from pretending friend equipment to obtain the digital key permission. And whether to authorize to activate the friend equipment is determined based on the signature verification result, so that refined authority management is realized.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a digital key management method and device. Background Technology

[0002] With the rapid development of intelligent connected vehicles, digital key technology has become an important medium connecting car owners and their vehicles. Digital key technology involves interaction between people, vehicles, and the cloud to manage the lifecycle of digital keys, including sharing, activation, and deletion. Any vulnerability in any link of the interaction process could lead to privacy leaks or vehicle theft.

[0003] It should be noted that the above introduction to the technical background is only for the purpose of providing a clear and complete explanation of the technical solutions of this application and facilitating understanding by those skilled in the art. It should not be assumed that these technical solutions are known to those skilled in the art simply because they have been described in the background section of this application. Summary of the Invention

[0004] The purpose of this application is to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this application is to propose two digital key management methods.

[0006] The second objective of this application is to propose two digital key management devices.

[0007] The third objective of this application is to propose an electronic device.

[0008] The fourth objective of this application is to provide a non-transitory computer-readable storage medium.

[0009] The fifth objective of this application is to provide a computer program product.

[0010] To achieve the above objectives, a first aspect of this application provides a digital key management method, comprising: After the target vehicle has deleted the owner's device public key, receive a digital key activation request initiated by a friend's device; The first public key certificate of the friend's device is obtained according to the digital key activation request, and the first public key certificate is sent to the cloud server. The second public key certificate corresponding to the car owner's digital key stored in the cloud server verifies the signature of the first public key certificate. The system receives the verification result of the first public key certificate sent by the cloud server, and authorizes the activation of the friend's device if the verification result has activation permission.

[0011] To achieve the above objectives, a second aspect of this application provides a digital key management method, comprising: After the target vehicle has deleted the owner's device public key, the system receives the first public key certificate sent by the friend's device. The first public key certificate is obtained from the digital key activation request initiated by the friend's device. The signature of the first public key certificate is verified by the second public key certificate in the stored signature-only state to obtain the verification result, and the verification result is sent to the friend's device. The second public key certificate corresponds to the vehicle owner's digital key.

[0012] To achieve the above objectives, a third aspect of this application provides a digital key management device, comprising: The first receiving module is used to receive a digital key activation request initiated by a friend's device after the owner's device public key has been deleted from the target vehicle. The sending module is used to obtain the first public key certificate of the friend's device according to the digital key activation request, and send the first public key certificate to the cloud server, wherein the second public key certificate corresponding to the car owner's digital key stored in the cloud server verifies the signature of the first public key certificate. The first activation module is used to receive the verification result of the first public key certificate sent by the cloud server, and authorize the activation of the friend's device if the verification result has activation permission.

[0013] To achieve the above objectives, a fourth aspect of this application provides a digital key management device, comprising: The second receiving module is used to receive a first public key certificate sent by a friend's device after the target vehicle has deleted the owner's device public key. The first public key certificate is obtained by a digital key activation request initiated by the friend's device. The second activation module is used to verify the signature of the first public key certificate using the second public key certificate in the stored signature-only state, obtain the verification result, and send the verification result to the friend's device, wherein the second public key certificate corresponds to the car owner's digital key.

[0014] To achieve the above objectives, a fifth aspect of this application provides an electronic device, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the digital key management method proposed in the first or second aspect of this application.

[0015] To achieve the above objectives, a sixth aspect of this application provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the digital key management method proposed in the first or second aspect of the embodiment.

[0016] To achieve the above objectives, a seventh aspect of this application provides a computer program product, including a computer program that, when executed by a processor in a communication device, implements the digital key management method proposed in the first or second aspect of this application.

[0017] In this embodiment, when the owner's device public key has been deleted from the target vehicle, the cloud server verifies the first public key certificate of the friend's device using the second public key certificate corresponding to the owner's digital key. This ensures that only legitimate and trusted friend devices can initiate activation requests, effectively preventing unauthorized devices from impersonating friend devices to obtain digital key permissions. This significantly enhances system security and protects the vehicle and related digital assets from unauthorized access. Determining whether to authorize activation of the friend's device based on the verification result achieves fine-grained permission management. Activation is only performed when the verification result indicates the friend's device has activation permissions, ensuring that digital key allocation strictly follows preset permission rules and avoiding permission abuse and misallocation.

[0018] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0019] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A schematic diagram illustrating a digital key sharing process provided in an embodiment of this application; Figure 2 A flowchart illustrating a digital key management method provided in an embodiment of this application; Figure 3 A flowchart illustrating another digital key management method provided in an embodiment of this application; Figure 4 A flowchart illustrating another digital key management method provided in an embodiment of this application; Figure 5 This is a schematic diagram of a digital key activation process according to an embodiment of this application; Figure 6 A flowchart illustrating another digital key management method provided in an embodiment of this application; Figure 7 This is a schematic diagram of a second public key certificate management strategy provided according to an embodiment of this application; Figure 8a A schematic diagram of the structure of a digital key management device provided in this application embodiment; Figure 8b A schematic diagram of another digital key management device provided in this application embodiment; Figure 9 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0021] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the embodiments of this application. The singular forms “a” and “the” as used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used to describe various information in the embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words "if" and "suppose" as used herein can be interpreted as "when," "when," or "in response to a determination."

[0023] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] With the rise of intelligent technology in the automotive industry, digital key functionality has become widely adopted. It not only eliminates the constraints of traditional physical keys, freeing car owners from the hassle of forgetting or losing their keys, but also offers users a more convenient experience through diverse unlocking methods, such as Bluetooth unlocking via mobile phone and NFC (Near Field Communication) sensor unlocking.

[0025] To further explore the potential value of digital keys and expand their application scope, allowing car owners to share access to their digital keys with friends through specific means and authorize friends' devices to use the car has become a common and practical way to expand the functionality of digital keys. This sharing function is extremely convenient in social scenarios.

[0026] Figure 1 This is a schematic diagram illustrating a digital key sharing process provided in an embodiment of this application. Figure 1 As shown, the vehicle owner's device requests an information exchange space (which can be called a "cloud mailbox") from the relay server (a network node located between the target vehicle, the vehicle owner's device, the friend's device, and the cloud server. Its core function is to provide secure and efficient data relay and interaction support between devices. It does not directly store or process data, but acts as a "middleman" to forward requests and responses). The relay server is used to upload some business information and generate a URL (Uniform Resource Locator) pointing to the information exchange space. Optionally, the URL includes the "cloud mailbox" address.

[0027] The car owner can send (share) the URL to a friend's device via their own device using a relevant communication method (such as SMS, social media, etc.).

[0028] After receiving the URL, the friend device accesses the relay server and retrieves the business information uploaded by the car owner (such as the expiration date and permissions of the digital key shared by the car owner). The friend device can generate a public-private key pair and push the friend device's public key to the relay server.

[0029] The relay server can send a pull notification to the vehicle owner's device. Based on this notification, the vehicle owner's device accesses the relay server, retrieves the friend's device's public key, and signs it using the vehicle owner's private key, generating a public key certificate (E), or simply certificate (E). Simultaneously, the target vehicle also includes a public key certificate (B), or simply certificate (B). The vehicle owner's device can push both certificate (E) and certificate (B) to the relay server.

[0030] The relay server can send a pull notification to a friend's device. Based on this notification, the friend's device pulls the certificate (E) signed by the vehicle owner's device's private key and the target vehicle's certificate (B) from the relay server. Therefore, when the friend's device approaches the target vehicle, it can send the certificate (E) and certificate (B) to the target vehicle. The target vehicle can verify the certificate (E) using the vehicle owner's device's public key and accept the friend's device's public key after successful verification.

[0031] After the digital key sharing process of the car owner's device is completed, the friend's device can report the friend's device public key certificate (E) to the cloud server (which can be provided by the car manufacturer's application or by the friend's device manufacturer) by establishing a network link (which can be provided by the car manufacturer or a third party).

[0032] After receiving the certificate (E), the cloud server maintains the certificate (E), including: checking the validity period of the certificate (E), verifying the signature of the certificate (E) to ensure its authenticity and legality, and checking whether the subject information of the certificate (E) (such as the identifier of the friend's device, user information, etc.) is consistent with expectations.

[0033] If the certificate (E) is verified, the cloud server will store the friend's device public key certificate (E) in a secure database for subsequent verification and management of the friend's device identity. Simultaneously, relevant information about the friend's device public key certificate (E), such as the reporting time and device identifier, will be recorded for auditing and tracking purposes.

[0034] It should be noted that some abnormal situations may occur during the above process, and appropriate handling will be carried out accordingly. If the friend's device encounters network connection problems during network link selection or data transmission, the friend's device will attempt to reconnect to the network. After a certain number of failures (e.g., 3 times), it will prompt the user to check the network settings or try again later. If the cloud server encounters an error when decrypting data packets, it may be due to key mismatch or data corruption. The cloud server will send an error notification to the friend's device and prompt the friend's device to resubmit the certificate (E). If the cloud server fails to verify the certificate (E), it will record the reason for the failure and send a verification failure notification to the friend's device. The friend's device will then check whether the certificate (E) is correct or regenerate and resubmit the certificate based on this notification.

[0035] In some application scenarios, the digital key sharing process typically includes two steps: The first step is for the car owner's digital key to authorize (i.e., "share") the friend's digital key, and to ensure that only authorized friends can access the car owner's digital key information.

[0036] The second step involves the target vehicle authenticating the key and certificate carried by the friend's digital key lock. When the friend attempts to unlock or start the target vehicle using the friend's digital key, the vehicle's built-in security system initiates an authentication process. This process compares the key and certificate uploaded by the friend's device with the information stored internally in the target vehicle, checking the certificate's validity period, signature, and other information to ensure its authenticity and legitimacy. Only after successful verification can the friend's digital key subsequently be used normally on the target vehicle; this process is called "activation." Only after activation is complete can the friend truly gain operating rights to the target vehicle.

[0037] It's important to note that the first step, "sharing," and the second step, "activation," are usually not simultaneous; there's a time interval between them, resulting in an asynchronous and discontinuous process. This asynchronicity can cause problems, such as the friend's device failing to receive authorization information in a timely manner when the network is unstable, or delays in the activation process preventing the friend from unlocking the vehicle when needed.

[0038] When this time lag occurs, a potential risk arises: if the vehicle owner deletes the owner's digital key during this period, meaning the vehicle system deletes the owner's device's public key, then the unactivated friend's digital key will be in trouble. This is because activating the friend's digital key requires the owner's device's public key to verify and authorize the friend's public key certificate (E), confirming the friend's device's legitimacy and permissions. Once the owner's device's public key is deleted, the target vehicle loses its verification and authorization basis, and the unactivated friend's digital key cannot complete the activation process, thus becoming unusable.

[0039] However, the situation is different for a friend's digital key that has already been activated. Since the target vehicle has successfully trusted the friend's device's public key certificate (E) during the activation phase and stored the relevant information in the system, even if the owner subsequently deletes the owner's digital key, the activated friend's digital key can still continue to use the target vehicle normally based on the previously stored trust information.

[0040] From the user's perspective, this discrepancy can lead to situations where "when a car owner deletes their digital key, some users' digital keys can be used normally, while others cannot be activated." This inconsistency increases the learning curve for users of the digital key sharing function, requiring them to spend more time understanding and memorizing the usage rules under different conditions. This significantly diminishes the overall experience and hinders the promotion of the digital key sharing function and the improvement of user satisfaction.

[0041] Therefore, effectively shortening the asynchronous time difference in the digital key sharing process and avoiding poor experiences such as interruption of the sharing process has become the key for car companies to optimize the overall user experience of digital keys.

[0042] The digital key management method and apparatus of this application are described below with reference to the accompanying drawings.

[0043] Figure 2 This is a flowchart illustrating a digital key management method provided in an embodiment of this application. The method is applicable to scenarios such as temporary vehicle use, ride-sharing, and valet services. For example, temporary vehicle use scenarios include: a car owner lending their vehicle to a friend for short-term use (such as weekend outings or running errands). Ride-sharing scenarios include: a friend temporarily accessing the vehicle as a passenger. Valet service scenarios include: a car owner handing over their vehicle to a third-party service provider (such as a mechanic or car wash worker).

[0044] like Figure 2 As shown, the digital key management method includes, but is not limited to, the following steps: S201: After the target vehicle's owner's device public key has been deleted, receive a digital key activation request initiated by a friend's device.

[0045] In one feasible implementation, when the target vehicle completes the critical event of deleting the owner's device public key and then receives a friend's digital key request from a friend's device, the entire system (referring to the digital key management system, which typically consists of a vehicle-side digital key management module, a cloud service platform, and a mobile device (owner / friend) digital key application module) establishes a rigorous processing mechanism to ensure the security of the target vehicle, protect the owner's rights, and optimize the user experience. In some embodiments, the system performs preliminary parsing of the basic information of the digital key activation request, including the friend's device identifier and the request time.

[0046] In one feasible implementation, the system rigorously verifies the identity of the friend's device when processing digital key activation requests. In addition to routine verification of the public key certificate uploaded by the friend's device, it also performs comprehensive verification based on other characteristics of the friend's device, such as hardware identifiers (International Mobile Equipment Identity, Media Access Control Address, etc.), operating system version, and list of installed applications. Through multi-dimensional information comparison, it ensures that the digital key activation request initiated by the friend's device is indeed from a device authorized to share the digital key, preventing malicious activation requests initiated by forged devices.

[0047] In one feasible implementation, to ensure the security of activation requests and related verification information during transmission, the system can employ high-strength encryption algorithms to encrypt the data. For example, using the TLS 1.3 protocol for communication ensures that data is not stolen or tampered with during transmission between the friend's device, the cloud server, and the target vehicle's in-vehicle terminal. Simultaneously, the system periodically updates the encryption key to further enhance data transmission security.

[0048] In one feasible implementation, when a friend's device initiates a digital key activation request, the system can send a notification message to the friend's device regardless of whether the activation is ultimately successful. If activation is successful, the system notifies the friend's device that the digital key is activated and can be used normally; if activation is rejected, the system details the reason for the rejection and provides corresponding solutions, such as contacting the vehicle owner for reauthorization.

[0049] S202: Obtain the first public key certificate of the friend's device based on the digital key activation request, and send the first public key certificate to the cloud server. The second public key certificate corresponding to the car owner's digital key stored on the cloud server verifies the signature of the first public key certificate.

[0050] In one feasible implementation, the friend device sends a digital key activation request to the target vehicle via a specific communication protocol (such as Bluetooth, NFC, or an internet-based protocol). When initiating the digital key activation request, the friend device encapsulates its own first public key certificate within the request, following a predetermined encrypted communication protocol. This first public key certificate is a crucial digital credential verifying the friend device's identity. Generated using an asymmetric encryption algorithm, it contains key data such as the friend device's public key information, unique device identifier, and the signature of the Certificate Authority (CA). This data is processed using a specific encryption algorithm to ensure the confidentiality, integrity, and non-repudiation of the certificate during transmission and storage.

[0051] In one feasible implementation, the Electronic Control Unit (ECU) of the target vehicle accurately extracts the first public key certificate when parsing the digital key activation request. Subsequently, the ECU sends this first public key certificate to a cloud server via a secure network channel. This network channel typically employs encrypted Transport Layer Security (TLS) protocol to prevent the certificate from being stolen or tampered with during transmission.

[0052] In one feasible implementation, the cloud server acts as the core security hub of the entire digital key management system, storing the second public key certificate corresponding to the vehicle owner's digital key. This second public key certificate is generated based on an asymmetric encryption mechanism and is paired with the vehicle owner's device's private key to verify the legitimacy of related operations on the vehicle owner's device. Upon receiving the first public key certificate from the target vehicle, the cloud server immediately initiates the signature verification process.

[0053] In one feasible implementation, the signature verification process is based on the mathematical principles of asymmetric encryption. The cloud server uses the public key information contained in the second public key certificate to decrypt and verify the digital signature on the first public key certificate. By comparing the hash value of the decrypted data with the original data in the certificate, the cloud server can accurately determine whether the first public key certificate was issued by a legitimate certificate authority and whether it has been tampered with during transmission. Only when the signature verification result is successful will the cloud server recognize the first public key certificate of the friend's device as legitimate and valid, providing a secure basis for subsequent digital key activation authorization.

[0054] In one feasible implementation, the cloud server returns the signature verification result to the target vehicle. If the signature verification is successful, it indicates that the friend's device's first public key certificate is legitimate, and the activation request can continue to be processed for the friend's device; if the signature verification fails, the activation request will be rejected, and a corresponding error message will be sent to the friend's device.

[0055] S203: Receive the verification result of the first public key certificate sent by the cloud server. If the verification result has activation permission, authorize the activation of the friend's device.

[0056] In one feasible implementation, after receiving the verification result data packet of the first public key certificate sent by the cloud server, the vehicle's onboard control unit unpacks the data packet layer by layer to extract key information from the verification result, such as the verification status code and permission level identifier. After parsing, the onboard control unit analyzes the verification result according to preset permission judgment logic.

[0057] In some embodiments, the vehicle control unit checks whether the signature verification status code is successful and simultaneously verifies whether the permission level identifier meets the minimum permission requirements for the friend's device's digital key activation request. Only when the signature verification status code explicitly indicates successful verification and the permission level identifier reaches or exceeds a preset activation permission threshold will the vehicle system determine that the signature verification result has activation permission.

[0058] In one feasible implementation, once the verification result confirms activation authorization, the vehicle control unit quickly enters the authorization activation phase and generates a unique activation authorization token. This token is encrypted using a high-strength encryption algorithm to prevent theft or tampering during transmission. The vehicle control unit transmits the encrypted activation authorization token to the peer device via the target vehicle's high-speed bus (such as a CAN bus or LIN bus). Upon receiving the authorization token, the peer device uses its pre-stored decryption key to decrypt the token, obtaining the activation instructions and related parameters. Based on these instructions and parameters, the peer device initializes and activates its own digital key function, enabling it to establish a secure and reliable communication connection with the target vehicle's in-vehicle system and realize various functions of the digital key, such as remote unlocking and vehicle start.

[0059] In one feasible implementation, the vehicle owner's device can also send the activation result back to the cloud server, so that the cloud server can update the relevant records and status. For example, if authorization is successful, the cloud server will record the activation status and permission information of the friend's device; if authorization fails, the cloud server will record the reason for the failure.

[0060] In summary, the digital key management method provided in this application, when the owner's device public key has been deleted from the target vehicle, verifies the first public key certificate of the friend's device using the second public key certificate corresponding to the owner's digital key via a cloud server. This ensures that only legitimate and trusted friend devices can initiate activation requests, effectively preventing unauthorized devices from impersonating friend devices to obtain digital key permissions. This significantly enhances system security and protects the vehicle and related digital assets from unauthorized access. Determining whether to authorize activation of the friend's device based on the verification result achieves fine-grained permission management. Activation is only performed when the verification result indicates that the friend's device has activation permissions, ensuring that the allocation of digital keys strictly follows preset permission rules and avoiding permission abuse and misallocation.

[0061] To further illustrate the process for processing the verification results, this application provides Figure 3 To explain, Figure 3 This is a flowchart illustrating another digital key management method provided in an embodiment of this application.

[0062] like Figure 3 As shown, the digital key management method includes, but is not limited to, the following steps: S301 receives a digital key activation request initiated by a friend's device after the owner's device public key has been deleted from the target vehicle.

[0063] In one feasible implementation, when the target vehicle performs the operation of deleting the owner device public key, the vehicle's on-board control unit will immediately update its internal security key storage database, remove the originally stored owner device public key from the list of valid keys, and mark it as deleted.

[0064] In one feasible implementation, a friend's device can initiate a digital key activation request to a target vehicle through a user interface. In some embodiments, the friend's device selects the target vehicle and submits the digital key activation request through the user interface of a car manufacturer's app or a third-party platform.

[0065] In some embodiments, a user initiates a digital key activation request on a friend's device via voice interaction. The target vehicle receives the digital key activation request through interaction between the friend's device and the target vehicle. For example, the interaction methods between the friend's device and the target vehicle include, but are not limited to, near-field communication, Bluetooth communication, and ultra-wideband communication.

[0066] In some embodiments, a user initiates a digital key activation request on a friend's device via the user interface of the vehicle manufacturer's app or a third-party platform (such as a mini-program). The target vehicle receives the digital key activation request through interaction between the friend's device and the target vehicle.

[0067] In one feasible implementation, when initiating a digital key activation request, the friend's device first performs a self-check, including checking the device's hardware integrity, software version compatibility, and network connection stability. After passing the self-check, the friend's device generates a digital key activation request data packet containing its unique identifier, request timestamp, random number, and other information.

[0068] In one feasible implementation, after the target vehicle receives the digital key activation request, the vehicle's onboard control unit, upon receiving the digital key activation request data packet, first performs a data integrity check to ensure that the data has not been damaged or tampered with during transmission. If the data integrity check fails, the onboard control unit records an error log and sends a retransmission request to the other device.

[0069] S302, perform signature verification on the digital key activation request and obtain the verification result.

[0070] In one feasible implementation, the digital key activation request typically includes business information such as the request time, the type of operation requested (e.g., activating the digital key), and the target vehicle identifier. This business information can serve as input for signature verification. Upon receiving the digital key activation request data packet, the vehicle's onboard control unit first separates the business information and the digital signature from the data packet. The onboard control unit then uses a hash algorithm corresponding to the friend device's signature algorithm (such as SHA-256, which generates fixed-length and highly unique hash values) to perform a hash operation on the business information, obtaining a verification result containing the hash value to be verified.

[0071] S303, in response to the verification result indicating that the verification was successful, obtain the first public key certificate from the verification result.

[0072] In one feasible implementation, when signature verification passes, the vehicle control unit parses the verification result according to a predefined protocol specification, including identifying the status identifier field and determining its value as the code corresponding to "verification passed". Upon confirmation of successful verification, the vehicle control unit further retrieves the first public key certificate from the verification result.

[0073] S304, send the first public key certificate to the cloud server, where the second public key certificate corresponding to the vehicle owner's digital key stored on the cloud server verifies the signature of the first public key certificate.

[0074] In one feasible implementation, the first public key certificate is encapsulated into a defined data format. Common data formats include JSON, XML, and Protocol Buffers. The first public key certificate, based on this data format, is sent via the network link between the target vehicle and the cloud server. It should be noted that before sending the first public key certificate, the target vehicle's onboard control unit needs to check the network link with the cloud server to ensure it is functioning correctly. This can be done by sending a simple network probe request (such as an ICMP ping request). If certificate transmission fails, the target vehicle can configure a retry mechanism to automatically retry the transmission within a certain time interval. For example, an exponential backoff algorithm can be used to determine the retry interval, avoiding excessive load on the cloud server due to frequent retries.

[0075] In one feasible implementation, after receiving the first public key certificate, the cloud server returns a response indicating whether the first public key certificate was successfully received and processed. The vehicle's onboard control unit parses the response content and performs corresponding processing based on the response status code and the information in the response. For example, if the response status code is 200, it indicates that the first public key certificate was sent successfully; if the response status code is 400, it indicates an error in the request format; and if the response status code is 500, it indicates an internal error on the cloud server.

[0076] S305 receives the verification result of the first public key certificate sent by the cloud server. If the verification result has activation permission, it authorizes the activation of the friend's device.

[0077] In one feasible implementation, the target vehicle parses the signature verification result to determine whether the result grants activation permissions. The signature verification result is typically returned in a structured data format (such as JSON, XML, or binary protocol), which can be obtained by a cloud server verifying the signature of the first public key certificate using a second public key certificate in the signature-only state of the vehicle owner's device.

[0078] In some embodiments, the signature verification result is parsed to extract the permission identifier field. A bitwise AND operation is then performed between the permission identifier field and a predefined activation permission mask to obtain the result. If the result is non-zero, the signature verification result is determined to have activation permission; if the result is zero, the signature verification result is determined to have no activation permission.

[0079] In one feasible implementation, if the signature verification result has activation authority, the first public key certificate is trusted and verified, activation information is generated, and the friend's device is activated based on the activation information.

[0080] In some embodiments, the first public key certificate can be verified according to preset verification rules to obtain a verification result. If the verification result indicates that the first public key certificate has passed the verification, activation information is generated; if the verification result indicates that the first public key certificate has failed the verification, a response of refusal to activate is sent to the friend's device.

[0081] It should be noted that the preset verification rules may include: the certificate chain of the first public key certificate can be traced back to a trusted root certificate authority, the first public key certificate is within its validity period, and the first public key certificate is not in a revoked state.

[0082] In one feasible implementation, the target vehicle can authorize the activation of a friend's device based on the verification result.

[0083] For further details regarding the activation process, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0084] In summary, the digital key management method provided in this application, when the owner's device public key has been deleted from the target vehicle, effectively verifies the legitimacy of the request by verifying the signature when a friend's device initiates a digital key activation request. Only a device holding a legitimate private key to sign the request can pass the verification, thus preventing unauthorized devices from impersonating the friend's device to initiate activation requests and ensuring the security of the vehicle digital key system. Sending the first public key certificate to the cloud server and having the cloud server verify the signature using the second public key certificate corresponding to the owner's digital key further strengthens the security defense. As a trusted third party, the cloud server stores authoritative owner digital key information. This dual verification mechanism ensures that the public key certificate used by the friend's device is authorized and recognized by the owner, effectively resisting security threats such as man-in-the-middle attacks.

[0085] To expand the application scenarios of digital keys, and considering that the public key of the owner's device has not been deleted from the target vehicle, this application further elaborates on the digital key sharing process. Figure 4 and Figure 5 To explain, Figure 4 This is a flowchart illustrating another digital key management method provided in an embodiment of this application.

[0086] like Figure 4 As shown, the digital key management method includes, but is not limited to, the following steps: S401 receives a digital key activation request initiated by a friend's device after the owner's device public key has been deleted from the target vehicle.

[0087] In one feasible implementation, if the target vehicle has not deleted the owner's device public key, the vehicle's onboard control unit can extract the identifier of the friend's device from the digital key activation request initiated by the friend's device. Based on this identifier, the owner's device retrieves a first public key certificate from its own stored friend's device public key repository. The first public key certificate is then used to sign the digital key activation request, confirming that the request has not been tampered with and originates from an authorized device.

[0088] S402 verifies the trust of the digital key activation request. If the trust verification is successful, it authorizes the activation of the friend's device.

[0089] In one feasible implementation, the onboard control unit of the target vehicle verifies the signature, timestamp, and dynamic permission parameters of the friend's device activation request to confirm its legitimacy. For example, the dynamic permissions may include: activation duration, geofence information about the target vehicle, and configurable parameters for functional permissions (such as unlocking, starting, etc.). It should be noted that a cloud server can also be used to perform secondary signature verification on the friend's device activation request to increase reliability.

[0090] In one feasible implementation, if the trust verification is successful, the vehicle control unit of the target vehicle generates activation information and authorizes the friend's device to be activated based on the activation information; if the trust verification fails, the vehicle control unit of the target vehicle sends a response to the friend's device rejecting the activation.

[0091] As an example, Figure 5 This is a schematic diagram of a digital key activation process provided according to an embodiment of this application.

[0092] like Figure 5 As shown, the target vehicle has not deleted the owner's device public key. The friend device (based on a relay server) sends a digital key activation request to the target vehicle. The target vehicle retrieves the first public key certificate from its stored friend device public key library to sign the digital key activation request. In some scenarios, the cloud server can also perform secondary verification of the digital key activation request. If the verification result indicates that the first public key certificate has passed the trust verification, activation information is generated; if the verification result indicates that the first public key certificate has failed the trust verification, the target vehicle sends a response to the friend device rejecting activation. If the friend device's digital key is activated, the friend device sends the activation result to the cloud server, which maintains the friend key's status.

[0093] like Figure 5 As shown, if the target vehicle has deleted the owner's device public key, the friend device (based on a relay server) sends a digital key activation request to the target vehicle. The target vehicle verifies the validity of the digital key activation request and obtains a verification result. If the verification result indicates that the digital key activation request has not been tampered with and comes from a friend device authorized by the owner's device, the first public key certificate is obtained from the verification result. The target vehicle sends the first public key certificate to the cloud server and verifies the first public key certificate using the second public key certificate corresponding to the owner's digital key stored on the cloud server, obtaining a verification result. If the verification result indicates that the first public key certificate passes the trust verification, activation information is generated, and the target vehicle sends the activation information to the friend device; if the verification result indicates that the first public key certificate fails the trust verification, the target vehicle sends a response to the friend device rejecting activation. If activated, the friend device reports the activation result to the cloud server, and the cloud server maintains the friend key status.

[0094] To further illustrate the necessity of maintaining the second public key certificate for the vehicle owner's digital key after the deletion of the vehicle owner's device public key, this application provides... Figure 6 and Figure 7 To explain, Figure 6 This is a flowchart illustrating another digital key management method provided in an embodiment of this application.

[0095] like Figure 6As shown, the digital key management method includes, but is not limited to, the following steps: S601: After the target vehicle's owner's device public key has been deleted, the system receives the first public key certificate sent by the friend's device. The first public key certificate is obtained from the digital key activation request initiated by the friend's device.

[0096] In one feasible implementation, after the target vehicle has performed the operation of deleting the owner's device public key, and the friend's device initiates a digital key activation request to the target vehicle, the target vehicle parses the digital key activation request, extracts the first public key certificate according to the predefined data format and protocol specifications, and the cloud server receives the first public key certificate.

[0097] For further details regarding the first public key certificate, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0098] S602, the signature of the first public key certificate is verified using the second public key certificate in the stored signature-only state, and the verification result is obtained and sent to the friend's device. The second public key certificate corresponds to the vehicle owner's digital key.

[0099] In one feasible implementation, the cloud server can construct a dynamic permission mapping table to associate and store the owner's digital key on the vehicle owner's device, the friend's digital key on the friend's device, and the corresponding second public key certificate information. When the cloud server detects that the owner's device public key has been deleted from the target vehicle, it can update the dynamic permission mapping table to mark the status of all friend digital keys related to the deleted owner's digital key.

[0100] In some embodiments, based on the above, the cloud server can maintain the owner's digital key, friend's digital key, and friend's digital key status as shown in the following table:

[0101] As shown in the table above, there is a friend's digital key A, which has been authorized by the car owner's digital key A. The sharing has been completed, but the activation has not been completed.

[0102] As shown in the table above, there is a friend's digital key B, which is authorized by the car owner's digital key A, and the sharing and activation have been completed.

[0103] As shown in the table above, there is a friend's digital key C, which is authorized by the car owner's digital key B, and the sharing and activation have been completed.

[0104] As shown in the table above, there is a friend's digital key D, which is authorized by the car owner's digital key C, and the sharing and activation have been completed.

[0105] Based on the table above, the necessity information for maintaining the second public key certificate can be synchronously maintained in the following table:

[0106] As shown in the table above, if there is a vehicle owner digital key A, associated with a target vehicle A, and the number of friends whose digital keys have been shared but not activated is 1, and the vehicle owner digital key A is in a "deleted" state, then the necessity of maintaining the second public key certificate corresponding to the vehicle owner digital key A is "necessary".

[0107] As shown in the table above, if there is a vehicle owner digital key B, associated with a target vehicle B, and the number of friends' digital keys that have been shared but not activated by this vehicle owner digital key B is 0, and this vehicle owner digital key B is in a "deleted" state, then the necessity of maintaining the second public key certificate corresponding to the vehicle owner digital key B is "unnecessary".

[0108] As shown in the table above, if there is a vehicle owner digital key C, associated with a target vehicle C, and the number of friends' digital keys that have been shared but not activated by the vehicle owner digital key C is 0, and the vehicle owner digital key C is in a "in use" state, then the necessity of maintaining the second public key certificate corresponding to the vehicle owner digital key C is "necessary".

[0109] In one feasible implementation, if the owner's device completes the sharing operation and the number of unactivated friend digital keys is non-zero, and the target vehicle has deleted the owner's device public key, the status of the second public key certificate is configured as signature-only, and the necessity of maintaining the second public key certificate is "necessary"; if the owner's device completes the sharing operation and the number of unactivated friend digital keys is zero, and the target vehicle has deleted the owner's device public key, the status of the second public key certificate is configured as deleted, and the necessity of maintaining the second public key certificate is "unnecessary"; if the target vehicle has not deleted the owner's device public key (i.e., the owner's digital key status of the owner's device is in use), the status of the second public key certificate is configured as in use, and the necessity of maintaining the second public key certificate is "necessary".

[0110] As an example, based on the status of the second public key certificate mentioned above, the management policy for the cloud server can be configured accordingly. Figure 7 This is a schematic diagram of a second public key certificate management strategy provided according to an embodiment of this application.

[0111] like Figure 7 As shown, when the vehicle owner's digital key is in use, the cloud server synchronizes the status of the vehicle owner's digital key to "in use" and maintains the second public key certificate corresponding to the vehicle owner's device.

[0112] like Figure 7As shown, during the deletion of the owner's device public key in the target vehicle, the cloud server needs to verify the necessity of maintaining the second public key certificate. If the necessity of maintaining the second public key certificate is "necessary," the status of the second public key certificate is configured as "signature verification only." At this time, the cloud server can use the second public key certificate to verify the signature of the friend's device's first public key certificate, but cannot perform any other operations besides signature verification.

[0113] like Figure 7 As shown, during the process of deleting the owner device public key in the target vehicle, the cloud server needs to confirm the necessity of maintaining the second public key certificate. If the necessity of maintaining the second public key certificate is "unnecessary", the status of the second public key certificate will be configured as "deleted" after the target vehicle deletes the owner device public key.

[0114] like Figure 7 As shown, when the status of the second public key certificate is "signature only", but all the friend digital keys issued by the second public key certificate have been verified or deleted, that is, the second public key certificate does not have "shared but unverified friend digital keys", the cloud server can perform the deletion operation on the second public key certificate and configure the status of the second public key certificate to "deleted".

[0115] For further details regarding the verification results, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0116] Corresponding to the digital key management described above, this application also provides a digital key management device. Since the digital key management device of this application corresponds to the digital key management method embodiment described above, details not disclosed in the digital key management device can be referred to the digital key management method embodiment described above, and will not be repeated here.

[0117] Figure 8a This application provides a schematic diagram of the structure of a digital key management device. (See attached diagram.) Figure 8a As shown, the digital key management device 800 includes: The first receiving module 801 is used to receive a digital key activation request initiated by a friend's device after the owner's device public key has been deleted from the target vehicle. Sending module 802 is used to obtain the first public key certificate of the friend's device according to the digital key activation request, and send the first public key certificate to the cloud server. The second public key certificate corresponding to the car owner's digital key stored in the cloud server verifies the signature of the first public key certificate. The first activation module 803 is used to receive the verification result of the first public key certificate sent by the cloud server, and authorize the activation of the friend's device if the verification result has activation permission.

[0118] Optionally, such as Figure 8a As shown, the transmitting module 802 is also used for: The digital key activation request is signed and verified to obtain the verification result. In response to the verification result indicating that the verification was successful, the first public key certificate is obtained from the verification result.

[0119] Optionally, such as Figure 8a As shown, the first activation module 803 is also used for: The signature verification result is analyzed to determine whether the signature verification result has activation permission; If the signature verification result grants activation permission, the first public key certificate is verified for trust, activation information is generated, and the friend's device is activated based on the activation information.

[0120] Figure 8b This application provides a schematic diagram of the structure of another digital key management device according to an embodiment. (See attached diagram.) Figure 8b As shown, the digital key management device 800 includes: The second receiving module 804 is used to receive the first public key certificate sent by the friend's device after the owner's device public key has been deleted from the target vehicle. The first public key certificate is obtained by the digital key activation request initiated by the friend's device. The second activation module 805 is used to verify the signature of the first public key certificate using the second public key certificate in the stored signature-only state, obtain the verification result, and send the verification result to the friend's device. The second public key certificate corresponds to the vehicle owner's digital key.

[0121] Optionally, such as Figure 8b As shown, the second receiving module 804 is also used for: Receives a request from the vehicle owner's device to delete the vehicle owner's digital key; The owner's digital key deletion instruction is determined based on the owner's digital key deletion request and sent to the target vehicle. The owner's device then executes the deletion of the owner's device public key based on the owner's digital key deletion instruction.

[0122] The methods and apparatus provided in the embodiments of this application have been described above. To achieve the functions of the methods provided in the embodiments of this application, the methods and apparatus can be further refined using electronic devices.

[0123] Figure 9 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Figure 9The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0124] like Figure 9 As shown, the electronic device 900 includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a memory 906 into a random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the operation of the electronic device 900. The processor 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0125] The following components are connected to I / O interface 905: memory 906 including hard disk; and communication section 907 including network interface card such as LAN (Local Area Network) card, modem, etc., which performs communication processing via a network such as the Internet; and driver 908 is also connected to I / O interface 905 as needed.

[0126] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 907. When the computer program is executed by processor 901, it performs the functions defined in the methods of this application.

[0127] In an exemplary embodiment, a storage medium including instructions is also provided, such as a memory including instructions, which can be executed by a processor 901 of an electronic device 900 to perform the above-described method. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0128] In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can transmit, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0129] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0130] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A digital key management method, characterized in that, include: After the target vehicle has deleted the owner's device public key, receive a digital key activation request initiated by a friend's device; The first public key certificate of the friend's device is obtained according to the digital key activation request, and the first public key certificate is sent to the cloud server. The second public key certificate corresponding to the car owner's digital key stored in the cloud server verifies the signature of the first public key certificate. The system receives the verification result of the first public key certificate sent by the cloud server, and authorizes the activation of the friend's device if the verification result has activation permission.

2. The method according to claim 1, characterized in that, The step of obtaining the first public key certificate of the friend's device according to the digital key activation request includes: The digital key activation request is verified by signature to obtain the verification result; In response to a verification result indicating successful verification, the first public key certificate is obtained from the verification result.

3. The method according to claim 1, characterized in that, Sending the first public key certificate to the cloud server includes: Encapsulate the first public key certificate into a specified data format; The first public key certificate in the specified data format is sent via the network link between the target vehicle and the cloud server.

4. The method according to any one of claims 1-3, characterized in that, The step of receiving the signature verification result of the first public key certificate from the cloud server and authorizing the activation of the friend's device based on the signature verification result includes: The signature verification result is parsed to determine whether the signature verification result has activation permission; If the verification result grants activation permission, the first public key certificate is verified for trust, activation information is generated, and the friend's device is activated based on the activation information.

5. The method according to claim 4, characterized in that, Also includes: The signature verification result is obtained by the cloud server verifying the signature of the first public key certificate using the second public key certificate in the signature-only state of the vehicle owner's device.

6. The method according to claim 4, characterized in that, The step of verifying the trust of the first public key certificate and generating activation information includes: According to the preset verification rules, the first public key certificate is verified to obtain the verification result; If the verification result indicates that the first public key certificate has passed the trust verification, the activation information is generated; If the verification result indicates that the first public key certificate has failed the trust verification, a response of refusal to activate is sent to the friend's device; The preset verification rules include: The certificate chain of the first public key certificate can be traced back to a trusted root certificate authority; The first public key certificate is valid; The first public key certificate is not in a revoked state.

7. The method according to claim 1, characterized in that, The deletion of the vehicle owner's device public key for the target vehicle includes: Receive the vehicle owner digital key deletion instruction issued by the cloud server, wherein the vehicle owner digital key deletion instruction is obtained based on the vehicle owner device initiating a vehicle owner digital key deletion request to the cloud server, and the vehicle owner digital key deletion request is obtained based on the vehicle owner device deleting the stored vehicle owner device public and private key pair; According to the vehicle owner's digital key deletion command, delete the vehicle owner's device public key stored in the target vehicle.

8. The method according to claim 1, characterized in that, Also includes: In response to the fact that the owner's device public key has not been deleted from the target vehicle, receive a digital key activation request initiated by a friend's device; The digital key activation request is verified for trust. If the trust verification is successful, the activation of the friend's device is authorized.

9. A digital key management method, characterized in that, include: After the target vehicle has deleted the owner's device public key, the system receives the first public key certificate sent by the friend's device. The first public key certificate is obtained from the digital key activation request initiated by the friend's device. The signature of the first public key certificate is verified using the second public key certificate in the stored signature-only state to obtain the verification result, and the verification result is sent to the friend's device. The second public key certificate corresponds to the vehicle owner's digital key.

10. The method according to claim 9, characterized in that, The deletion of the owner's device public key in the target vehicle includes: Receives a request from the vehicle owner's device to delete the vehicle owner's digital key; The owner's digital key deletion instruction is determined based on the owner's digital key deletion request, and the owner's digital key deletion instruction is sent to the target vehicle. The owner's device executes the deletion of the owner's device public key based on the owner's digital key deletion instruction.

11. The method according to claim 9, characterized in that, Also includes: If the number of unactivated friend digital keys after the vehicle owner device completes the sharing operation is non-zero, and the status of the vehicle owner device's public key is deleted, then the status of the second public key certificate is configured to be signature-only. If the number of unactivated friend digital keys on the vehicle owner's device is zero and the status of the vehicle owner's device public key is deleted, then the status of the second public key certificate is configured to be deleted. If the owner's digital key of the vehicle owner's device is in use, configure the status of the second public key certificate to be in use.

12. A digital key management device, characterized in that, include: The first receiving module is used to receive a digital key activation request initiated by a friend's device after the owner's device public key has been deleted from the target vehicle. The sending module is used to obtain the first public key certificate of the friend's device according to the digital key activation request, and send the first public key certificate to the cloud server, wherein the second public key certificate corresponding to the car owner's digital key stored in the cloud server verifies the signature of the first public key certificate. The first activation module is used to receive the verification result of the first public key certificate sent by the cloud server, and authorize the activation of the friend's device if the verification result has activation permission.

13. The apparatus according to claim 12, characterized in that, The sending module is further configured to: The digital key activation request is verified by signature to obtain the verification result; In response to a verification result indicating successful verification, the first public key certificate is obtained from the verification result.

14. The apparatus according to claim 12, characterized in that, The first activation module is further configured to: The signature verification result is parsed to determine whether the signature verification result has activation permission; If the verification result grants activation permission, the first public key certificate is verified for trust, activation information is generated, and the friend's device is activated based on the activation information.

15. A digital key management device, characterized in that, include: The second receiving module is used to receive a first public key certificate sent by a friend's device after the target vehicle has deleted the owner's device public key. The first public key certificate is obtained by a digital key activation request initiated by the friend's device. The second activation module is used to verify the signature of the first public key certificate using the second public key certificate in the stored signature-only state, obtain the verification result, and send the verification result to the friend's device, wherein the second public key certificate corresponds to the vehicle owner's digital key.

16. The apparatus according to claim 15, characterized in that, The second receiving module is further configured to: Receives a request from the vehicle owner's device to delete the vehicle owner's digital key; The owner's digital key deletion instruction is determined based on the owner's digital key deletion request, and the owner's digital key deletion instruction is sent to the target vehicle. The owner's device executes the deletion of the owner's device public key based on the owner's digital key deletion instruction.

17. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 8 or 9 to 11.

18. A non-transitory computer-readable storage medium, characterized in that, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the method as described in any one of claims 1 to 8 or 9 to 11.

19. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8 or 9 to 11.

Images