A digital key management method and device

Abstract

The application provides a digital key management method and device, comprising: receiving a digital key activation request initiated by a friend device after a target vehicle has deleted a public key of an owner device; obtaining a first public key certificate of the friend device according to the digital key activation request, and sending the first public key certificate to a cloud server; receiving a signature verification result of the first public key certificate sent by the cloud server, and authorizing the activation of the friend device in the case that the signature verification result has activation authority. In the case that the target vehicle has deleted the public key of the owner device, the first public key certificate of the friend device is verified by the cloud server by using a second public key certificate corresponding to the owner digital key, so that only a legal and trusted friend device can initiate an activation request, and illegal devices are effectively prevented from impersonating the friend device to obtain the digital key authority. Whether to authorize the activation of the friend device is determined based on the signature verification result, and fine-grained authority management is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicles, and in particular to a digital key management method and device. BACKGROUND

[0002] With the rapid development of intelligent networked vehicles, digital key technology has become an important medium connecting vehicle owners and vehicles. Digital key technology involves the interaction of people, vehicles and the cloud to manage the sharing, activation and deletion of digital keys in the life cycle of digital keys. Any vulnerability in the interaction process may lead to privacy leakage or vehicle theft.

[0003] It should be noted that the above introduction to the technical background is only to facilitate a clear and complete description of the technical solutions of the present application, and to facilitate the understanding of those skilled in the art. The above technical solutions cannot be considered as known to those skilled in the art merely because they are described in the background section of the present application. SUMMARY

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

[0005] To this end, the first purpose of the present application is to propose two digital key management methods.

[0006] The second purpose of the present application is to propose two digital key management devices.

[0007] The third purpose of the present application is to propose an electronic device.

[0008] The fourth purpose of the present application is to propose a non-transitory computer readable storage medium.

[0009] The fifth purpose of the present application is to propose a computer program product.

[0010] To achieve the above purpose, the first aspect of the present application proposes a digital key management method, comprising:

[0011] After the target vehicle has deleted the public key of the owner device, receiving a digital key activation request initiated by a friend device;

[0012] According to the digital key activation request, obtaining a first public key certificate of the friend device, and sending the first public key certificate to a cloud server, wherein the second public key certificate corresponding to the owner digital key stored by the cloud server is used to verify the first public key certificate;

[0013] Receiving a verification result of the first public key certificate sent by the cloud server, and in the case that the verification result has activation authority, authorizing the activation of the friend device.

[0014] To achieve the above object, the second aspect of the present application proposes a digital key management method, comprising:

[0015] After the target vehicle has deleted the public key of the owner device, a first public key certificate sent by the friend device is received, wherein the first public key certificate is obtained by a digital key activation request initiated by the friend device;

[0016] The signature of the first public key certificate is verified by the stored second public key certificate in the only verification state, and a verification result is obtained, and the verification result is sent to the friend device, wherein the second public key certificate corresponds to the owner digital key.

[0017] To achieve the above object, the third aspect of the present application proposes a digital key management device, comprising:

[0018] The first receiving module is configured to receive a digital key activation request initiated by a friend device after a target vehicle has deleted the public key of an owner device;

[0019] The sending module is configured to obtain a first public key certificate of the friend device according to the digital key activation request, and send the first public key certificate to a cloud server, wherein a second public key certificate corresponding to an owner digital key stored by the cloud server verifies the first public key certificate;

[0020] The first activation module is configured to receive a verification result of the first public key certificate sent by the cloud server, and authorize the activation of the friend device in the case that the verification result has activation authority.

[0021] To achieve the above object, the fourth aspect of the present application proposes a digital key management device, comprising:

[0022] The second receiving module is configured to receive a first public key certificate sent by a friend device after a target vehicle has deleted the public key of an owner device, wherein the first public key certificate is obtained by a digital key activation request initiated by the friend device;

[0023] The second activation module is configured to verify the signature of the first public key certificate by the stored second public key certificate in the only verification state, obtain a verification result, and send the verification result to the friend device, wherein the second public key certificate corresponds to the owner digital key.

[0024] To achieve the above object, the fifth aspect of the present application provides an electronic device, comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the digital key management method according to the first aspect or the second aspect of the present application.

[0025] To achieve the above object, the sixth aspect of the present application provides a non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the digital key management method according to the first aspect or the second aspect of the present application.

[0026] To achieve the above object, the seventh aspect of the present application provides a computer program product, comprising a computer program, when the computer program is executed by a processor in a communication device, the digital key management method according to the first aspect or the second aspect of the present application is implemented.

[0027] In the embodiments of the present application, in the context that the target vehicle has deleted the public key of the owner device, the first public key certificate of the friend device is verified by the cloud server using the second public key certificate corresponding to the owner digital key, ensuring that only a legitimate and trusted friend device can initiate an activation request, effectively preventing illegal devices from impersonating friend devices to obtain digital key permissions, greatly enhancing the security of the system and protecting the vehicle and related digital assets from unauthorized access. Based on the verification result, it is determined whether to authorize the activation of the friend device, realizing fine-grained permission management. Only when the verification result indicates that the friend device has activation permission, will the authorization activation operation be performed, ensuring that the distribution of digital keys strictly follows the preset permission rules, avoiding the situation of abuse of permissions and misallocation.

[0028] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter in the description of the application. BRIEF DESCRIPTION OF DRAWINGS

[0029] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which:

[0030] Figure 1 A schematic diagram of a digital key sharing process provided by an embodiment of the present application;

