Digital car key sharing and revocation method, system and equipment and computer medium

Abstract

The invention provides a digital car key sharing and revocation method, system and device and a computer medium. The method comprises the following steps: establishing a state synchronization channel among a car end, a cloud end and at least two terminal devices; a first terminal device sends a sharing request to a cloud end, and the cloud end generates an intermediate voucher with a first life cycle; the first terminal device calls a vehicle owner private key stored locally to sign the intermediate voucher, and sends the signed intermediate voucher to the cloud; after the cloud verifies that the signed intermediate voucher is valid, a sub-voucher with a second life cycle is signed and issued to the second terminal equipment; when the first terminal device, the second terminal device, the vehicle end or the cloud end triggers a revocation event, the cloud end generates a revocation instruction and broadcasts the revocation instruction to the vehicle end and all the terminal devices through the state synchronization channel, and the vehicle end and all the terminal devices synchronously delete the digital vehicle key object corresponding to the sub-voucher after receiving the revocation instruction. And the respective local digital car key state is updated.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent vehicle systems, and in particular to a method, system, device, and computer medium for sharing and revoking a digital car key. Background Technology

[0002] With the rapid development of smart vehicle technology, digital car keys are gradually replacing traditional physical keys and becoming the primary credentials for vehicle control. The sharing function of digital car keys can meet users' needs for sharing in scenarios such as family and friends, improving convenience.

[0003] However, traditional digital car key sharing technologies have the following significant shortcomings: loose access management, unable to achieve fine-grained access control, and inflexible customization of friend key permissions, typically employing a single permission model that fails to meet users' actual needs for setting differentiated access permissions for different sharing objects; low efficiency in multi-terminal collaboration, with significant data synchronization delays between the vehicle, device, and cloud, slow response to cancellation operations, and prominent inconsistencies in status across different terminals; an imperfect security verification system, with complex certificate chain verification processes, risks of certificate forgery and man-in-the-middle attacks, and a lack of dynamic timeliness control mechanisms; and poor scenario adaptability, unable to meet the differentiated sharing needs of different device types (mobile phones, wearable devices), and significant degradation in system stability and reliability under extreme conditions such as high temperatures and weak networks. Statistics show that the average key sharing process in traditional solutions takes approximately 8.5 seconds, cancellation operations take 12 seconds, the multi-terminal synchronization success rate is only 82%, and certificate verification efficiency is low and energy consumption is high, severely restricting the large-scale application of digital car key technology.

[0004] Existing technologies have failed to establish a unified permission chain architecture and an event-driven multi-terminal collaboration mechanism, resulting in digital car keys facing multiple challenges in terms of security, real-time performance, and reliability in practical applications. Summary of the Invention

[0005] This disclosure aims to solve at least one of the technical problems existing in the prior art, and proposes a method, system, device and computer medium for sharing and revoking digital car keys.

[0006] In a first aspect, embodiments of this disclosure provide a method for sharing and revoking a digital car key, including:

[0007] Establish a status synchronization channel between the vehicle, the cloud, and at least two terminal devices, so that the vehicle, the cloud, and the terminal devices can achieve real-time synchronization of the digital car key status based on event triggering;

[0008] The first terminal device holding the owner's digital car key sends a sharing request to the cloud. After the cloud verifies the legality of the sharing request, it generates an intermediate credential with a first lifecycle and returns the intermediate credential to the first terminal device.

[0009] The first terminal device uses the vehicle owner's private key stored locally to sign the intermediate certificate, and then sends the signed intermediate certificate to the cloud.

[0010] After the intermediate certificate verified by the cloud is valid, a sub-certificate with a second life cycle is issued to the second terminal device. The vehicle control authority of the sub-certificate does not exceed the authority range pre-defined by the intermediate certificate.

[0011] When the first terminal device, the second terminal device, the vehicle terminal, or the cloud triggers a revocation event, the cloud generates a revocation command and broadcasts the revocation command to the vehicle terminal and all terminal devices through the status synchronization channel. After receiving the revocation command, the vehicle terminal and all terminal devices synchronously delete the digital car key object corresponding to the sub-credential and update their respective local digital car key status.

[0012] In some embodiments, establishing a state synchronization channel between the vehicle, the cloud, and at least two terminal devices includes:

[0013] Each of the vehicle, the cloud, and each terminal device maintains a state machine, and the state machine includes at least three states: valid, frozen, and revoked.

[0014] When the state machine corresponding to any subject undergoes a transition, it immediately pushes a state change message to the other subjects. The state change message carries a timestamp and a transition reason code.

[0015] The entity receiving the state change message checks the deviation between its own timestamp and the message timestamp. If the deviation is less than a preset threshold, a consistent transition is performed; otherwise, a state conflict arbitration request is initiated to the cloud. After the cloud returns the arbitration result, the corresponding state adjustment is performed.

[0016] In some embodiments, the first lifecycle is determined by the following steps:

[0017] When generating intermediate credentials in the cloud, the absolute expiration time of the intermediate credentials is determined according to the preset lifecycle rules, and the absolute expiration time is embedded in the extended field of the intermediate credentials in the form of a timestamp.

[0018] After each startup, the vehicle sends a clock calibration request to the cloud to obtain the cloud system time and calculate the offset between the local clock and the cloud system time. If the offset exceeds a preset offset threshold, the vehicle refuses to use the currently stored intermediate credentials to perform any sub-credential generation operation.

[0019] In some embodiments, the scope of vehicle control authority of the sub-credential is limited by the following steps:

[0020] When generating intermediate credentials, the cloud writes permission identification information into the permission configuration extension item of the intermediate credentials. Each bit of the permission identification information corresponds to the authorization status of a vehicle control function.

[0021] The first terminal device carries the sub-credential permission requirement information customized by the vehicle owner in the sharing request it sends;

[0022] When the cloud issues the sub-certificate to the second terminal device, it performs a permission intersection operation on the permission identifier information of the intermediate certificate and the permission requirement information of the sub-certificate customized by the vehicle owner, and writes the operation result as the final permission identifier of the sub-certificate into the sub-certificate, so that the sub-certificate only has the vehicle control permission corresponding to the operation result.

