Method for handling connection loss during a sharing process of a digital vehicle access key, system for performing the method and hardware token

Abstract

The invention relates to a method for handling connection loss during a sharing process of a digital vehicle access key from a sharing device to a digital hardware token, comprising: detecting a loss of communication between the hardware token and the sharing device during the sharing process of the digital key; attempting to recover the communication and retrying a failed sub-sequence of commands; once the communication is successfully re-established, continuing the sharing process. The invention also relates to a system for implementing the method and to a hardware token.

Description

Technical Field

[0001] This invention relates to a method for handling connection loss during the sharing process of a digital key from a shared device to a hardware token, a system for performing the method, and a hardware token. The digital key may be a Car Connectivity Consortium (CCC) digital key. Background Technology

[0002] Managing and exchanging digital keys in modern digital access systems presents significant technical challenges, especially in applications with stringent security requirements. Such systems face the challenge of integrating various technologies to reliably and securely control access to vehicle functions.

[0003] Currently, digital access systems include so-called smart devices such as smartphones, smartwatches, and tablets, as well as software carrying digital keys embedded in the secure storage of these smart devices. Smart devices provide an interface from the secure storage to the smartphone operating system, and from the smartphone operating system to other applications running on the smartphone (e.g., applications from vehicle original equipment manufacturers (OEMs)). Furthermore, digital access systems at least include the vehicle, allowing the holder of the digital key to operate certain vehicle functions. Finally, digital access systems include a backend system that interconnects the smart devices and the vehicle, allowing for the sharing and management of digital keys and providing additional services.

[0004] The key to these systems lies in the integrity and authentication of digital keys, access and management of key endpoints, and the flexibility of the system to adapt to different use cases. In particular, the following issues must be addressed to ensure a robust and user-friendly solution for digital key management in vehicle access systems.

[0005] A challenge for rental companies and other fleet management companies is that sharing digital keys to smartphones may be impractical or prohibitively costly. For example, work areas may have limited budgets, and / or smart devices may be vulnerable to theft. Another scenario is secure parking spaces where, unlike traditional key fobs, smart devices cannot remain in the vehicle. Furthermore, scenarios such as vehicle washing, refueling, or repairs, which typically involve multiple people, may be difficult to manage using smart devices that are usually tied to a single user and rely on key sharing between devices. Additionally, for companies such as dealerships or repair shops, there is a use case where they may avoid providing employees with smart devices that support digital keys due to cost, theft risk, or logistical issues, as smartphones may be too expensive, susceptible to theft, or difficult to transfer between employees.

[0006] Another issue concerns the secure and flexible sharing of digital keys. In particular, vehicle manufacturer policies must be considered to ensure that keys are shared only with authorized devices and under the correct conditions. The sharing process should be designed to support both private and fleet / service deployments without compromising security.

[0007] Finally, the issue of secure communication between the device and the vehicle arises. During the key transfer process, it is crucial that communication be reliably restored in the event of a connection loss. It must be ensured that the integrity and authenticity of the transmitted data remain intact even if an interruption occurs during the process. Summary of the Invention

[0008] In summary, a user of a digital key device can share a digital key used to control one or more vehicle functions with another device, which then becomes a digital key device itself. This document addresses the aforementioned technical problems and, in particular, provides a secure, flexible, and / or efficient key-sharing procedure for sharing digital keys with another digital key entity.

[0009] This technical problem is solved by each independent claim. Preferred examples are described in the dependent claims.

[0010] According to one aspect, a method for handling connection loss during the sharing process of a digital vehicle access key from a sharing device to a hardware token is described, comprising: detecting the loss of communication between the hardware token and the sharing device during the sharing process of the digital key; attempting to restore communication and retrying the failed command subsequence; and continuing the sharing process once communication is successfully re-established. The term "access" should encompass all forms of access to vehicle functions, such as locking / unlocking doors or hoods, vehicle driving modes achieved by unlocking an anti-theft device (typically via an anti-theft token), etc.