[0031] Figure 2 A flowchart of a digital key management method provided by an embodiment of the present application;

[0032] Figure 3 A flowchart of another digital key management method provided by an embodiment of the present application;

[0033] Figure 4 A flowchart of another digital key management method provided by the embodiments of the present application;

[0034] Figure 5 A flowchart of a digital key activation process provided by the embodiments of the present application;

[0035] Figure 6 A flowchart of another digital key management method provided by the embodiments of the present application;

[0036] Figure 7 A second public key certificate management strategy provided by the embodiments of the present application;

[0037] Figure 8a A structure diagram of a digital key management device provided by the embodiments of the present application;

[0038] Figure 8b A structure diagram of another digital key management device provided by the embodiments of the present application;

[0039] Figure 9 A structure diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0040] The exemplary embodiments will be described in detail herein below with reference to the drawings. The following description is with reference to the drawings, in which like numerals refer to like elements throughout. The implementations described in the following exemplary embodiments are not meant to represent all implementations in which one or more embodiments of the present application can be practiced. Rather, they are merely examples with which one or more embodiments of the present application can be practiced.

[0041] The terminology used in the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in the present application and the appended claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

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

[0043] The embodiments of the present application are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar notations represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by reference to the accompanying drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0044] With the development of the intelligent trend of the automobile industry, the digital key function is widely used in the automobile industry. It not only breaks away from the shackles of traditional physical keys, so that the car owner does not need to worry about forgetting the key or losing the key, but also brings more convenient experience to the user with its diversified unlocking methods, such as mobile phone Bluetooth unlocking, NFC (Near Field Communication) induction unlocking, etc.

[0045] In order to further tap the potential value of the digital key and expand its application scope, it has become a common and practical way in the expansion of the digital key function for the car owner to share the use permission of the digital key with friends through a specific way and authorize the use permission of the car owner's vehicle to the friend's device. Such sharing function has great convenience in social scenes.

[0046] Figure 1 A schematic diagram of a digital key sharing process provided by an embodiment of the present application is shown. As shown in Figure 1 The car owner device applies for opening an information interaction space (which can be referred to as a "cloud mailbox") to the relay server (the relay server is a network node located between the target vehicle, the car owner device, the friend device and the cloud server, and its core role is to provide safe and efficient data transfer and interaction support between devices, and it does not directly store or process data, but acts as an "intermediary" to forward requests and responses) for uploading part of the business information, and generates a URL (Uniform Resource Locator) pointing to the information interaction space, which can optionally include the "cloud mailbox" address.

[0047] The car owner sends (shares) the URL to the friend device based on relevant communication methods (such as SMS, social software, etc.) through the car owner device.

[0048] After receiving the URL, the friend device accesses the relay server to pull the service information uploaded by the owner (such as the duration and permissions of the digital key shared by the owner). The friend device can generate a friend device public-private key pair and push the friend device public key to the relay server.

[0049] The relay server can send a pull notification to the owner device. Based on the pull notification, the owner device accesses the relay server to pull the friend device public key and signs the friend device public key using the owner device private key to generate a friend device public key certificate (E), referred to as certificate (E) for short. At the same time, the target vehicle also includes a public key certificate (B), referred to as certificate (B) for short, and the owner device can push certificate (E) and certificate (B) to the relay server.

[0050] The relay server can send a pull notification to the friend device, and the friend device can pull certificate (E) signed by the owner device private key and certificate (B) of the target vehicle from the relay server based on the pull notification. Therefore, when the friend device is close to the target vehicle, the friend device can send certificate (E) and certificate (B) to the target vehicle. The target vehicle can verify certificate (E) by the owner device public key and accept the friend device public key after verification.

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

[0052] After receiving certificate (E), the cloud server maintains certificate (E), including checking the validity period of certificate (E), verifying the signature of certificate (E) to ensure authenticity and legality, and checking whether the subject information of certificate (E) (such as the identification of the friend device, user information, etc.) is consistent with the expected value.

[0053] If certificate (E) is verified, the cloud server will store the friend device public key certificate (E) in a secure database for subsequent authentication and management of the friend device's identity. At the same time, record the related information of the friend device public key certificate (E), such as the reporting time, device identification, etc., for auditing and tracking.

[0054] It should be noted that in the above process, some abnormal situations may occur, and corresponding processing is performed for the abnormal situations. If the friend device encounters network connection problems during the selection of the network link or the transmission of data, the friend device will try to reconnect the network, and after a certain number of failures (for example, 3 times), the user is prompted to check the network settings or try again later. If the cloud server encounters an error when decrypting the data packet, it may be due to mismatched keys or damaged data, and the cloud server sends an error notification to the friend device and prompts the friend device to re-report the certificate (E). If the cloud server fails to verify the certificate (E), it will record the failure reason and send a verification failure notification to the friend device, and the friend device checks whether the certificate (E) is correct or generates a new certificate based on the notification.

[0055] In some application scenarios, the digital key sharing process usually includes two steps:

[0056] The first step is to authorize (i.e., "share") the friend digital key by the owner digital key, and to ensure that only the authorized friend can obtain the owner digital key information.

[0057] The second step is to authenticate the related keys and certificates carried by the friend digital key lock by the target vehicle. When the friend tries to use the friend digital key to unlock or start the target vehicle, the security system built-in the target vehicle will start the authentication process to compare the keys and certificates uploaded by the friend device with the information stored in the target vehicle, and to check the validity period, signature, and other information of the certificate to ensure its authenticity and legality. Only after the verification is correct, the friend digital key can realize normal use of the target vehicle in the subsequent, which is called "activation". Only after the activation is completed, the friend can truly have the operation permission of the target vehicle.