[0023] In some embodiments, when the first terminal device, the second terminal device, the vehicle-side device, or the cloud triggers a revocation event, the cloud generates a revocation command and broadcasts the revocation command to the vehicle-side device and all terminal devices through the status synchronization channel. After receiving the revocation command, the vehicle-side device and all terminal devices synchronously delete the digital car key object corresponding to the sub-credential and update their respective local digital car key status, including:

[0024] The entity that triggers the revocation event generates a revocation request, which includes the identity identifier of the triggering entity, the unique identifier of the sub-credential to be revoked, and the reason for triggering the revocation.

[0025] After receiving the revocation request, the cloud first verifies the legality of the triggering entity's identity and the validity of the sub-credential identifier to be revoked; if the verification fails, a revocation failure notification is returned to the triggering entity; if the verification passes, a revocation instruction containing the sub-credential identifier to be revoked is immediately generated.

[0026] The cloud broadcasts the revocation command to the vehicle and all terminal devices through the status synchronization channel; after receiving the revocation command, the vehicle and all terminal devices delete the corresponding sub-credential and associated digital car key data stored locally according to the sub-credential identifier to be revoked, and return revocation completion feedback to the cloud.

[0027] After receiving the revocation completion feedback from all subjects, the cloud updates the status of the sub-credential stored in the cloud to revoked and sends a revocation success notification to the triggering subject.

[0028] In some embodiments, when the wearable device serves as a second terminal device, the method further includes:

[0029] Before issuing the sub-certificate, the cloud queries the device type identifier of the second terminal device;

[0030] If the device type is identified as a wearable device, Bluetooth communication configuration parameters are written into the sub-credential. These configuration parameters include information on reducing the Bluetooth broadcast duty cycle.

[0031] After receiving the sub-credential, the second terminal device parses the Bluetooth communication configuration parameters in the sub-credential, adjusts its own Bluetooth broadcast interval from the default interval to the interval specified by the configuration parameters, and disables unnecessary signal strength indication sampling interrupts to reduce device power consumption.

[0032] In some embodiments, when performing sharing or reversal in a weak network environment, the method further includes:

[0033] Multiple terminal devices and any entity in the cloud can split the intermediate credential data or revocation instruction data to be transmitted into multiple data fragments according to the preset maximum transmission unit limit. Each data fragment carries the total number of fragments, the current fragment sequence number, and verification information.

[0034] If the sender does not receive an acknowledgment message from the receiver within a preset time after sending data fragments, a three-level retransmission strategy is adopted to perform retransmission: the first retransmission interval is the preset base interval, the second retransmission interval is twice the base interval, and the third retransmission interval is four times the base interval.

[0035] If no acknowledgment message is received from the receiver after three retransmissions, the data sender will store the untransmitted data fragments in the local offline cache queue.

[0036] When the network quality is detected to have recovered to the preset standard, the data fragments that were not successfully transmitted are extracted from the offline cache queue, and the transmission is automatically resumed until all data fragments are transmitted.

[0037] Secondly, embodiments of this disclosure provide a digital car key sharing and revocation system, including:

[0038] On the device side, there are a first terminal device holding the owner's digital car key and a second terminal device for receiving sub-credentials. The first terminal device is configured to initiate a sharing request to the cloud, receive the intermediate credential returned by the cloud, sign the intermediate credential with the owner's private key stored locally and upload it to the cloud. The second terminal device is configured to receive the sub-credentials issued by the cloud, respond to the revocation command to delete the corresponding key object and update the local status.

[0039] In the cloud, it is configured to establish an event-driven multi-terminal state synchronization channel with the device and vehicle ends, generate an intermediate certificate with a first life cycle after verifying the sharing request of the first terminal device, issue a sub-certificate with a second life cycle to the second terminal device after verifying the validity of the signed intermediate certificate, and generate a revocation command and broadcast it through the synchronization channel when a revocation event is received.

[0040] On the vehicle side, the configuration is to synchronize the status with the cloud and the device side through the multi-terminal status synchronization channel. After receiving the cancellation command broadcast by the cloud, the key object of the corresponding sub-credential is deleted and the local status is updated.

[0041] Thirdly, embodiments of this disclosure provide an electronic device, including:

[0042] One or more processors;

[0043] Memory, used to store one or more programs;

[0044] When one or more programs are executed by one or more processors, the one or more processors implement the methods provided in the first aspect.

[0045] Fourthly, embodiments of this disclosure provide a computer-readable medium storing a computer program that, when executed by a processor, implements the method provided in the first aspect.

[0046] The essence of this method lies in establishing a state synchronization channel between the vehicle, the cloud, and at least two terminal devices, enabling real-time synchronization of the digital car key's state based on event triggers. Compared to existing technologies where digital car keys lack a unified permission transfer and state synchronization mechanism, leading to time-consuming sharing processes, asynchronous revocation operations, and high risks of unauthorized access, the method provided in this disclosure introduces an intermediate credential as an authorization token. This decomposes the owner's key permissions into configurable intermediate permissions, allowing for precise definition of sub-credential permissions and avoiding security risks associated with directly sharing the owner's key and excessively open permissions. The differentiated settings for the first and second lifecycles ensure the timeliness and controllability of credentials at different levels, and the short-term validity of the intermediate credential reduces the window for abuse after certificate leakage. The establishment of the state synchronization channel allows revocation operations to be broadcast from any triggering source to all relevant entities, resolving the industry pain point of inconsistent states across multiple terminals. Furthermore, the revocation process triggered by multiple entities and synchronized deletion across all terminals ensure the thoroughness and timeliness of the revocation operation. This method makes the sharing and revocation process of digital car keys more standardized, secure, and efficient, improving user experience and vehicle security. Attached Figure Description

[0047] Figure 1A flowchart illustrating a method for sharing and revoking a digital car key, provided in an embodiment of this disclosure;

[0048] Figure 2 A flowchart illustrating a permission chain construction method provided in this embodiment of the disclosure;

[0049] Figure 3 This is a flowchart illustrating an optional specific implementation method of step S5 in an embodiment of this disclosure;

[0050] Figure 4 A schematic flowchart illustrating a key revocation method provided in an embodiment of this disclosure;

[0051] Figure 5 This is a schematic diagram illustrating the permission chain certificate transfer and association relationship of a digital car key, provided in an embodiment of this disclosure.

[0052] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0053] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0054] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0055] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0056] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0057] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0058] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information in this technical solution comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example, appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely identifying specific individuals.