[0011] The sharing device can be a smartphone or a server-based owner / partner device (SBxD), and the hardware token can be a key card or, theoretically, a key fob. The possibility of retrying the failure command when a connection loss with the hardware token is detected (e.g., the key card slips off the back of the smartphone during the sharing process) leads to a significant improvement in the user experience regarding connection quality. By detecting communication loss and attempting to resume communication, along with retrying the failure command, this method ensures that the sharing process can continue even in the event of a temporary interruption. This improves the system's reliability, making it more robust.

[0012] During the sharing process, an endpoint is created and set to an inactive state. Immediately after creation, the endpoint cannot be used directly. In this state, the digital key endpoint can only be managed, not interacted with normally. As long as the endpoint remains inactive, it can be restarted and recreated after a communication interruption (e.g., power loss or communication loss). Data can be retained (e.g., confidential mailbox data encryption keys). When the endpoint is set to an active state, confidential information and all other data in the key learning session must be deleted.

[0013] According to a preferred embodiment, the reader device automatically detects connection loss and initiates a retry process. This may involve notifying the sharing device that a connection loss has occurred and that the sharing device will re-establish a secure channel. The reader device's automatic detection of communication loss ensures a rapid system response without user intervention.

[0014] According to another preferred embodiment, the retry process includes repeating a specific command from the previously failed step to ensure the key-sharing process completes successfully. This ensures the successful completion of the key-sharing process.

[0015] According to a further preferred embodiment, the hardware token and the shared device use a secure communication protocol. Alternatively, a proxy instance (e.g., a fleet management server or service provider server (FMS / SPS)) can thus establish a secure channel and compile and issue appropriate Application Protocol Data Unit (APDU) commands and exchange data between the FMS / SPS acting as the proxy and the SBxD acting as the shared device. Theoretically, such a proxy instance acting as an endpoint of the secure channel could also be a reader device.

[0016] Retrying can be performed within a predefined time window to avoid persistent failures in the key-sharing process. Limiting retries to a predefined time window prevents infinite retries, which could otherwise cause delays or inefficiencies in the key-sharing process, ensuring that the process completes in a timely manner.

[0017] Furthermore, in a preferred embodiment, there is an execution delay between retry attempts.

[0018] Preferably, the execution delay increases or shifts with each failed attempt, and in particular, the delay duration grows exponentially. This allows for protection against brute-force attacks, such as those in the password authentication process.

[0019] According to one embodiment, the delay is reset after successful authentication.

[0020] According to another embodiment, the sharing device records retry attempts and generates an error report in case of persistent connection problems. When sharing from a device such as a smartphone, only the sharing device can create the record data because it is the only entity involved besides the hardware token itself. When sharing is initiated from a backend SBxD, the backend entity (such as FMS / SPS) can also record the data.

[0021] Logging retry attempts and generating error reports provides a valuable mechanism for troubleshooting and diagnosis.

[0022] According to a further embodiment, the method also includes storing necessary data related to the key-sharing process in the non-volatile memory of a hardware token, so that the data can be accessed during the retry process. Storing necessary data related to the key-sharing process in non-volatile memory ensures that critical information is retained even in the event of a communication interruption. This allows the system to recover the process from the point of interruption, ensuring continuity and reducing the risk of data loss during communication interruptions.

[0023] It should be emphasized that the methods and systems described in this patent application (including their preferred embodiments) can be used independently or in combination with other methods and systems proposed herein. Furthermore, all aspects of the methods and systems described herein can be freely combined. Specifically, the features of the claims can be combined in any order or manner. Attached Figure Description

[0024] The invention will now be described below by way of example with reference to the accompanying drawings, in which:

[0025] Figure 1 An embodiment of a digital key access system for a vehicle is illustrated in schematic diagram;

[0026] Figure 2 An embodiment of a hardware token is illustrated in the diagram.

[0027] Figure 3 An example of the initial preparation process for a hardware token is shown;

[0028] Figure 4 An example of the process for initiating a sharing process on the sharing side is shown;

[0029] Figure 5 An example of the process of creating an endpoint on a hardware token is shown;

[0030] Figure 6 An example of the process of key tracking and sharing the final completion is shown;