[0058] It should be noted that the "sharing" in the first step and the "activation" in the second step are usually not performed synchronously, and there is a time interval between the two, showing an asynchronous and discontinuous state. This asynchrony may cause some problems, for example, in the case of unstable network, the friend device may not be able to receive the authorization information in time; or in the activation process, there is a delay, which causes the friend to be unable to smoothly unlock the target vehicle when it needs to use the target vehicle.

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

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

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

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

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

[0064] 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).

[0065] like Figure 2 As shown, the digital key management method includes, but is not limited to, the following steps:

[0066] S201, after the target vehicle has deleted the owner device public key, receiving a digital key activation request initiated by the friend device.

[0067] In a feasible implementation, when the target vehicle completes the key event of deleting the owner device public key and receives a friend digital key request initiated by the friend device again, the entire system (referring to a digital key management system, which is usually composed of a vehicle-side digital key management module, a cloud service platform, and a mobile device (owner / friend) digital key application module) will establish a rigorous processing mechanism to ensure the safety of the target vehicle, protect the interests of the owner, and optimize the user experience. In some embodiments, the system performs preliminary analysis on the basic information of the digital key activation request, including the identification of the friend device, the request time, etc.

[0068] In a feasible implementation, when processing the digital key activation request, the system will strictly verify the identity of the friend device. In addition to the regular signature verification of the public key certificate uploaded by the friend device, the system will also conduct comprehensive verification based on other features of the friend device, such as the hardware identification (international mobile equipment identity, media access control address, etc.), operating system version, installed application list, etc. Through multi-dimensional information comparison, it is ensured that the digital key activation request initiated by the friend device is indeed a device that has obtained the digital key sharing authorization, preventing malicious activation requests initiated by fake devices.

[0069] In a feasible implementation, to ensure the security of the activation request and related verification information during transmission, the system can use high-strength encryption algorithms to encrypt the data. For example, use the TLS 1.3 protocol for communication to ensure that the data is not stolen or tampered with during transmission between the friend device, the cloud server, and the target vehicle terminal. At the same time, the system will regularly update the encryption key to improve the security of data transmission.

[0070] In a feasible implementation, when the friend device initiates a digital key activation request, the system can send a notification message to the friend device regardless of whether the final activation is successful. In the case of successful activation, the friend device is notified that the digital key has been activated and can be used normally; in the case of activation being rejected, the reason for rejection is specified in detail, and appropriate solutions are provided, such as contacting the owner for re-authorization, etc.

[0071] S202, according to the digital key activation request, obtaining the first public key certificate of the friend device, and sending the first public key certificate to the cloud server, wherein the second public key certificate corresponding to the owner digital key stored in the cloud server verifies the first public key certificate.

[0072] In a feasible implementation, the friend device sends a digital key activation request to the target vehicle through a specific communication protocol (such as Bluetooth, NFC, or an Internet-based protocol). When initiating the digital key activation request, the friend device encapsulates the first public key certificate carried by itself in the digital key activation request according to a predetermined encrypted communication protocol. The first public key certificate is an important digital certificate of the legitimacy of the identity of the friend device, which is generated based on an asymmetric encryption algorithm and contains public key information, a device unique identifier, a signature of a certificate authority (CA), and other key data. These data are processed through a specific encryption algorithm to ensure the confidentiality, integrity, and non-repudiation of the certificate during transmission and storage.

[0073] In a feasible implementation, when analyzing the digital key activation request, the electronic control unit (ECU) of the target vehicle accurately extracts the first public key certificate. Subsequently, the ECU sends the first public key certificate to the cloud server through a secure network channel. This network channel usually uses an encrypted transport layer security protocol (TLS) to prevent the certificate from being stolen or tampered with during transmission.

[0074] In a feasible implementation, the cloud server, as the core security hub of the entire digital key management system, stores the second public key certificate corresponding to the owner's digital key. The second public key certificate is generated based on an asymmetric encryption mechanism and is used in conjunction with the private key of the owner's device to verify the legitimacy of the owner's device-related operations. When the cloud server receives the first public key certificate from the target vehicle, it immediately initiates a signature verification process.

[0075] In a 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 decrypted data with the original data hash value 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 was tampered with during transmission. Only when the signature verification result is passed, the cloud server will consider the first public key certificate of the friend device to be legitimate and effective, providing a secure basis for subsequent digital key activation authorization.

[0076] In a feasible implementation, the cloud server returns the signature verification result to the target vehicle. If the signature verification is passed, it means that the first public key certificate of the friend device is legitimate, and the friend device can continue to process the activation request. If the signature verification fails, the activation request will be rejected, and an appropriate error prompt will be sent to the friend device.

[0077] S203, receiving the verification result of the first public key certificate sent by the cloud server, and in the case that the verification result has the activation permission, authorizing the activation of the friend device.

[0078] In an available embodiment, the on-board control unit of the target vehicle unpacks the data packet layer by layer after receiving the verification result data packet of the first public key certificate sent by the cloud server, and extracts the key information in the verification result, such as the verification status code, the permission level identifier, etc. After the analysis is completed, the on-board control unit analyzes the verification result according to the preset permission judgment logic.