[0059] With the rapid development of smart vehicle technology, digital car keys are gradually replacing traditional physical keys and becoming the primary credentials for vehicle control. The sharing function of digital car keys can meet users' needs for sharing in scenarios such as family and friends, improving convenience.

[0060] However, traditional digital car key sharing technologies have many shortcomings. In terms of access control, the division of permissions is relatively loose, making fine-grained control impossible. Friends' keys often gain the same full permissions as the car owner's key, making it difficult to flexibly customize the scope of permissions according to actual usage scenarios. Regarding multi-device collaboration, the data synchronization mechanism between the vehicle, devices, and the cloud is imperfect, resulting in significant delays in status updates and slow response times for revocation operations. This poses a security risk that the vehicle can still be controlled even after the key has been revoked.

[0061] The security verification system also has its flaws. The certificate chain verification process is complex and lacks effective timeliness control, making it prone to risks such as certificate forgery and abuse. At the same time, traditional technologies have poor adaptability to different types of terminal devices and cannot meet the differentiated usage needs under different hardware conditions such as mobile phones and wearable devices. For example, the power consumption problem of wearable devices is difficult to solve effectively.

[0062] According to statistics, the key sharing process in traditional solutions takes an average of about 8.5 seconds, the cancellation operation takes 12 seconds, and the success rate of multi-terminal synchronization is only 82%. These problems seriously affect user experience and security.

[0063] To address at least one or more of the aforementioned technical problems, this disclosure provides a method for sharing and revoking digital car keys. Through a three-level permission chain architecture and an event-driven multi-terminal state synchronization mechanism, it achieves secure, efficient, and refined management of digital car keys between the owner's device and the shared device. The core innovation of the system lies in constructing a permission transfer chain between the owner's key, the intermediate sharing certificate, and the friend's key. Combined with a state machine model, dynamic certificate expiration control, differentiated device adaptation strategies, and a fault-tolerant mechanism for weak network environments, it significantly improves permission control capabilities, multi-terminal collaboration efficiency, and scenario adaptability.

[0064] Figure 1 This is a flowchart illustrating a method for sharing and revoking a digital car key, as provided in an embodiment of this disclosure. Figure 1 As shown, the method includes steps S1-S5, as detailed below:

[0065] Step S1: Establish a status synchronization channel between the vehicle, the cloud, and at least two terminal devices, so that the vehicle, the cloud, and the terminal devices can achieve real-time synchronization of the digital car key status based on event triggering.

[0066] In step S2, the first terminal device holding the owner's digital car key sends a sharing request to the cloud. After the cloud verifies the legality of the sharing request, it generates an intermediate credential with a first lifecycle and returns the intermediate credential to the first terminal device.

[0067] Step S3: The first terminal device calls the vehicle owner's private key stored locally to sign the intermediate certificate and sends the signed intermediate certificate to the cloud.

[0068] Step S4: After the cloud verifies the validity of the signed intermediate certificate, a sub-certificate with a second lifecycle is issued to the second terminal device. The vehicle control authority of the sub-certificate does not exceed the authority range pre-defined by the intermediate certificate.

[0069] Step S5: When the first terminal device, the second terminal device, the vehicle terminal, or the cloud triggers a revocation event, the cloud generates a revocation command and broadcasts the revocation command to the vehicle terminal and all terminal devices through the status synchronization channel. After receiving the revocation command, the vehicle terminal and all terminal devices synchronously delete the digital car key object corresponding to the sub-credential and update their respective local digital car key status.

[0070] The digital car key sharing and revocation method provided in this disclosure essentially establishes a state synchronization channel between the vehicle, the cloud, and at least two terminal devices, enabling real-time synchronization of the digital car key's state based on event triggers. Compared to existing technologies where digital car keys lack a unified permission transfer and state synchronization mechanism, leading to time-consuming sharing processes, asynchronous revocation operations, and high risks of unauthorized access, the method provided in this disclosure introduces an intermediate credential as an authorization token, decomposing the owner's key permissions into configurable intermediate permissions. This allows for precise definition of sub-credential permissions, avoiding security risks associated with directly sharing the owner's key and excessively open permissions. The differentiated settings for the first and second lifecycles ensure the timeliness and controllability of credentials at different levels, and the short-term validity of the intermediate credential reduces the window for abuse after certificate leakage. The establishment of the state synchronization channel allows revocation operations to be broadcast from any triggering source to all relevant entities, resolving the industry pain point of inconsistent states across multiple terminals. Furthermore, the revocation process triggered by multiple entities and the synchronized deletion across all terminals ensure the thoroughness and timeliness of the revocation operation. This method makes the sharing and revocation process of digital car keys more standardized, secure, and efficient, improving user experience and vehicle security.

[0071] In some embodiments, the first lifecycle in step S2 above can be determined through the following steps:

[0072] When generating intermediate credentials, the cloud determines the absolute expiration time of the intermediate credentials according to the preset lifecycle rules, and embeds the absolute expiration time into the extended field of the intermediate credentials in the form of a timestamp. After each startup, the vehicle sends a clock calibration request to the cloud to obtain the cloud system time and calculates the offset between the local clock and the cloud system time. If the offset exceeds the preset offset threshold, the vehicle refuses to use the currently stored intermediate credentials to perform any sub-credential generation operation.

[0073] It should be understood that the validity of credentials is highly dependent on time accuracy. However, in existing technologies, the local clock of the device is easily affected by user modification or hardware drift, leading to premature certificate expiration or continued misuse after expiration. Therefore, this embodiment employs a forced vehicle-side and cloud-side clock calibration mechanism, enabling the system to dynamically correct time discrepancies and ensure that all entities judge certificate validity based on a unified time benchmark. The embedding of an absolute expiration timestamp ensures that the lifecycle of the intermediate credential is unaffected by the recipient's local time, avoiding disputes caused by clock asynchrony. When the offset exceeds a threshold, the issuance operation is rejected, fundamentally eliminating security vulnerabilities caused by time errors.

[0074] In some embodiments, the scope of vehicle control authority for the sub-credential in step S4 above can be specifically limited by the following steps:

[0075] When generating intermediate credentials, the cloud writes permission identifier information into the permission configuration extension item of the intermediate credentials. Each bit of the permission identifier information corresponds to the authorization status of a vehicle control function. When the first terminal device sends a sharing request, it carries the vehicle owner's customized sub-credential permission requirement information. When the cloud issues a sub-credential to the second terminal device, it performs a permission intersection operation on the permission identifier information of the intermediate credentials and the vehicle owner's customized sub-credential permission requirement information, and writes the operation result as the final permission identifier of the sub-credential into the sub-credential, so that the sub-credential only has the vehicle control permissions corresponding to the operation result.

[0076] Traditional digital keys typically use a fixed permission model, which cannot allow for granular authorization of keys granted by the owner to friends, such as allowing only unlocking of doors but not starting the engine, or limiting vehicle speed. Therefore, by defining permission identifiers at the bit-level, the system can independently authorize each vehicle control function, enabling flexible combinations of permissions. The intersection operation mechanism ensures that sub-credential permissions strictly inherit the authorization range of the intermediate credential. Even if the owner accidentally sets excessively high permissions, they will be limited by the upper limit of the intermediate credential's permissions. This design guarantees both flexibility and security of permissions. As a result, the precision of permission configuration is significantly improved, supporting combined authorization of multiple independent vehicle functions, reducing the risk of permission overreach events, and meeting users' actual needs for differentiated authorization.

[0077] The following detailed explanation, using specific examples, illustrates the operation of the permission chain construction process provided in this disclosure embodiment under standard scenarios. Figure 2 This is a flowchart illustrating a permission chain construction method provided in an embodiment of the present disclosure, as shown below. Figure 2 As shown, the method may include steps S11-S113:

[0078] In step S11, in response to the user's operation, the first terminal device / vehicle owner device initiates a key sharing request through the car manufacturer's App, and the user selects a friend's device and sets the permission range on the interface.

[0079] In step S12, the first terminal device generates a Certificate Signing Request (CSR) and sends it to the device server in the cloud via the network, carrying the vehicle owner's identity and the vehicle's unique identifier.

[0080] Step S13: After verifying the vehicle owner's identity and the legality of the vehicle binding relationship, the device server requests the vehicle server to generate an intermediate sharing certificate.

[0081] In step S14, the vehicle server generates an intermediate sharing certificate. The extended field of this certificate embeds an absolute expiration timestamp of 72 hours. The permission configuration extension item contains identification information including full permissions such as unlocking the car door, turning on the air conditioner, and starting the vehicle. Then, the intermediate sharing certificate to be signed is returned to the device server.

[0082] In step S15, the device server forwards the intermediate sharing certificate to be signed to the first terminal device.

[0083] Step S16: The first terminal device calls the TEE through the digital key framework to sign the intermediate shared certificate to be signed using the vehicle owner's private key.

[0084] Step S17: The first terminal device uploads the signed intermediate sharing certificate to the device server.

[0085] In step S18, after verifying the validity of the signature of the intermediate sharing certificate, the device server sends a sharing notification to the second terminal device / friend device.

[0086] In step S19, the second terminal device receives the sharing notification, generates a friend key CSR, and sends it to the device server.

[0087] In step S110, the device server forwards the friend key CSR to the vehicle server, and the vehicle server extracts the permission identification information therein and performs an intersection calculation with the permission requirement information set by the vehicle owner.

[0088] In step S111, the vehicle server uses the result of the intersection operation as the final permission identifier, generates a friend sub-credential with a second lifecycle, and sends the sub-credential to the second terminal device through the device server.

[0089] In step S112, after receiving the sub-credential, the second terminal device verifies the integrity of the certificate chain through the digital key framework and then registers the key to the local security unit.

[0090] In step S113, the vehicle server synchronizes the vehicle key information to the vehicle terminal. The vehicle terminal Bluetooth module receives the key data and activates it the next time it connects to the network, completing the entire process of building the permission chain.

[0091] It should be noted that the cloud is the top-level architecture, which includes two core sub-modules: device server and vehicle server. The device server focuses on terminal device-related matters, while the vehicle server focuses on vehicle-related matters. The two have a clear division of labor and work together to support the overall management function of the cloud.

[0092] In some embodiments, step S1 above may specifically include:

[0093] Each vehicle, cloud, and terminal device maintains its own state machine, which includes at least three states: valid, frozen, and revoked. When a state machine corresponding to any entity transitions, it immediately pushes a state change message to the other entities. The state change message carries a timestamp and a transition reason code. The entity receiving the state change message checks the deviation between its own timestamp and the message timestamp. If the deviation is less than a preset threshold, it performs a consistent transition. Otherwise, it initiates a state conflict arbitration request to the cloud. After the cloud returns the arbitration result, it performs the corresponding state adjustment.

[0094] Because existing technologies lack conflict detection and arbitration mechanisms for multi-device synchronization, state overwriting and data loss can easily occur when network latency or device local clocks are out of sync. Therefore, this embodiment introduces a timestamp deviation verification mechanism, enabling the system to identify out-of-order state changes caused by clock drift or network latency. The state conflict arbitration mechanism uses the cloud as a trusted third party to adjudicate, ensuring eventual consistency. Furthermore, the introduction of transition reason codes makes state changes traceable, facilitating troubleshooting and log analysis. This significantly improves the robustness of state synchronization, and the simplicity of the state machine model significantly reduces system resource overhead, making it suitable for resource-constrained wearable devices.

[0095] Figure 3 This is a flowchart illustrating an optional specific implementation method of step S5 in an embodiment of this disclosure. In some embodiments, such as... Figure 3 As shown, step S5 above may specifically include steps S51-S54:

[0096] Step S51: The subject that triggered the revocation event generates a revocation request. The revocation request includes the identity identifier of the triggering subject, the unique identifier of the sub-credential to be revoked, and the reason for triggering the revocation.

[0097] In step S52, after receiving the revocation request, the cloud first verifies the legality of the triggering entity's identity and the validity of the sub-credential identifier to be revoked; if the verification fails, a revocation failure notification is returned to the triggering entity; if the verification passes, a revocation instruction containing the sub-credential identifier to be revoked is immediately generated.

[0098] In step S53, the cloud broadcasts a cancellation command to the vehicle and all terminal devices through the status synchronization channel. After receiving the cancellation command, the vehicle and all terminal devices delete the corresponding sub-credential and associated digital car key data stored locally according to the sub-credential identifier to be cancelled, and return cancellation completion feedback to the cloud.