[0031] Figure 7An embodiment of the binding process for sharing hardware tokens is shown;

[0032] Figure 8 An example of a process for handling connection loss in key sharing is shown. Detailed Implementation

[0033] Figure 1 An embodiment of a digital key access system 100 for vehicle 110 is shown. In addition to vehicle 110, system 100 typically (but not necessarily) includes a smart device 112 and a server 114. Smart device 112 can be a portable electronic device, such as a smartphone, tablet, wearable smart device (such as a smartwatch), etc. Digital key 116 can be stored on smart device 112, particularly in a protected memory portion of the portable electronic device. The protected memory portion can be a so-called secure element 118 according to CCC standards. Generally, this does not necessarily have to be a secure element and different technologies can be used. Smart device 112 typically includes an integrated power supply (such as a battery) to allow smart device 112 to operate autonomously.

[0034] The smart device 112 can communicate with the communication unit 120 of the vehicle 110 via one or more wireless communication links 122, 124. Different communication links 122, 124 can be used for different purposes. In particular, short-range communication can be provided between the device 112 and the vehicle 110 using Bluetooth Low Energy (BLE) communication link 122 and / or Near Field Communication (NFC) communication link 124. To establish an NFC communication link 124, the device 112 can maintain close proximity to the communication unit 120 of the vehicle 110 (e.g., within 10 cm).

[0035] The control unit 126 of vehicle 110 can be configured to control at least one vehicle function of vehicle 110 based on communication between smart device 112 and vehicle 110. In this case, the digital key 116 of smart device 112 can be verified, specifically authenticated. Furthermore, upon authentication, one or more vehicle functions can be controlled, specifically based on the distance between smart device 112 and vehicle 110; the position of smart device 112 relative to vehicle 110; and / or control commands sent by smart device 112 to vehicle 110 via communication links 122, 124.

[0036] In example system 100, once the distance between smart device 112 and vehicle 110 is equal to or less than a first distance threshold, a BLE communication link 122 can be established between smart device 112 and vehicle 110. Once the BLE communication link 122 is established, smart device 112 can authenticate with vehicle 110 using smart device 112's digital key 116. With smart device 112 authenticated, smart device 112 can be permitted to send one or more control commands via communication link 122 to control one or more vehicle functions.

[0037] As already discussed, using a smart device 112 as the carrier of the digital key 116 is not always the best choice. Various use cases exist (as already mentioned) where hardware tokens are preferred. Rental companies and other fleet management companies can use hardware tokens (such as key cards) to share vehicle keys with employees or customers.

[0038] Figure 2 An embodiment of a hardware token 200 is shown, which has a communication module 202 (particularly an NFC communication module) and a secure storage area 204 (particularly a secure element 205), wherein the storage area 204 is configured to store a shared digital key 206 and / or proof 208 for the shared digital key 206. Furthermore, the hardware token 200 may include an applet 210 (e.g., a hardware token management applet 210) that provides a set of commands for interacting with the hardware token 200 (particularly with the secure element 205 of the hardware token 200). The hardware token management applet 210 and the digital key applet 211 can execute on the processor of the hardware token 200. Generally, all functions (i.e., management and use of related functions) can also be encapsulated in a single applet.

[0039] In the illustrated embodiment, the hardware token 200 is a key card. The key card 200 must be supplied with electrical power from an external power source (e.g., from an ambient magnetic field). Furthermore, the hardware token 200 may have a code 212 (specifically a machine-readable code, such as a QR code) printed on its surface. The code 212 may indicate a password that can be used to establish a secure communication channel with the hardware token 200.

[0040] A digital key device (e.g., smart device 112) acting as the owner and / or sharing device can interact with the hardware token 200 via communication link 124 (particularly via an NFC communication link). Therefore, smart device 112 can be used as an NFC reader for the hardware token 200. Communication link 124 can be used to manage (e.g., share or create, terminate, and / or delete) the shared digital key 206 on the hardware token 200.