[0079] In some embodiments, the on-board control unit checks whether the verification status code is in the success state, and checks whether the permission level identifier meets the minimum permission requirement of the friend device for the digital key activation request. Only when the verification status code clearly indicates that the verification is successful, and the permission level identifier reaches or exceeds the preset activation permission threshold, the on-board system determines that the verification result has the activation permission.

[0080] In an available embodiment, when it is confirmed that the verification result has the activation permission, the on-board control unit will quickly enter the authorized activation stage, and generate a unique activation authorization token, which is encrypted by using a high-strength encryption algorithm to prevent being stolen or tampered with during transmission. The on-board control unit transmits the encrypted activation authorization token to the friend device through the high-speed bus (such as CAN bus or LIN bus) of the target vehicle. After receiving the authorization token, the friend device uses the decryption key stored in advance to decrypt the token, and obtains the activation instructions and related parameters therein. The friend device initializes and activates the digital key function according to these instructions and parameters, so that it can establish a secure and reliable communication connection with the on-board system of the target vehicle, and realize the functions of the digital key, such as remote unlocking, starting the vehicle, etc.

[0081] In an available embodiment, the owner device can also feed back the activation result to the cloud server, so that the cloud server updates the related records and states. For example, if the authorization is successful, the cloud server records the activation state and permission information of the friend device; if the authorization fails, the cloud server records the failure reason.

[0082] In summary, the digital key management method provided by the embodiments of the present application, in the context that the target vehicle has deleted the public key of the owner device, ensures that only a legitimate and trusted friend device can initiate an activation request by verifying the first public key certificate of the friend device with the second public key certificate corresponding to the owner digital key by the cloud server, effectively preventing illegal devices from impersonating friend devices to obtain digital key permissions, greatly enhancing the security of the system and protecting the vehicle and related digital assets from unauthorized access. Based on the verification result, it is determined whether to authorize the activation of the friend device, thereby realizing fine-grained permission management. Only when the verification result indicates that the friend device has activation permission, will the authorization activation operation be performed, ensuring that the distribution of digital keys strictly follows the preset permission rules, and avoiding the occurrence of permission abuse and misallocation.

[0083] To further illustrate the process of verifying the verification result, the present application provides Figure 3 for illustration, Figure 3 a flowchart of another digital key management method provided by the embodiments of the present application.

[0084] As Figure 3 indicated, the digital key management method includes but is not limited to the following steps:

[0085] S301, after the target vehicle has deleted the public key of the owner device, receiving a digital key activation request initiated by the friend device.

[0086] In one possible implementation, after the target vehicle performs the operation of deleting the public key of the owner device, the vehicle control unit of the target vehicle will immediately update its internal security key storage database, remove the originally stored public key of the owner device from the valid key list, and mark it as deleted.

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

[0088] In some embodiments, the user initiates a digital key activation request on the friend device through voice interaction. The digital key activation request is received by the target vehicle through interaction between the friend device and the target vehicle. Exemplarily, the interaction between the friend device and the target vehicle includes but is not limited to near field communication, Bluetooth communication, and ultra-wideband communication.

[0089] In some embodiments, the user initiates a digital key activation request on the friend device based on the user interface of the vehicle manufacturer's APP or a third-party platform (e.g., a mini program). The digital key activation request is received by the target vehicle through interaction between the friend device and the target vehicle.

[0090] In a feasible implementation, when initiating the digital key activation request, the friend device first performs self-state inspection, including checking the hardware integrity, software version compatibility, network connection stability, and the like of the device. After the self-state inspection passes, the friend device generates a digital key activation request data packet containing information such as a unique identifier of the friend device, a request timestamp, a random number, and the like.

[0091] In a feasible implementation, after the target vehicle receives the digital key activation request, the vehicle-mounted control unit of the target vehicle first performs data integrity verification after receiving the digital key activation request data packet, to ensure that the data is not damaged or tampered with during transmission. If the data integrity verification fails, the vehicle-mounted control unit records an error log and sends a retransmission request to the friend device.

[0092] S302, signature verification is performed on the digital key activation request, to obtain a verification result.

[0093] In a feasible implementation, the digital key activation request usually contains business information such as a request time, a requested operation type (such as activating a digital key), and a target vehicle identifier, which can be used as input content for signature verification. After receiving the digital key activation request data packet, the vehicle-mounted control unit of the target vehicle first separates the business information and the digital signature from the data packet. The vehicle-mounted control unit uses a hash algorithm (such as SHA-256, which can generate a fixed-length hash value with high uniqueness) corresponding to the signature algorithm of the friend device to perform hash operation on the business information, to obtain a verification result containing a hash value to be verified.

[0094] S303, in response to the verification result indicating that the verification passes, a first public key certificate is obtained from the verification result.

[0095] In a feasible implementation, when the signature verification passes, the vehicle-mounted control unit parses the verification result according to a pre-defined protocol specification, including identifying a status identifier field and determining the value corresponding to the code of “verification pass”. When it is confirmed that the verification passes, the vehicle-mounted control unit further obtains the first public key certificate from the verification result.

[0096] S304, the first public key certificate is sent to a cloud server, wherein a second public key certificate corresponding to a vehicle owner digital key stored in the cloud server is used to verify the first public key certificate.