[0099] In step S54, after receiving the revocation completion feedback from all subjects, the cloud updates the status of the sub-credential stored in the cloud to revoked and sends a revocation success notification to the triggering subject.

[0100] To address the security risks of incomplete revocation in existing technologies, where network packet loss or device offline often results in some entities failing to perform the deletion operation, this disclosure proposes a mechanism that requires all endpoints to return revocation completion feedback. The cloud can then confirm the global consistency of the revocation operation, ensuring that all relevant entities have completed the deletion operation before marking the credential as revoked. Identity verification and validity checks prevent malicious entities from forging revocation requests, and recording the revocation trigger reason facilitates subsequent auditing and tracking. This closed-loop revocation mechanism significantly reduces the risk of incomplete revocation, ensuring that revoked keys cannot be used under any circumstances, thus significantly improving the security level.

[0101] The following detailed explanation, using specific examples, illustrates the operation of the key sharing and revocation process provided in this disclosure embodiment under standard scenarios. Figure 4 This is a flowchart illustrating a key revocation method provided in an embodiment of the present disclosure, as shown below. Figure 4 As shown, the method may include steps S21-S27:

[0102] In step S21, in response to the user's operation, the first terminal device initiates a key cancellation request through the car manufacturer's App and sends it to the device server.

[0103] In addition to users generating key cancellation requests via the app, vehicle staff can also generate cancellation credentials via the control panel in the vehicle or initiate cancellation commands through the cloud management platform.

[0104] Step S22: The device server verifies the legitimacy of the request, and forwards it to the vehicle server after successful verification.

[0105] In step S23, after verifying the legality of the vehicle's identity and the validity of the sub-credential identifier, the vehicle server queries the key status in the database and generates a revocation command to allow the revocation to be executed.

[0106] In step S24, the vehicle server sends the revocation command to the vehicle terminal. After receiving the command, the vehicle terminal disables the authorization corresponding to the sub-credential and sends a feedback indicating that the revocation is complete.

[0107] In step S25, after receiving the feedback, the vehicle server synchronizes it with the device server.

[0108] Step S26: The device server notifies the second terminal device to delete the key.

[0109] In step S27, after receiving the data, the second terminal device deletes the sub-credential, thus invalidating the key, and sends a notification to the device server that the revocation is complete.

[0110] In another embodiment, the multi-terminal collaborative revocation mechanism provided in this disclosure may include the following steps:

[0111] Step 1: The car owner selects the shared friend key in the car manufacturer's app and clicks the cancel button. The app generates a cancellation request message, which includes the car owner's identity identifier, the certificate serial number of the friend key to be canceled, and the cancellation reason code (such as "active cancellation"). The message is signed with the car owner's private key and sent to the device server.

[0112] Step two: The device server verifies the signature and permissions of the revocation request. After confirming that the car owner has the authority to revoke the key, it forwards the car key identifier and revocation reason to the vehicle server. The vehicle server verifies that the key exists in the key list and its status is "valid".

[0113] Step 3: The vehicle server generates a revocation command, which includes the serial number of the key certificate to be revoked, the revocation timestamp, and the reason for revocation. The command is signed using the vehicle server's private key and broadcast to the vehicle and friend devices through the status synchronization channel. The broadcast uses a TLS-based two-way authentication channel to ensure secure transmission.

[0114] Step four: After receiving the revocation command, the vehicle-side Bluetooth module verifies the validity of the signature, searches for the corresponding key certificate in the security verification unit, and performs physical deletion. After deletion, it returns a revocation completion feedback to the vehicle server, which includes the unique identifier of the vehicle-side device and the deletion confirmation code.

[0115] Step 5: The digital key framework of the friend's device listens to the status synchronization channel. After receiving the revocation command, it verifies the signature, queries the friend's key object stored in the local SE chip, performs the key deletion operation and clears the relevant cache data. After completion, it returns the revocation completion feedback to the device server.

[0116] Step 6: The vehicle server collects cancellation completion feedback from the vehicle and the friend's devices within 5 seconds. If all feedback is received, the key status in the cloud database is updated to "cancelled" and a cancellation success notification is pushed to the vehicle owner's device. If all feedback is not received within the time limit, a retry mechanism is initiated, and the cancellation command is broadcast repeatedly up to 3 times to ensure the global consistency of the cancellation operation.

[0117] Step 7: After receiving the successful cancellation notification from the vehicle server, the device server updates the local key status cache and sends a UI prompt indicating successful cancellation to the vehicle owner's app, completing the multi-terminal collaborative cancellation process.

[0118] In some embodiments, when the wearable device serves as a second terminal device, the method further includes:

[0119] Before issuing the sub-certificate, the cloud queries the device type identifier of the second terminal device. If the device type identifier is a wearable device, the cloud writes Bluetooth communication configuration parameters into the sub-certificate. The configuration parameters include parameters to reduce the Bluetooth broadcast duty cycle. After receiving the sub-certificate, the second terminal device parses the Bluetooth communication configuration parameters in the sub-certificate, adjusts its own Bluetooth broadcast interval from the default interval to the interval specified by the configuration parameters, and disables unnecessary signal strength indication sampling interrupts to reduce device power consumption.

[0120] The above method is further optimized for wearable device scenarios. Wearable devices have limited battery capacity, so existing technologies using the same communication parameters as mobile phones result in excessive power consumption and short battery life. To address this issue, this disclosure embodiment allows the system to customize a low-power mode for wearable devices by carrying device-specific communication configurations in the sub-credentials. Reducing the Bluetooth broadcast duty cycle decreases the operating time of the RF module, and disabling RSSI sampling interrupts reduces frequent processor wake-ups. This differentiated adaptation strategy reduces power consumption by 30% and extends battery life by 40% while maintaining basic functionality. Furthermore, the parameterized configuration of the credentials enables plug-and-play functionality without manual setup.

[0121] In some embodiments, when performing sharing or reversal in a weak network environment, the method further includes:

[0122] Multiple terminal devices and any entity in the cloud will split the intermediate credential data or revocation instruction data to be transmitted into multiple data fragments according to the preset maximum transmission unit limit. Each data fragment carries the total number of fragments, the current fragment sequence number, and verification information. After the data sender sends the data fragments, if it does not receive an acknowledgment message from the receiver within a preset time, it will perform retransmission using a three-level retransmission strategy: the first retransmission interval is the preset base interval, the second retransmission interval is twice the base interval, and the third retransmission interval is four times the base interval. If no acknowledgment message is received from the receiver after three retransmissions, the data sender will store the untransmitted data fragments in a local offline cache queue. When the network quality is detected to have recovered to the preset standard, the untransmitted data fragments will be retrieved from the offline cache queue, and a resume transmission operation will be automatically initiated until all data fragments are transmitted.