[0041] Hardware token 200 is typically provided by a hardware token provider, which runs hardware token manufacturer server 220. Hardware token manufacturer server 220 and hardware token 200 can interact via communication link 124 (e.g., via an NFC communication link), for example, to install software (such as hardware token management applet 210) on hardware token 200, and / or to provide public key infrastructure (PKI) data to hardware token 200. The PKI data of hardware token manufacturer server 220 is typically different from the PKI data used by vehicle server 114. Hardware token manufacturer server 220 and vehicle server 114 can be configured to communicate with each other via communication link 222.

[0042] Figure 3 An embodiment of the initial preparation process for hardware token 200 is shown. This process forms what is called Phase 0 of the process of sharing digital key 206 with hardware token 200. In Phase 0, hardware token 200 is prepared for secure communication and operation within the digital vehicle access system. This initialization is typically completed by the hardware token manufacturer before shipment to ensure that hardware token 200 is fully configured before any sharing operation begins.

[0043] First, a hardware token management applet 210 for key learning and management, a digital key applet 211 for key usage, and configuration data (e.g., SPAKE2+) for establishing a secure external communication channel with the hardware token management applet 210 are deployed to the hardware token 200 (S300). As already mentioned, the functionality of the two applets 210 and 211 can be integrated into a single applet. Once the hardware token management applet 210 and digital key applet 211 are installed, a hardware token instance CA 214 is created on the hardware token 200 (S302), generating a unique key pair that will be used for authentication and encrypted communication. The hardware token instance CA key pair, along with the corresponding hardware token instance CA certificate, is generated and stored directly on the hardware token 200.

[0044] Subsequently, hardware token 200 generates a certificate signing request for the hardware token instance CA certificate and sends it to hardware token manufacturer server 220 for verification (S304). Hardware token manufacturer server 220 reviews the request and signs the hardware token instance CA certificate, confirming the authenticity and integrity of the hardware token instance CA (S306). The hardware token instance CA certificate can be cross-signed by a vehicle OEM-specific vehicle OEM CA, a global hardware token root CA for global tokens, or a proxy hardware token acting as an intermediary for multiple vehicle OEMs.

[0045] After signing, the hardware token instance CA certificate is provided to hardware token 200 (S308). Finally, the hardware token OEM CA certificate is also provided to hardware token 200, thereby enabling trusted communication with multiple vehicle OEMs (S310).

[0046] After the initial preparation of the hardware token 200, the digital key 206 can be shared with the hardware token 200. This requires initiating a sharing process. This is completed in Phase 1 – see [link to Phase 1] Figure 4 .

[0047] exist Figure 4 In this process, the initiation of sharing the digital key with the hardware token 200 is shown as Phase 1. The method begins with an employee 102 of the fleet management or service provider 106 selecting the vehicle 110 to which access is to be granted (S400). The employee 102 then initiates the "Share to Token" process on a terminal 104 (S402), which acts as a gateway between the hardware token 200, the fleet management server (FMS) or service provider server (SPS), and any relevant backend systems. Subsequently, the hardware token 200 is placed on the interface of the terminal 104 to establish a connection (S404).

[0048] Once connected, the terminal sends a SELECT command to activate the hardware token management applet 210 on the hardware token 200, preparing it for sharing operations (S406). The hardware token 200 responds with a SELECT response message indicating readiness (S408). If an endpoint already exists on the hardware token 200, and the hardware token is designed to accommodate only one endpoint, the existing endpoint must be revoked first, and the process ends there. The endpoint revocation procedure needs to be initiated before proceeding (S410). Alternatively, if the hardware token is ready to accept a new digital key, it will respond with a SELECT response confirming its compatibility with the new key's sharing operations (S412).

[0049] Then, the terminal requests the hardware token instance CA certificate and other certificates in the certificate chain from the hardware token 200 to identify the hardware token 200 (S414). In response, the hardware token 200 provides a VIEW response indicating the length of the requested certificate data, allowing the terminal 104 to prepare for data transmission (S414).

[0050] Terminal 104 issues a READ BUFFER command to download the certificate data specified in the previous response, which includes the hardware token instance CA certificate and other relevant certificates required for authentication (S416). Hardware token 200 responds with the requested certificate data, which includes all necessary certificates for verification (S418).