[0097] In an implementation, the first public key certificate is encapsulated into a predefined data format. Common data formats include JSON, XML, Protocol Buffers, etc. The first public key certificate in the data format is sent through the network link between the target vehicle and the cloud server. It should be noted that before sending the first public key certificate, the vehicle control unit of the target vehicle needs to check whether the network link with the cloud server is normal, and the connectivity of the network link can be detected by sending a simple network probe request (such as an ICMP ping request). If the certificate sending fails, the target vehicle can set a retry mechanism to automatically retry sending within a certain time, for example, an exponential backoff algorithm can be used to determine the retry interval time to avoid excessive load on the cloud server due to frequent retries.

[0098] In an implementation, after the cloud server receives the first public key certificate, it returns a response indicating whether the first public key certificate is successfully received and processed. The vehicle control unit of the target vehicle parses the response content and performs corresponding processing according to the response status code and information in the response. For example, if the response status code is 200, it indicates that the first public key certificate is sent successfully; if the response status code is 400, it indicates that the request format is incorrect; and if the response status code is 500, it indicates that there is an internal error in the cloud server.

[0099] S305, receiving the verification result of the first public key certificate sent by the cloud server, and in the case that the verification result has activation authority, authorizing the activation of the friend device.

[0100] In an implementation, the target vehicle parses the verification result to determine whether the verification result has activation authority. The verification result is usually returned in a structured data format (such as JSON, XML, or binary protocol), and the verification result can be obtained by verifying the signature of the first public key certificate using the second public key certificate in the owner device only signature state by the cloud server.

[0101] In some embodiments, the verification result is parsed to extract the permission identification field. The permission identification field is bitwise ANDed with a predefined activation permission mask to obtain an operation result. If the operation result is non-zero, it is determined that the verification result has activation authority; if the operation result is zero, it is determined that the verification result has no activation authority.

[0102] In an implementation, in the case that the verification result has activation authority, the first public key certificate is verified for trust, and activation information is generated, and the friend device is activated based on the activation information.

[0103] In some embodiments, the first public key certificate can be subjected to trust verification according to a preset verification rule to obtain a verification result. If the verification result indicates that the first public key certificate passes the trust verification, the activation information is generated; if the verification result indicates that the first public key certificate fails the trust verification, a response of rejecting the activation is fed back to the friend device.

[0104] It should be noted that the preset verification rule can include that the certificate chain of the first public key certificate is traceable to a trusted root certificate authority, the first public key certificate is within a valid period, and the first public key certificate is not in a revoked state.

[0105] In a feasible implementation, the target vehicle can authorize the activation of the friend device according to the signature verification result.

[0106] For further specific introduction of the activation process, reference can be made to the description of the related content in the above embodiments, which will not be repeated here.

[0107] In summary, the digital key management method provided by the embodiments of the present application can effectively identify the legality of the request through the signature verification link when the friend device initiates the digital key activation request in the context that the target vehicle has deleted the public key of the vehicle owner device. Only the device holding the legal private key to sign the request can pass the verification, thereby preventing the illegal device from impersonating the friend device to initiate the activation request and ensuring the security of the vehicle digital key system. Sending the first public key certificate to the cloud server and verifying it by the cloud server using the second public key certificate corresponding to the vehicle owner digital key further strengthens the security line. As a trusted third party, the cloud server has authoritative vehicle owner digital key information, and through this double signature verification mechanism, it is ensured that the public key certificate used by the friend device is authorized and approved by the vehicle owner, effectively resisting security threats such as man-in-the-middle attacks.

[0108] In order to expand the use scenarios of the digital key, in combination with the target vehicle not performing the deletion of the public key of the vehicle owner device, the digital key sharing process is further described, and the present application provides Figure 4 and Figure 5 are described, Figure 4 a flowchart of another digital key management method provided by the embodiments of the present application.

[0109] As Figure 4 shown, the digital key management method includes but is not limited to the following steps:

[0110] S401, after the target vehicle has deleted the public key of the vehicle owner device, receiving a digital key activation request initiated by the friend device.

[0111] In an implementation, if the target vehicle does not delete the public key of the owner device, the vehicle control unit of the target vehicle can extract the identification code of the friend device from the digital key activation request initiated by the friend device, and based on the identification code, the owner device obtains the first public key certificate from the friend device public key library stored in the owner device. The first public key certificate is used to sign the digital key activation request, and it is confirmed that the digital key activation request is tampered and comes from an authorized device.

[0112] S402, the digital key activation request is verified, and in the case that the verification is passed, the friend device is authorized to be activated.

[0113] In an implementation, the vehicle control unit of the target vehicle verifies the signature, timestamp and dynamic permission parameter of the friend device activation request, and confirms the legality of the friend device activation request. As an example, the dynamic permission can include: activation duration, geofencing information about the target vehicle, and configurable parameters of function permissions (such as unlocking, starting, etc.). It should be noted that the cloud server can also be used to re-sign the friend device activation request to increase reliability.

[0114] In an implementation, if the verification is passed, the vehicle control unit of the target vehicle generates activation information based on the activation information to authorize the activation of the friend device; if the verification is not passed, the vehicle control unit of the target vehicle feeds back a response of rejecting the activation to the friend device.

[0115] As an example, Figure 5 A schematic diagram of a digital key activation process according to an embodiment of the present application.

[0116] As Figure 5 shown, the target vehicle does not delete the public key of the owner device, and the friend device (based on the relay server) sends a digital key activation request to the target vehicle. The target vehicle obtains the first public key certificate from the friend device public key library stored in the target vehicle to sign the digital key activation request, and in some scenarios, the cloud server can also re-sign the digital key activation request. If the verification result indicates that the first public key certificate passes the trust verification, the activation information is generated; if the verification result indicates that the first public key certificate does not pass the trust verification, the target vehicle feeds back a response of rejecting the activation to the friend device. If the friend device digital key is activated, the friend device sends the activation result to the cloud server, and the cloud server maintains the friend key state.