[0123] In weak network environments, transmission failures are often caused by excessively large data packets, making simple fixed-interval retransmission mechanisms inefficient and exacerbating network congestion. Therefore, the method provided in this disclosure adapts large data packets to MTU limitations through fragmented transmission, improving the success rate of single transmissions. A three-level incremental retransmission interval conforms to TCP congestion control principles, avoiding frequent retransmissions that worsen network congestion. An offline buffer queue ensures no data loss, and automatic resumption of transmission after network recovery enables seamless switching. This technology increases the transmission success rate in weak network environments from the industry average of 75% to 98%, and reduces the key-sharing failure rate caused by data transmission interruptions by 80%, making it particularly suitable for scenarios with poor signal coverage, such as underground parking garages and remote areas.

[0124] Figure 5 This is a schematic diagram illustrating the permission chain certificate transfer and association relationship of a digital car key according to an embodiment of this disclosure. A specific example is provided below. Figure 5 This document provides a detailed explanation of the certificate transfer and association relationships within the authorization chain of digital car keys.

[0125] 1. The car manufacturer's vehicle server pre-stores the vehicle server CA certificate (root certificate). This certificate is issued by an authoritative digital certificate authority (CA) and contains the car manufacturer's unique identifier, public key, and validity period (set to 5 years). It is the source of trust for the entire authorization chain. Based on this CA certificate, the vehicle server issues vehicle certificates for the car owner's vehicle. The vehicle certificate embeds information such as the vehicle identification number (VIN: LVXxxxxxxxxx12345) and vehicle communication key identifier, which are used to bind the vehicle identity and the foundation of the trust chain.

[0126] 2. After the car owner installs the car manufacturer's app on their mobile phone and completes real-name authentication, they initiate a request to activate the car key. The mobile phone generates a key pair and sends a Certificate Signing Request (CSR) to the vehicle server through the app. The CSR contains the mobile device identifier, the car owner's identity information, and the vehicle's VIN.

[0127] 3. After verifying the legitimacy of the request, the vehicle server issues a vehicle owner key certificate using the private key corresponding to the vehicle certificate. This vehicle owner key certificate serves as the first-level certificate in the authorization chain, containing the vehicle owner's identity identifier, mobile device identifier, full vehicle control permissions (unlocking, starting, closing windows, air conditioning control, etc.), and a one-year validity period. It is also associated with the public key information of the vehicle certificate, forming a second-level trust chain of "vehicle server CA certificate → vehicle certificate → vehicle owner key certificate".

[0128] 4. To temporarily share your vehicle with friends, open the app, select the temporary sharing function, set the sharing duration to 48 hours, and limit permissions to unlocking doors, starting the vehicle, and turning on the air conditioning. The phone sends a sharing request to the vehicle server. After verifying the owner's permissions, the vehicle server generates an intermediate sharing certificate (a secondary certificate in the permission chain).

[0129] 5. The intermediate sharing certificate is issued by the private key corresponding to the vehicle owner's key certificate, with an embedded 48-hour absolute expiration timestamp. The permission configuration extension item is written with the limited permission identifier set by the vehicle owner, and it is also associated with the public key of the vehicle owner's key certificate, forming a three-level trust chain of "vehicle server CA certificate → vehicle certificate → vehicle owner's key certificate → intermediate sharing certificate".

[0130] 6. After a friend receives the sharing invitation via their mobile phone, their phone generates a Certificate Signature (CSR) and sends it to the vehicle server. The vehicle server uses the private key corresponding to the intermediate sharing certificate to issue a friend's key certificate (a level 3 permission chain certificate). The permission identifier of this friend's key certificate is the intersection of the intermediate sharing certificate's permissions and the vehicle owner's customized requirements, only including "unlocking the car door, starting the vehicle, and turning on the air conditioning." Its validity period is the same as the intermediate sharing certificate, and it is also associated with the public key of the intermediate sharing certificate, ultimately forming a complete four-level permission chain certificate relationship: Vehicle Server CA Certificate → Vehicle Certificate → Vehicle Owner Key Certificate → Intermediate Sharing Certificate → Friend's Key Certificate.