[0051] The system can then optionally use a proprietary method similar to that used in private processes to verify the compatibility of the hardware token 200 (S420). The terminal can send a PreShare request, which includes hardware token sharing data based on the hardware token instance CA certificate and the vehicle identifier, to verify the compatibility of the hardware token 200 (S422).

[0052] The PreShare request is an optional step in the sharing process. It can be used to obtain individual policies regarding endpoint deletion from the vehicle OEM 114. This policy provides information on whether and how endpoints should be deleted in the event of an error during the final completion of the token sharing process. This information may help ensure compliance with the vehicle OEM 114's policies in any endpoint creation or deletion actions.

[0053] Especially in fleet scenarios, ciphers used for secure communication (e.g., SPAKE2+) can be provided in a scannable format (such as a QR code) or sent by the backend entity. For fleet or service provider processes, secure communication parameters can be exchanged in advance between the hardware token manufacturer (OEM) and the fleet or service provider to facilitate secure sharing.

[0054] exist Figure 5 Phase 2 is shown in the diagram. The process in Phase 2 focuses on establishing a secure communication channel, such as a SPAKE2+-based secure communication channel, between the hardware token 200 and the server-based owner / partner device (SBxD) 108, creating a new endpoint on the hardware token 200, and generating an encryption key and its authentication for future secure data exchange. This newly generated key is used to securely transmit an optional anti-theft token to a confidential mailbox (see below). Figure 6 Step S600 in the process.

[0055] The process begins when fleet management employee 102 or service employee 102 initiates the sharing process by selecting the option to request sharing on the appropriate device (S500). This request is forwarded to the fleet management / service provider application or terminal 104 (S502). Then, the fleet management / service provider server 105 calls the corresponding API on SBxD 108. This API prepares the hardware token sharing request by including necessary parameters such as vehicle ID, sharing ID, permissions, activation options, sharing type, SPAKE2+password (if the fleet management / service provider server 105 does not provide it), and hardware instance CA certificate (S503). The response to this API call generates a SELECT command.

[0056] Next, the SELECT command is forwarded from SBxD 108 to application / terminal 104 via FMS / SPS 105 (S504). Communication between application / terminal 104 and hardware token 200 can be performed via NFC or other means. A secure channel is established between hardware token 200 and application / terminal 104, which acts as a relay for fleet management / service provider server 105 (e.g., via SPAKE2+ protocol) (S505). The application / terminal relays the SELECT command to hardware token 200, identifying the application identifier (AID) of the hardware token management applet (S506). The hardware token responds with relevant data (including version information and scrypt parameters) (S507).

[0057] Next, the application or terminal will transmit the additional Application Protocol Data Unit (APDU) payload to the fleet management / service provider server (S508) and SBxD 108 (S509).

[0058] SBxD 108 generates a SPAKE2+ request command by calculating the SPAKE2+ parameters (which includes deriving w0 and w1 from the password and Scrypt configuration) (S510). This command is sent to the fleet management / service provider server 105 and used to establish a secure connection with the hardware token 200 (S511).

[0059] Once the SPAKE2+ exchange is complete, SBxD 108 compiles endpoint creation data, which outlines the configuration of the new endpoint on hardware token 200. As a sharing device, SBxD 108 sends the endpoint configuration to hardware token 200 using the WRITE BUFFER command (S521). Once all the necessary data has been transferred, SBxD 108 initiates processing of that data by issuing the CREATE HARDWARETOKEN ENDPOINT command (S522). Hardware token 200 reads the data from the buffer, verifies the configuration, creates the endpoint, and generates the corresponding certificate (S523). The newly created endpoint is set to an inactive state; that is, it is not allowed to perform fast or standard transactions until the token sharing process is finally complete. A corresponding response is sent to SBxD 108 (S524). Subsequently, SBxD 108 reads the generated certificate from hardware token 200 (S525, S526). The certificate is cached on the sharing device (i.e., SBxD 108).