[0117] As Figure 5As shown, if the target vehicle has deleted the owner device public key, the friend device (based on the relay server) sends a digital key activation request to the target vehicle. The target vehicle performs legality verification on the digital key activation request and obtains a verification result. If the verification result indicates that the digital key activation request is not tampered with and comes from a friend device authorized by the owner device, a first public key certificate is obtained from the verification result. The target vehicle sends the first public key certificate to the cloud server, and uses a second public key certificate corresponding to the owner digital key stored by the cloud server to verify the first public key certificate, and obtains a verification result. If the verification result indicates that the first public key certificate passes the trust verification, an 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 does not pass the trust verification, the target vehicle feeds back a response of rejecting activation to the friend device. If activated, the friend device reports the activation result to the cloud server, and the cloud server maintains the friend key state.

[0118] To further illustrate the necessity of maintaining the second public key certificate of the owner digital key after the owner device public key is deleted, the present application provides Figure 6 and Figure 7 for illustration, Figure 6 a flowchart of another digital key management method provided by the embodiments of the present application.

[0119] As Figure 6 shown, the digital key management method includes but is not limited to the following steps:

[0120] S601, after the target vehicle has deleted the owner device public key, receiving a first public key certificate sent by a friend device, wherein the first public key certificate is obtained by a digital key activation request initiated by the friend device.

[0121] In a possible implementation, after the target vehicle has performed the operation of deleting the owner device public key, and the friend 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 specification, and receives the first public key certificate by the cloud server.

[0122] For further specific introduction of the first public key certificate, reference can be made to the description of the related contents in the above embodiments, which will not be repeated here.

[0123] S602, verifying the signature of the first public key certificate by the stored second public key certificate in the only verification state, obtaining a verification result, and sending the verification result to the friend device, wherein the second public key certificate corresponds to the owner digital key.

[0124] In a feasible implementation, the cloud server can construct a dynamic permission mapping table to store the owner digital key in the owner device, the friend digital key in the friend device, and the corresponding second public key certificate information in association. When the cloud server monitors that the target vehicle has deleted the public key of the owner device, the dynamic permission mapping table can be updated through the cloud server to mark the status of all friend digital keys related to the deleted owner digital key.

[0125] In some embodiments, according to the above, the cloud server can maintain the owner digital key, the friend digital key, and the friend digital key state as the following table:

[0126]

[0127] As shown in the above table, there is a friend digital key A authorized by the owner digital key A, which has completed sharing but not activation.

[0128] As shown in the above table, there is a friend digital key B authorized by the owner digital key A, which has completed sharing and activation.

[0129] As shown in the above table, there is a friend digital key C authorized by the owner digital key B, which has completed sharing and activation.

[0130] As shown in the above table, there is a friend digital key D authorized by the owner digital key C, which has completed sharing and activation.

[0131] According to the above table, the second public key certificate maintenance necessity information can be maintained in the following table:

[0132]

[0133] As shown in the above table, there is an owner digital key A associated with the target vehicle A, the number of friend digital keys shared but not activated by the owner digital key A is 1, and the owner digital key A is in the "deleted" state, so the necessity of the second public key certificate corresponding to the owner digital key A is "necessary".

[0134] As shown in the above table, there is an owner digital key B associated with the target vehicle B, the number of friend digital keys shared but not activated by the owner digital key B is 0, and the owner digital key B is in the "deleted" state, so the necessity of the second public key certificate corresponding to the owner digital key B is "unnecessary".

[0135] As shown in the above table, if there exists the owner digital key C associated with the target vehicle C, the number of shared but not activated friend digital keys of the owner digital key C is 0, and the owner digital key C is in the "in use" state, the necessity of maintaining the second public key certificate corresponding to the owner digital key C is "necessary".

[0136] In a feasible implementation, if the number of shared but not activated friend digital keys of the owner device is non-zero after the sharing operation is completed, and the target vehicle has deleted the public key of the owner device, the state 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 number of shared but not activated friend digital keys of the owner device is zero after the sharing operation is completed, and the target vehicle has deleted the public key of the owner device, the state 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 public key of the owner device (i.e., the state of the owner digital key of the owner device is "in use"), the state of the second public key certificate is configured as "in use", and the necessity of maintaining the second public key certificate is "necessary".

[0137] For example, according to the state of the second public key certificate described above, the management strategy of the cloud server can be set accordingly, Figure 7 A second public key certificate management strategy according to an embodiment of the present application is shown in the figure.

[0138] As shown in the figure, Figure 7 when the owner digital key is in use, the cloud server synchronizes the state of the owner digital key to "in use", and the cloud server maintains the second public key certificate corresponding to the owner device.

[0139] As shown in the figure, Figure 7 in the process of deleting the public key of the owner device by the target vehicle, the cloud server needs to confirm the necessity of maintaining the second public key certificate, and if the necessity of maintaining the second public key certificate is "necessary", the state of the second public key certificate is configured as "signature only". At this time, the cloud server can use the second public key certificate to sign the first public key certificate of the friend device, but cannot perform any other operation except signing.