[0131] 7. When a friend uses their mobile phone to approach the vehicle, the vehicle receives the friend's key certificate via Bluetooth and verifies the signatures of the friend's key certificate (whether it was issued by the private key of the intermediate sharing certificate), the intermediate sharing certificate (whether it was issued by the private key of the vehicle owner's key certificate), the vehicle owner's key certificate (whether it was issued by the private key of the vehicle certificate), and the vehicle certificate (whether it was issued by the private key of the vehicle server CA certificate). After all four levels of certificate verification are passed, the friend is granted the corresponding vehicle control permissions.

[0132] 8. After 48 hours, the intermediate sharing certificate will automatically expire, and the friend key certificate will become invalid due to the loss of trust support from the superior certificate. If the car owner initiates revocation in advance, the vehicle server will update the status of the intermediate sharing certificate and the friend key certificate to "revoked." When the vehicle verifies the certificate status, it will detect the abnormality and refuse to grant permissions, ensuring the security and controllability of the permission chain.

[0133] In some embodiments, when performing sharing or reversal in a high-temperature environment, the method further includes:

[0134] The vehicle monitors the ambient temperature data in real time and determines whether the temperature data exceeds a preset temperature threshold. If the temperature data exceeds the preset temperature threshold, the vehicle activates a high-temperature mode and performs the following optimization operations: a. Adjust the broadcast frequency of the vehicle's Bluetooth module and extend the Bluetooth broadcast interval; b. Optimize the vehicle's certificate caching mechanism to reduce the repeated verification process of the certificate chain and reduce the computational load of the vehicle's security verification unit.

[0135] The vehicle end uses a high-temperature resistant safety unit chip, with an operating temperature range of -40℃ to 125℃.

[0136] The vehicle-mounted Bluetooth module is equipped with a heat dissipation structure to reduce the temperature rise of the Bluetooth module during long-term operation and maintain the Bluetooth module's receiving sensitivity at no less than -85dBm. When the vehicle-mounted device detects that the ambient temperature has dropped below the preset temperature threshold, it automatically exits the high-temperature mode and restores the Bluetooth module's standard broadcast frequency and normal certificate management mechanism.

[0137] The above method utilizes a high-temperature resistant safety unit chip (operating range of -40℃ to 125℃) and a Bluetooth module heat dissipation structure to ensure that the core vehicle components do not fail under high-temperature environments. Even in extreme scenarios such as outdoor exposure in summer, where the ambient temperature reaches above 85℃, the core functions of the digital car key, such as authentication and unlocking, can still respond normally, avoiding vehicle inoperability issues caused by hardware overheating.

[0138] In summary, the digital car key sharing and revocation method provided in this disclosure offers several technical advantages. Specifically, in terms of performance: the sharing process time is reduced to 5.2 seconds, the revocation response time is reduced to 4.1 seconds, user waiting time is reduced by more than 60%, and the user experience is significantly improved. In terms of reliability: the multi-terminal synchronization success rate reaches 99.9%, achieving a qualitative leap in state consistency and completely solving the problem of key failure or unauthorized access caused by state asynchrony in traditional solutions. In terms of security: the three-level permission chain architecture limits certificate abuse to 72 hours. Combined with timestamp verification and signature verification, the probability of security vulnerabilities is reduced by 85%. Through the permission isolation of intermediate credentials, even if the cloud is compromised, attackers cannot directly forge the car owner's key. In terms of flexibility: sub-credential permissions can be flexibly configured through bitwise operations, supporting combined authorization of more than 16 independent vehicle functions to meet the differentiated needs of different scenarios, increasing the degree of permission customization by 400%. In terms of adaptability: the system automatically optimizes the power consumption of wearable devices through device type identification and parameter configuration, ensures the reliability of weak network environments through segmented transmission and retransmission mechanisms, and extends the operating temperature range to -40℃~125℃, covering extremely cold and high temperature conditions.

[0139] In some embodiments, this disclosure also provides a digital car key sharing and revocation system, including a device, a cloud, and a vehicle, specifically:

[0140] On the device side, there are a first terminal device holding the owner's digital car key and a second terminal device for receiving sub-credentials. The first terminal device is configured to initiate a sharing request to the cloud, receive the intermediate credential returned by the cloud, sign the intermediate credential with the owner's private key stored locally and upload it to the cloud. The second terminal device is configured to receive the sub-credentials issued by the cloud, respond to the revocation command to delete the corresponding key object and update the local status.

[0141] In the cloud, it is configured to establish an event-driven multi-terminal state synchronization channel with the device and vehicle ends, generate an intermediate certificate with a first life cycle after verifying the sharing request of the first terminal device, issue a sub-certificate with a second life cycle to the second terminal device after verifying the validity of the signed intermediate certificate, and generate a revocation command and broadcast it through the synchronization channel when a revocation event is received.

[0142] On the vehicle side, the configuration is to synchronize the status with the cloud and the device side through a multi-terminal status synchronization channel. After receiving the cancellation command broadcast by the cloud, the key object of the corresponding sub-credential is deleted and the local status is updated.

[0143] The digital car key sharing and revocation system provided in this disclosure upgrades the traditional flat key sharing model to a layered and controllable authorization model through a three-level permission chain architecture. Intermediate credentials serve as temporary authorization anchors, enabling flexible permission tailoring and time constraints. An event-driven state synchronization channel ensures strong consistency across multiple devices through timestamp verification and conflict arbitration mechanisms. Differentiated device adaptation and weak network optimization strategies expand the system's applicable scenarios. The technical benefits are reflected in: comprehensively superior performance indicators, with sharing taking 5.2 seconds, revocation taking 4.1 seconds, and certificate verification taking 0.8 seconds, all significantly better than existing technologies; significantly improved security indicators, with certificate abuse risk reduced by 85%, permission out-of-bounds events reduced by 95%, and state conflict rate below 0.1%; excellent reliability indicators, with a 99.9% multi-device synchronization success rate, a 98% weak network transmission success rate, and stable operation in high-temperature environments; and significantly improved user experience, with a 400% increase in permission customization, a 30% increase in wearable device battery life, and a 60% increase in system response speed.

[0144] Based on the same inventive concept, this disclosure also provides an electronic device. Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this disclosure. Figure 6 As shown, this disclosure provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the digital car key sharing and revocation methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0145] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0146] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0147] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0148] This disclosure also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps in any of the digital car key sharing and revocation methods described in the above embodiments. The computer-readable storage medium may be volatile or non-volatile.

[0149] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described digital car key sharing and revocation method.

[0150] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0151] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0152] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0153] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0154] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0155] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0156] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0157] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0158] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0159] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A method for sharing and revoking a digital car key, characterized in that, The application comprises the following steps: A state synchronization channel is established between the vehicle end, the cloud end and at least two terminal devices, so that the vehicle end, the cloud end and the terminal devices can realize real-time synchronization of the digital vehicle key state based on event triggering; A sharing request is sent to the cloud end by a first terminal device holding a digital vehicle key of a vehicle owner, and the cloud end generates an intermediate credential with a first life cycle and returns the intermediate credential to the first terminal device after verifying the legality of the sharing request; The first terminal device signs the intermediate credential by calling a locally stored private key of the vehicle owner, and sends the signed intermediate credential to the cloud end; After verifying the validity of the signed intermediate credential, the cloud end issues a sub-credential with a second life cycle for a second terminal device, and the vehicle control authority range of the sub-credential does not exceed the authority range predefined by the intermediate credential; When the first terminal device, the second terminal device, the vehicle end or the cloud end triggers a revocation event, the cloud end generates a revocation instruction and broadcasts the revocation instruction to the vehicle end and all terminal devices through the state synchronization channel, and the vehicle end and all terminal devices delete the digital vehicle key object corresponding to the sub-credential and update their local digital vehicle key state after receiving the revocation instruction.