[0060] To proceed, the shared device requests the creation of an encryption key on the hardware token 200 by sending a CREATE ENCRYPTION KEY command (S527). The hardware token 200 generates the encryption key and creates a proof (S528). Then, SBxD 108 receives a CREATE ENCRYPTION KEY response (S529). Next, SBxD 108 retrieves the encryption key proof using a READ BUFFER command (steps 530, 531). The proof data is stored on the shared device for later use, such as during key tracking.

[0061] Finally, in stage 3 (see Figure 6 In this process, the sharing entity (i.e., SBxD 108) prepares a proof package. This package specifically includes the public key of the endpoint certificate and is signed by the sharing entity. A key tracking and online proof package is also prepared and includes the aforementioned proof package, the endpoint certificate signed by the instance CA, the instance CA certificate, and an endpoint cryptographic key certificate signed by the endpoint private key used for newly created endpoints. This key is used to securely transmit optional anti-theft tokens to a confidential mailbox (S600). In cases where sharing originates from a device, explicit user authentication is required. When sharing is initiated by SBxD 108, additional vehicle OEM policies, such as two-factor protection, may be applied.

[0062] Once the proof package is ready, the sharing entity proceeds with the tracking key request. This request is sent to the vehicle OEM server 114 (S602). The purpose of this request is to retrieve the contents of the mailbox.

[0063] The vehicle OEM server 114 processes the request (S604), sends a tracking key request to the key tracking server 115 (S605), and sends a tracking key response containing encrypted device data and email information back to the sharing entity (S606). The sharing entity then uses its private encryption key to decrypt the received device data. The confidential email data is then securely forwarded to the hardware token 200, which decrypts it using its specific encryption key verified by the encryption key (S608).

[0064] After successfully decrypting the data, the shared entity writes the two mailboxes into the token.

[0065] The shared device (e.g., SBxD 108) and the hardware token 200 are protected by a secure SPAKE2+ channel between the NFC terminal 104 and the fleet management server / service provider (S610).

[0066] In step S612, the shared device issues a SET PRIVATE DATA command, providing a key identifier and mailbox data. The mailbox data includes relevant information such as mailbox version and signaling bitmap. The hardware token 200 processes the command and responds with a success code in step S613.

[0067] Next, in step S614, the shared device initiates a WRITE BUFFER command, which transmits encrypted confidential mailbox data to the hardware token 200. In step S615, the hardware token 200 confirms receipt of this data using a success code.

[0068] In step S616, the shared device issues a SET CONFIDENTIAL DATA command, including the key identifier. In step S617, the hardware token 200 decrypts and stores the confidential mailbox data. In step S618, the hardware token 200 confirms the success of this operation.

[0069] In step S619, the shared device issues a SETUP HARDWARE TOKEN ENDPOINT command, specifically providing the hardware token 200 with a key identifier and a key slot identifier. The hardware token 200 responds with a success code in step S620.

[0070] If a link interruption occurs at any time between steps S612 and S620, the shared device can retry the failed subsequence. For example, if the SET CONFIDENTIAL DATA command is to be repeated, the WRITE BUFFER command can be repeated.

[0071] Finally, the hardware token 200 completes the endpoint setup by deleting all temporary data (such as the confidential mailbox data encryption key), sets the endpoint to an active state in step S621, and notifies the shared device with a SETUP HARDWARE TOKENENDPOINT response and a success code in step S622.

[0072] Next, the sharing entity (here, SBxD 105) issues a command to the vehicle OEM server 114 indicating that the sharing process has been successfully completed (S624). Then, the vehicle OEM server 114 pushes the certificate to the vehicle 110 (S626).

[0073] The vehicle OEM server 114 sends a message to SBxD 108, notifying it of the hardware token 200 and that the sharing process is complete (S628). Finally, SBxD 108 sends a message to the fleet management / service provider server 105, confirming that the token sharing process is fully completed and all processes are finally finished (S630).

[0074] Apply any additional vehicle OEM security data processing and two-factor authentication policies as required by the fleet / service context.

[0075] Figure 7 An embodiment of a method for binding a hardware token 200 is shown.

[0076] The binding is initiated by a terminal (“binding device”) 104, which can be a PC or similar device with an NFC card reader (S700). The binding device 104 then instructs a backend entity (“binding entity”) to perform the binding process. The backend entity can be an SBxD 104 or an FMS / SPS 105. Figure 7 In this embodiment, the binding device 104 requests a binding challenge from the fleet management / service provider server 105 (S702), which will be used to ensure a secure and unique binding. The fleet management / service provider server 105 generates a binding challenge as a unique identifier for the binding session (S704) and returns it to the binding device 104, allowing the process to continue (S706).

[0077] Then, binding device 104 sends an INSTANCE CA BINDING request to hardware token 200, which includes a binding challenge obtained from backend entities 105 / 108 (S708) and a parameter of the instance CA key to perform the signing. Hardware token 200 compiles a set of data containing the binding challenge and may include further data (such as locally generated random values, parameters of the signing key, and / or constants reflecting the binding of this set of data to the instance CA). Hardware token 200 then signs this set of data using the private key (SK) of the requested instance CA (S710). Hardware token 200 responds with an INSTANCE CABINDING response, returning the signature (S712). This response may include additional data (such as locally generated random values, parameters of the signing key, and / or constants reflecting the binding of this set of data to the instance CA).

[0078] The binding device 104 forwards the instance CA certificate and signature to the fleet management / service provider server 105 for verification (S714). The fleet management / service provider server 105 then verifies the validity of the instance CA certificate and checks the correctness of the signature, confirming the authenticity of the hardware token (S716). Upon successful verification, the server stores the instance CA certificate for use by the fleet or service (S718). Therefore, the corresponding hardware token 200 will be on a "whitelist," meaning the hardware token 200 is now added to the pool of hardware tokens that can be used as a shared target for digital keys associated with the binding entity, while unbound hardware tokens cannot be used as recipients of digital keys associated with the binding entity.

[0079] Then, the server confirms the binding with the binding device, indicating that the token binding has been successfully completed (S720). Finally, the binding device ends the token binding process, marking the end of the method (S722).

[0080] As already mentioned, the binding entity can also be SBxD 108, meaning that steps 704 / 716 / 718 can be performed by SBxD 108, and FMS / SPS 105 will then act as a proxy between terminal 104 and SBxD 108.

[0081] Furthermore, prior to the binding process, a secure communication channel can be established between the binding entity 105 / 108 and the hardware token 200 using a provided password. The binding entity 105 / 108 can use this channel to confirm that the hardware token 200 is technically available.

[0082] Furthermore, and importantly, the digital key sharing process can continue even in the event of a temporary interruption of the underlying secure communication channel.

[0083] Figure 8 An embodiment of a process for handling connection loss during key sharing is illustrated. The method for handling connection loss between the hardware token and reader device 104 begins with the start of the key sharing process. Sharing of the digital key is initiated (S800), for example, via a smart device's wallet or another sharing device (such as a fleet management / service provider server 105), which pushes a key sharing command to the hardware token 200 via reader device 104 (S802). Initial data, such as a session identifier and an encryption key for secure communication, is generated and may be stored in the non-volatile memory (NVM) of the hardware token 200 in preparation for potential interruptions.

[0084] Once the process is initiated, the reader device detects when communication with the hardware token 200 is lost during the key-sharing process (S804). Upon identifying the connection loss, the reader initiates a retry mechanism to restore communication with the hardware token 200 (S806), attempting to re-establish the connection. This mechanism is designed to automatically handle brief communication problems and allow the system to continue the key-sharing process once communication is restored. To ensure continuity, the system stores the state of the current command sequence (including breakpoints) in the NVM. This information allows the reader device 104 to know exactly where to continue once communication is restored.

[0085] After communication is re-established (S808), reader device 104 attempts to resume the key-sharing process by retransmitting the subset of commands that failed in the previous successful step. Reader device 104 retrieves the previously saved command state from the NVM, allowing it to continue from the point of interruption. This process enables the system to continue from the point of interruption, ensuring the key-sharing process completes without repeating unnecessary commands (S810). Retry counts and timing data can also be stored in the NVM to track the number of retries and apply exponential backoff when necessary.

[0086] To ensure robust security, retry attempts are limited to a predefined time window. Communication between the hardware token and the reader device uses a secure protocol (such as SPAKE2+) to ensure data integrity and confidentiality throughout the transmission. Limiting retry attempts to a specific time window prevents endless retries that could lead to inefficiency and delays, denial-of-service (DoS) attacks, or brute-force attacks.

[0087] To further protect against brute-force attacks, the retry mechanism can use exponential backoff delays between subsequent retries. With each failed attempt, the delay before the next attempt increases, making fast retries impossible. After successful reconnection and authentication, the exponential delay is reset, ensuring rapid restoration of access when the connection is re-established.

[0088] In cases of persistent connectivity issues, reader device 104 logs each retry attempt and may generate error reports. These logs provide system administrators with valuable diagnostic data, enabling them to troubleshoot and resolve persistent connectivity problems.

[0089] Finally, the necessary data related to the key-sharing process is stored in the non-volatile memory of the hardware token 200. The reader device 104 is typically stateless and only forwards commands and their responses. Sharing entities must perform retries; for example, a smartphone or SBxD 108 in a private sharing use case might need to repeat a step. In both cases, the use of non-volatile memory may not be necessary because the data can be stored within the open key-sharing session.

[0090] Generally, storage ensures that critical information is preserved even in the event of a temporary power outage. By retaining this data, the system can resume the key-sharing process without losing progress.

[0091] Not all the information mentioned needs to be stored in non-volatile memory (NVM). In many cases, storing a limited set of critical data to resume the process after an interruption may be sufficient. The focus is primarily on the hardware token 200 itself, to handle situations such as power loss in the case of a key card and communication loss that may occur with any type of hardware token 200.

[0092] When not set to active, the endpoint for hardware token 200 may be unavailable. The endpoint is set to active when the key learning sequence is fully completed. This may result in the deletion of all key learning session information, which is persistently stored and is data in RAM (e.g., data such as the basic encryption key (confidential mailbox encryption key), etc.).

[0093] Typically, only the following key information will be stored in NVM:

[0094] - Timer and retry counter: The current state of the retry timer and the number of retries already made;

[0095] - Basic encryption keys: If encryption keys are necessary for secure communication and need to be temporarily stored, they can be stored in NVM to support secure session recovery;

[0096] - Session ID or other identifiers: These can help maintain the context of ongoing operations.

Claims

1. A method for handling connection loss during the sharing process of a digital key from a sharing device to a hardware token, comprising: - Detect the loss of communication between the hardware token and the sharing device during the digital key sharing process; - Attempt to restore communication and retry the failed command subsequence; Once communication is successfully re-established, the sharing process continues.

2. The method according to claim 1, wherein, During the sharing process, an endpoint is created and set to an inactive state.

3. The method according to claim 2, wherein, After the sharing process is complete, set the endpoint to active status.

4. The method according to claim 2 or 3, wherein, The shared device can interact with active endpoints, and / or the shared device cannot interact with inactive endpoints.

5. The method according to claim 1, wherein, When an endpoint is set to active, delete temporary data.

6. The method according to claim 1, wherein, The reader device detected a connection loss and initiated a retry process.

7. The method according to claim 1, wherein, The retry process involves repeating specific commands from previously failed steps to ensure that the key-sharing process completes successfully.

8. The method according to claim 1, wherein, Hardware tokens and shared devices use a secure communication protocol and retry within a predefined time window to avoid persistent failures during the key-sharing process.

9. The method according to claim 4, wherein, There is an execution delay between retry attempts.

10. The method according to claim 5, wherein, Execution latency increases with each failed attempt.

11. The method according to claim 1, wherein, Shared devices and / or agent instances record retry attempts.

12. The method of claim 1, further comprising storing necessary data related to the key-sharing process in a non-volatile memory of a hardware token so that the data can be accessed during the retry process.

13. A system for performing the method according to any one of claims 1 to 12, the system comprising securely sharing a digital vehicle access key, the system comprising a server and / or a backend system and a hardware token.

14. A hardware token for use in the system according to claim 13.

Images