[0140] As shown in the figure, Figure 7 in the process of deleting the public key of the owner device by the target vehicle, the cloud server needs to confirm the necessity of maintaining the second public key certificate, and if the necessity of maintaining the second public key certificate is "unnecessary", the state of the second public key certificate is configured as "deleted" after the target vehicle deletes the public key of the owner device.

[0141] As shown in the figure, Figure 7As shown, when the status of the second public key certificate is "signature verification only", but the friend digital keys issued by the second public key certificate are all verified or deleted, that is, there is no "shared but not verified friend digital key" in the second public key certificate, the cloud server can additionally perform a deletion operation on the second public key certificate, and configure the status of the second public key certificate as "deleted".

[0142] For further details of the signature verification result, please refer to the relevant content described in the above embodiments, which will not be repeated here.

[0143] Corresponding to the above-mentioned digital key management, the present application also provides a digital key management device. Since the digital key management device of the present application corresponds to the above-mentioned digital key management method embodiment, the details not disclosed in the digital key management device can be referred to the above-mentioned digital key management method embodiment, which will not be repeated here.

[0144] Figure 8a A structural schematic diagram of a digital key management device provided by an embodiment of the present application. As shown in the figure, Figure 8a The digital key management device 800 comprises:

[0145] A first receiving module 801, the first receiving module 801 is configured to receive a digital key activation request initiated by a friend device after the target vehicle has deleted the public key of the owner device;

[0146] A sending module 802, the sending module 802 is configured to obtain a first public key certificate of the friend device according to the digital key activation request, and send the first public key certificate to a cloud server, wherein the second public key certificate corresponding to the owner digital key stored in the cloud server verifies the first public key certificate;

[0147] A first activation module 803, the first activation module 803 is configured to receive a signature verification result of the first public key certificate sent by the cloud server, and authorize the activation of the friend device in the case that the signature verification result has activation authority.

[0148] Optionally, as shown in the figure, Figure 8a The sending module 802 is further configured to:

[0149] verify the signature of the digital key activation request to obtain a verification result;

[0150] In response to the verification result indicating that the verification is passed, obtain the first public key certificate from the verification result.

[0151] Optionally, as shown in the figure, Figure 8a The first activation module 803 is further configured to:

[0152] analyze the signature verification result to determine whether the signature verification result has activation authority;

[0153] In the case that the signature verification result has the activation permission, the first public key certificate is verified, activation information is generated, and the friend device is activated based on the activation information.

[0154] Figure 8b Another structure schematic diagram of the digital key management device provided by the embodiment of the present application is shown. As shown in the figure, the digital key management device 800 comprises: Figure 8b

[0155] The second receiving module 804 is configured to receive the first public key certificate sent by the friend device after the target vehicle deletes the public key of the owner device, wherein the first public key certificate is obtained from the digital key activation request initiated by the friend device.

[0156] The second activation module 805 is configured to verify the signature of the first public key certificate by the stored second public key certificate in the signature verification state, obtain a signature verification result, and send the signature verification result to the friend device, wherein the second public key certificate corresponds to the owner digital key.

[0157] Optionally, as shown in the figure, the second receiving module 804 is further configured to: Figure 8b

[0158] Receive the owner digital key deletion request initiated by the owner device.

[0159] Determine the owner digital key deletion instruction according to the owner digital key deletion request, and send the owner digital key deletion instruction to the target vehicle, wherein the public key of the owner device is deleted based on the owner digital key deletion instruction.

[0160] The above embodiments provided by the present application provide methods and devices. In order to realize the functions of the above methods and devices, the above methods and devices can be further refined by electronic devices.

[0161] Figure 9 A structure schematic diagram of an electronic device according to the embodiment of the present application is shown. Figure 9 The electronic device shown is only an example, and should not limit the functions and use range of the embodiments of the present application.

[0162] As shown in the figure, the electronic device 1000 comprises: Figure 9 ​​As shown, the electronic device 900 includes a processor 901 which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 902 or a program loaded from the storage 906 into a Random Access Memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the electronic device 900 are also stored. The processor 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. An Input / Output (I / O) interface 905 is also connected to the bus 904.

[0163] Connected to the I / O interface 905 are: a storage 906 including a hard disk or the like; and a communication section 907 including a network interface card such as a LAN (Local Area Network) card, a modem, or the like, which performs communication processing via a network such as the Internet; and a drive 908 is also connected to the I / O interface 905 as necessary.

[0164] In particular, according to the embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments of the present application include a computer program carried on a computer-readable medium, which contains program codes for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication section 907. When the computer program is executed by the processor 901, the above-described functions defined in the methods of the present application are performed.

[0165] In the exemplary embodiments, a storage medium including instructions, such as a storage including instructions, is also provided, which can be executed by the processor 901 of the electronic device 900 to complete the above-described methods. Alternatively, the storage medium can be a non-transitory computer-readable storage medium, such as a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, or the like.

[0166] In this application, computer readable storage medium can be any tangible medium that can contain, or store computer readable program codes. In this application, computer readable program codes can include any type of computer readable instructions, i.e., programs, on a tangible media. A computer readable medium can include computer readable storage medium and computer readable signaling medium. In this application, computer readable storage medium can include any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer readable medium can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired computer readable program codes in the form of computer readable instructions, data structures or program modules. Computer readable medium can further include propagated data signals with computer readable program codes embodied therein, e.g., in baseband or as part of a carrier wave. Computer readable signaling medium can include any computer readable medium, except for a propagated data signal.