2. The method of claim 1, wherein, The state synchronization channel is established between the vehicle end, the cloud end and at least two terminal devices, comprising: Each of the vehicle end, the cloud end and each terminal device maintains a state machine, and the state machine comprises at least three states of valid, frozen and revoked; When the state machine corresponding to any subject jumps, a state change message is immediately pushed to the remaining subjects, and the state change message carries a timestamp and a jump reason code; The subject receiving the state change message performs deviation check on the timestamp of itself and the timestamp of the message, and if the deviation is less than a preset threshold, consistent jump is performed, otherwise a state conflict arbitration request is initiated to the cloud end, and corresponding state adjustment is performed after the cloud end returns an arbitration result.

3. The method of claim 1, wherein, The first life cycle is determined by the following steps: When generating the intermediate credential, the cloud end determines the absolute expiration time of the intermediate credential according to the preset life cycle rule, and embeds the absolute expiration time in the form of timestamp in the extension field of the intermediate credential; After starting each time, the vehicle end initiates a clock calibration request to the cloud end, obtains the system time of the cloud end, and calculates the offset between the local clock and the system time of the cloud end; if the offset exceeds a preset offset threshold, the vehicle end refuses to use the currently stored intermediate credential to perform any sub-credential issuance generation operation.

4. The method of claim 1, wherein, The vehicle control authority range of the sub-credential is limited by the following steps: When generating the intermediate credential, the cloud end writes the authority identification information in the permission configuration extension item of the intermediate credential, and each bit of the authority identification information corresponds to the authorization state of one vehicle control function; The first terminal device carries the sub-credential authority requirement information customized by the vehicle owner in the sent sharing request; The cloud performs an intersection operation on the permission identifier information of the intermediate credential and the sub-certificate permission requirement information defined by the vehicle owner when issuing the sub-certificate for the second terminal device, and writes the operation result as the final permission identifier of the sub-certificate into the sub-certificate, so that the sub-certificate only has the vehicle control permission corresponding to the operation result.

5. The method of claim 1, wherein, When the first terminal device, the second terminal device, the vehicle terminal or the cloud triggers a revocation event, the cloud generates a revocation instruction and broadcasts the revocation instruction to the vehicle terminal and all terminal devices through the state synchronization channel. After receiving the revocation instruction, the vehicle terminal and all terminal devices synchronously delete the digital vehicle key object corresponding to the sub-certificate and update the local digital vehicle key state, including: The subject triggering the revocation event generates a revocation request, which includes the identity of the triggering subject, the unique identifier of the sub-certificate to be revoked, and the revocation trigger reason. After receiving the revocation request, the cloud first verifies the legality of the triggering subject identity and the validity of the sub-certificate identifier to be revoked. If the verification fails, the cloud returns a revocation failure notification to the triggering subject. If the verification is passed, the cloud immediately generates a revocation instruction containing the identifier of the sub-certificate to be revoked. The cloud broadcasts the revocation instruction to the vehicle terminal and all terminal devices through the state synchronization channel. After receiving the revocation instruction, the vehicle terminal and all terminal devices delete the corresponding sub-certificate and associated digital vehicle key data stored locally according to the identifier of the sub-certificate to be revoked, and return a revocation completion feedback to the cloud. After receiving all the revocation completion feedbacks returned by the subjects, the cloud updates the sub-certificate state stored in the cloud to revoked, and returns a revocation success notification to the triggering subject.

6. The method according to any one of claims 1 to 5, characterized in that, When the wearable device is the second terminal device, the method further includes: Before issuing the sub-certificate, the cloud queries the device type identifier of the second terminal device; If the device type identifier is a wearable device type, write the Bluetooth communication configuration parameters into the sub-certificate, including the parameter information for reducing the Bluetooth broadcast duty cycle; After receiving the sub-certificate, the second terminal device parses the Bluetooth communication configuration parameters in the sub-certificate, adjusts the Bluetooth broadcast interval of itself from the default interval to the interval specified by the configuration parameters, and closes unnecessary signal field strength indication sampling interrupts to reduce device power consumption.

7. The method according to any one of claims 1 to 5, characterized in that, When sharing or revoking in a weak network environment, the method further includes: Any subject in the plurality of terminal devices and the cloud splits the intermediate credential data or revocation instruction data to be transmitted into a plurality of data fragments according to a preset maximum transmission unit limit, and each data fragment carries the total number of fragments, the current fragment sequence number and the check information; After sending the data fragments, if the sender does not receive an acknowledgement message from the receiver within a preset time, the sender performs a three-level retransmission strategy: the first retransmission interval is a preset basic interval, the second retransmission interval is twice the basic interval, and the third retransmission interval is four times the basic interval; If the sender does not receive an acknowledgement message from the receiver after three retransmissions, the sender stores the unsuccessfully transmitted data fragments in the local offline cache queue. When detecting that the network quality recovers to a preset standard, the unsuccessfully transmitted data fragments are extracted from the offline cache queue, and a retransmission operation is automatically initiated until all data fragments are transmitted.

8. A sharing and revoking system of a digital car key, characterized by, The application relates to a method for sharing a digital vehicle key, comprising the following steps: The device end comprises a first terminal device holding a digital vehicle key of a vehicle owner and a second terminal device for receiving a sub-certificate, the first terminal device is configured to initiate a sharing request to the cloud end, receive an intermediate certificate returned by the cloud end, sign the intermediate certificate with a locally stored private key of the vehicle owner and upload the intermediate certificate to the cloud end, and the second terminal device is configured to receive a sub-certificate issued by the cloud end, delete a corresponding key object and update a local state in response to a revocation instruction; The cloud end is configured to establish an event-driven multi-end state synchronization channel with the device end and the vehicle end, generate an intermediate certificate with a first life cycle after verifying the sharing request of the first terminal device, issue a sub-certificate with a second life cycle for the second terminal device after verifying the validity of the signed intermediate certificate, and the authority of the sub-certificate does not exceed the limited range of the intermediate certificate, and generate a revocation instruction and broadcast the revocation instruction through the synchronization channel when a revocation event trigger is received; The vehicle end is configured to realize state synchronization with the cloud end and the device end through the multi-end state synchronization channel, delete a key object corresponding to the sub-certificate after receiving the revocation instruction broadcast by the cloud end, and update a local state.

9. An electronic device, comprising: One or more processors; Memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the vehicle-mounted human-computer interface adaptive layout method in any one of claims 1 to 7. The computer program is executed by the processor to implement the steps in the vehicle-mounted human-computer interface adaptive layout method in any one of claims 1 to 7.

10. A computer readable medium having stored thereon a computer program, characterized in that ​

Images