[0167] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the present application cover any and all variations of the application that come within the scope of the claims and a concept of the application. It is intended that the specification and examples be considered exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0168] It is to be understood that the application is not limited to the precise details of construction and the arrangement of components described above and illustrated in the drawings. The scope of the application should only be limited by the claims appended hereto.

Claims

1. A digital key management method characterized by, Comprising: After the target vehicle has deleted the owner device public key, receiving a digital key activation request initiated by a friend device; Performing signature verification on the digital key activation request to obtain a verification result; in response to the verification result indicating that the verification is passed, obtaining a first public key certificate from the verification result, and sending the first public key certificate to a cloud server, wherein a second public key certificate corresponding to an owner digital key stored by the cloud server is used to verify the first public key certificate; Receiving the verification result of the first public key certificate sent by the cloud server, analyzing the verification result, and determining whether the verification result has activation authority; in the case that the verification result has activation authority, performing trust verification on the first public key certificate, generating activation information, and activating the friend device based on the activation information.

2. The method of claim 1, wherein, The first public key certificate is sent to the cloud server, comprising: Packaging the first public key certificate into a set data format; Through a network link between the target vehicle and the cloud server, the first public key certificate in the data format is sent.

3. The method of claim 1, wherein, Also comprising: The verification result is obtained by the cloud server using the second public key certificate of the owner device in the signature verification state to verify the signature of the first public key certificate.

4. The method of claim 1, wherein, The trust verification on the first public key certificate and the generation of the activation information, comprising: According to the preset verification rule, the trust verification on the first public key certificate is performed to obtain a verification result; If the verification result indicates that the first public key certificate passes the trust verification, the activation information is generated; If the verification result indicates that the first public key certificate does not pass the trust verification, a response of rejecting activation is fed back to the friend device; The preset verification rule comprises: The certificate chain of the first public key certificate is traceable to a trusted root certificate authority; The first public key certificate is within the valid period; The first public key certificate is not in the revoked state.

5. The method of claim 1, wherein, The target vehicle deletes the owner device public key, comprising: Receiving the owner digital key deletion instruction issued by the cloud server, wherein the owner digital key deletion instruction is obtained based on the owner device initiating an owner digital key deletion request to the cloud server, and the owner digital key deletion request is obtained based on the owner device deleting the stored owner device public and private key pair; According to the owner digital key deletion instruction, delete the owner device public key stored by the target vehicle.

6. The method of claim 1, wherein, Also comprising: In response to the target vehicle not deleting the owner device public key, receiving a digital key activation request initiated by a friend device; Performing trust verification on the digital key activation request, and in the case that the trust verification is passed, authorizing the activation of the friend device.

7. A digital key management method characterized by, Comprising: Receiving an owner digital key deletion request initiated by an owner device; The owner digital key deletion instruction is determined according to the owner digital key deletion request, and the owner digital key deletion instruction is sent to the target vehicle, wherein the owner device performs owner device public key deletion based on the owner digital key deletion instruction; after the target vehicle has deleted the owner device public key, a first public key certificate sent by the friend device is received, wherein the first public key certificate is obtained by a digital key activation request initiated by the friend device; The signature of the first public key certificate is verified by the stored second public key certificate in the only verification state, a verification result is obtained, and the verification result is sent to the friend device, wherein the second public key certificate corresponds to the owner digital key.

8. The method of claim 7, wherein, Also includes: If the owner device completes the sharing operation, the number of unactivated friend digital keys is non-zero, and the state of the owner device public key is deleted, the state of the second public key certificate is configured as only verification; If the owner device completes the sharing operation, the number of unactivated friend digital keys is zero, and the state of the owner device public key is deleted, the state of the second public key certificate is configured as deleted; If the state of the owner digital key of the owner device is in use, the state of the second public key certificate is configured as in use.

9. A digital key management apparatus characterized by comprising: Includes: The first receiving module is used to receive the digital key activation request initiated by the friend device after the target vehicle has deleted the owner device public key; The sending module is used to verify the signature of the digital key activation request to obtain a verification result; in response to the verification result indicating that the verification is passed, a first public key certificate is obtained from the verification result, and the first public key certificate is sent to the cloud server, wherein the second public key certificate corresponding to the owner digital key stored by the cloud server verifies 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, analyze the verification result, and determine whether the verification result has activation authority; in the case that the verification result has activation authority, the first public key certificate is authenticated, activation information is generated, and the friend device is activated based on the activation information.

10. A digital key management apparatus characterized by comprising: Includes: The second receiving module is used to receive the owner digital key deletion request initiated by the owner device; The owner digital key deletion instruction is determined according to the owner digital key deletion request, and the owner digital key deletion instruction is sent to the target vehicle, wherein the owner device performs owner device public key deletion based on the owner digital key deletion instruction; after the target vehicle has deleted the owner device public key, a first public key certificate sent by the friend device is received, wherein the first public key certificate is obtained by a digital key activation request initiated by the friend device; The second activation module is used to verify the signature of the first public key certificate by the stored second public key certificate in the only verification state, obtain a verification result, and send the verification result to the friend device, wherein the second public key certificate corresponds to the owner digital key.

11. An electronic device, comprising: Includes: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method of any one of claims 1-6 or 7-8.

12. A non-transitory computer-readable storage medium, comprising: The instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the method of any one of claims 1-6 or 7-8.

13. A computer program product, characterised in that, A computer program comprising instructions which, when executed by a processor, implement the method of any one of claims 1-6 or 7-8.

Images