A concept for server-based sharing of digital keys

Abstract

Allows keys to be shared from a single paired device of the owner. A device 10 for a digital vehicle key sharing server 100 includes: an interface circuit 12; obtaining, via the interface circuit, a request from the first device 300 to the second device 200; 250 to share a digital vehicle key for the vehicle; Identifying whether the second device identified by the request is the user device 250 or the server 200; and and processing the request to share the digital vehicle key based on whether the second device identified by the request is the user device 250 or the server 200. A processing circuit 14 configured Contains:

Description

[Technical Field]

[0001] Examples relate to concepts for server-based sharing of digital keys, and more particularly, but not limited to, apparatus, methods and computer programs for a digital vehicle key sharing server, for a second server, and for a first device. [Background technology]

[0002] The Digital Car Key, defined in the Car Connectivity Consortium (CCC) standard Releases 2 and 3, defines an access system that includes a smart device, a vehicle, and a back-end system. The smart device uses software that contains the digital key embedded in secure storage on the smart device, provides an interface from the secure storage to the smartphone operating system, and provides an interface from the smartphone operating system to other applications running on the smartphone (e.g., the vehicle OEM's apps). The vehicle allows the digital key holder to operate specific vehicle functions. The back-end system interconnects the smart device and the vehicle and provides additional services when allowed to share and manage the digital key.

[0003] Generally, a digital key for a specific vehicle can only be shared with the owner key of that specific vehicle. Key sharing is a multi-step process in which the owner first configures the parameters of the digital key to be created (a "key creation request") and hands it over to the "recipient" device (via an intermediary server). After the recipient device creates the key (in its secure element) and exports an "endpoint certificate" containing the parameters that created the key, the recipient device sends a key signing request back to the owner containing the recipient's certificate chain, and the owner certifies that the key was created according to the key creation request by signing the endpoint certificate with its (endpoint's) private key (a "key sharing proof"). The owner's public key is known to the vehicle through the owner pairing process. Optionally, the recipient sends a key tracking request to a key tracking server.

[0004] During the initial connection with the recipient's vehicle using the owner's public key, the vehicle verifies the owner's signature on the recipient's key (contained in the certification package) to ensure that the presented key is authentic. After the signature is verified, the recipient's key can be used to start the engine.

[0005] However, in the above system, keys can only be shared from one paired device, since only that device contains the necessary private key. Furthermore, the recipient's key cannot share the key further, nor can the owner delegate sharing rights to other keys or entities. Summary of the Invention [Problem to be solved by the invention]

[0006] There may also be a need for improved concepts for key sharing of digital keys for vehicles. [Means for solving the problem]

[0007] This need is addressed by the subject matter of the independent claims.

[0008] The concept proposed in this disclosure is based on the discovery that a server-based approach can be used to alleviate the above-mentioned drawbacks. Instead of having a sharer / owner device (hereinafter referred to as a “first device”) sign the digital vehicle key to be shared, the sharer device is used only to trigger the sharing process in the digital vehicle key sharing server. To support both direct sharing to a recipient device (hereinafter referred to as a “user device”) and indirect sharing via another server (hereinafter referred to as a “second server”), which may be a server of a car sharing service, an owner device or entity with sharing rights sends a request to the second device to share digital vehicle keys for one or more vehicles, along with the request indicating whether the second device is a user device or a server. The digital vehicle key sharing server can then take appropriate action depending on whether the second device is a recipient device or a second device.

[0009] Some aspects of the present disclosure relate to an apparatus for a digital vehicle key sharing server, the apparatus including an interface circuit and a processing circuit. The processing circuit is configured to receive a request to share a digital vehicle key for one or more vehicles from a first device to a second device via the interface circuit. The processing circuit is configured to identify whether the second device identified in the request is a user device or a server. The processing circuit is configured to process the request to share the digital vehicle key based on whether the second device identified in the request is a user device or a server. With the involvement of the digital vehicle key sharing server, sharing is not tied to a single device of the vehicle owner. Furthermore, the sharing process is decoupled from the owner device so that sharing can occur even while the owner device is offline. Finally, the same mechanism allows both direct sharing to a recipient device (i.e., a user device) and indirect sharing (via a second server).

[0010] For example, the processing circuitry can be configured to verify a request to share a digital vehicle key based on a public key of the first device contained in a storage unit containing one or more public keys authorized to issue requests to share digital vehicle keys for one or more vehicles. This allows the same mechanism to be used for sharing by the first device and for sharing by the second server. Furthermore, additional devices of the owner can be added to the devices authorized to issue requests to share digital vehicle keys for one or more vehicles.

[0011] In some examples, if the second device is a server, the processing circuitry can be configured to add the public key of the second device to a store that includes one or more public keys that are authorized to issue requests to share the digital vehicle key. If the public key of the second server is part of the store, the second server can be authorized to issue requests to share the digital vehicle key.

[0012] In various examples, if the second device is a server, the processing circuitry can be configured to sign a public key of the second device with a private key of the digital vehicle key sharing server and provide the signed public key of the second device to the second device for future proofing, which can then be used by the second server to authenticate to the digital vehicle key sharing server.

[0013] The processing circuitry can be configured to obtain, via the interface circuit, a second request to share a digital vehicle key for the vehicle from the second device, which is a server, to the user device, and to provide, via the second device or directly, an invitation to provide the public key of the digital vehicle key for signing to the digital vehicle key sharing server. For example, the public key of the digital vehicle key can be part of a certificate including the public key and information on the authority of the digital vehicle key. Thus, the processing circuitry can be configured to provide, via the second device or directly, the invitation to the user device to provide a certificate including the public key of the digital vehicle key for signing to the digital vehicle key sharing server. The same mechanism can be used for the second device, which is a user device. Thus, the processing circuitry can be configured to provide, via the first device or directly, the invitation to the second device (which is a user device or a server) to provide the public key of the digital vehicle key (or a certificate including the public key) for signing to the digital vehicle key sharing server. The user device or the second server can use the invitation to have its respective public key signed by the digital vehicle key sharing server.

[0014] According to one example, the processing circuitry can be configured, via the interface circuitry, to obtain a request to sign the digital vehicle key public key (or a certificate including the public key) from a second device (e.g., from the user device or the second server), to sign the digital vehicle key public key (e.g., a certificate having the public key) using the digital vehicle key sharing server's private key, and to provide the signed digital vehicle key public key (e.g., a signed certificate including the public key) to the user device (e.g., the user device or the second server). As described above, the request to sign the digital vehicle key public key or the certificate can be obtained in response to an invitation to provide the digital vehicle key public key. In the vehicle, the digital vehicle key sharing server's public key is stored in a key storage unit. The signed digital vehicle key public key, e.g., the signed certificate, can then be used to authenticate the user device (or the second server) to the vehicle, which can use the digital vehicle key sharing server's public key to verify the signed digital vehicle key public key or the certificate.

[0015] According to one example, the user device may be the second device, or the user device may be the user device that requested the signature (or certification) of the public key of the digital vehicle key via the second device (which is a server). In other words, both direct and indirect key agreement are supported.

[0016] In various examples, the request to share the digital vehicle key can include authentication verification information. The processing circuitry can be configured to verify the request to sign the public key (or certificate) of the digital vehicle key based on the authentication verification information. This can provide additional security in cases where an invitation is provided to an "incorrect" recipient, for example, by the second server or the first device.

[0017] In some examples, the authentication verification information may include one of a public key of the second device, information derived from a user account identifier associated with the user device, and information derived from a phone number associated with the user device, all of which may be used to tie the invitation to a particular device or user account.

[0018] Some aspects of the present disclosure relate to an apparatus for a second server. The apparatus includes an interface circuit and a processing circuit. The processing circuit is configured to receive a first request for access to a vehicle from a user device via the interface circuit. The processing circuit is configured to provide a second request to the digital vehicle key sharing server to provide a digital vehicle key for the vehicle based on the first request. In other words, the second server acts as an intermediary between the user device and the digital vehicle key sharing server. Before assuming the role of intermediary, the second server's public key can be added to a storage unit containing one or more public keys authorized to issue requests to share digital vehicle keys.

[0019] In some examples, the processing circuitry can be configured to obtain a public key of the user device via the interface circuitry. The second request can include the public key of the user device, which can enable a form of authentication of the user device. Alternatively, or in addition, the user device can include the above-mentioned information about a user account identifier associated with the user device or information derived from a phone number associated with the user device.

[0020] According to one example, the processing circuitry can be configured to obtain an invitation to provide the public key (or a certificate including the public key) of the user device's digital vehicle key to the digital vehicle key sharing server for signing, and to forward the invitation to the user device, which then enables the user device to provide the public key (e.g., the certificate having the public key) of the user device's digital vehicle key to the digital vehicle key sharing server for signing.

[0021] Some aspects of the present disclosure relate to an apparatus for a first device. The apparatus includes an interface circuit and a processing circuit. The processing circuit is configured to generate a request to a second device to share a digital vehicle key for one or more vehicles. The request indicates whether the second device identified by the request is a user device or a server. The processing circuit is configured to provide the request to a digital vehicle key sharing server. The digital vehicle key sharing server can then take appropriate action, as described above.

[0022] For example, the request may include information about one or more vehicles to be shared and information about the second device, where the former information can be used by the digital vehicle key sharing server to identify the size of the share and the latter information can be used by the digital vehicle key sharing server to identify the recipients of the share.

[0023] Some aspects of the present disclosure relate to a method for a digital vehicle key sharing server. The method includes obtaining a request to share digital vehicle keys for one or more vehicles from a first device to a second device. The method includes identifying whether the second device identified by the request is a user device or a server. The method includes processing the request to share the digital vehicle keys based on whether the second device identified by the request is a user device or a server.

[0024] Some aspects of the present disclosure relate to a method for a second server, the method including obtaining a first request for access to a vehicle from a user device, and providing a second request to a digital vehicle key sharing server, based on the first request, to share a digital vehicle key for the vehicle.

[0025] Some aspects of the present disclosure relate to a method for a first device to generate a request to share digital vehicle keys for one or more vehicles with a second device, the request indicating whether the second device identified by the request is a user device or a server, and providing the request to a digital vehicle key sharing server.

[0026] One aspect of the present disclosure relates to a computer program comprising a program code for performing one of the above-mentioned methods when the program is run on a computer, a processor or a programmable hardware element.

[0027] Some examples of apparatus and / or methods will now be described, by way of example only, with reference to the accompanying drawings in which: [Brief explanation of the drawings]

[0028] [Figure 1a] 1 is a diagram illustrating an example of an apparatus for a digital vehicle key sharing server and an example of a digital vehicle key sharing server including such an apparatus; [Figure 1b] FIG. 1 illustrates a flowchart of an example method for a digital vehicle key sharing server. [Figure 1c] 1 is a diagram illustrating an example of a system including a digital vehicle key sharing server, a first device, and a second device that is a user device. [Figure 1d] 1 is a diagram illustrating an example of a system including a digital vehicle key sharing server, a first device, a second device that is a second server, and a user device. [Figure 2a]1 is a diagram illustrating an example of an apparatus for a second server and an example of a second server including such an apparatus. [Figure 2b] FIG. 10 shows a flowchart of an example of a method for a second server. [Figure 3a] 1A and 1B are diagrams illustrating an example of an apparatus for a first device and an example of a first device including such an apparatus. [Figure 3b] FIG. 10 illustrates a flowchart of an example of a method for a first device. [Figure 4-1] FIG. 10 is a sequence diagram of an example of server-based key sharing to a user device. [Figure 4-2] FIG. 10 is a sequence diagram of an example of server-based key sharing to a user device. [Figure 5] FIG. 10 is a sequence diagram of an example of registration of an automobile sharing server in a digital vehicle key sharing server. [Figure 6] FIG. 10 is a sequence diagram of a simplified example of server-based key sharing to a user device via a car sharing server. DETAILED DESCRIPTION OF THE INVENTION

[0029] Some examples will be described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of the examples described in detail. Other examples may include feature modifications, equivalents, and alternatives. Furthermore, the terms used herein to describe certain examples are not intended to be limiting of other possible examples.

[0030] Throughout the description of the figures, the same or similar reference numerals indicate the same or similar elements and / or features (functions), which may be the same or may be implemented in modified forms while providing the same or similar functionality. The thickness of lines, layers and / or regions in the figures may be exaggerated for clarity.

[0031] When two elements A and B are combined using "or", this should be understood as all possible combinations, i.e. A only, B only and A and B, unless expressly specified otherwise in individual cases. As alternative expressions for the same combinations, "at least one of A and B" or "A and / or B" can be used. This also applies to combinations of more than two elements.

[0032] Where singular forms such as "a," "an," and "the" are used and the use of only a single element is not expressly or implicitly required, further examples may use several elements to perform the same function. Where a function is described below as being performed using multiple elements, further examples may use a single element or processing entity to perform the same function. Also, when the terms "include," "including," "comprise," and / or "comprising" are used, it will be understood that the presence of stated features (functions), integers, steps, operations, processes, elements, components, and / or groups thereof is stated, but does not exclude the presence or addition of one or more other features (functions), integers, steps, operations, processes, elements, components, and / or groups thereof.

[0033] FIG. 1a schematically illustrates an apparatus 10 for a digital vehicle key sharing server 100 and a digital vehicle key sharing server 100 including such an apparatus 10. The apparatus 10 includes electrical circuitry configured to provide the functionality of the apparatus 10. For example, the apparatus 10 of FIG. 1a includes an interface circuit 12, a processing circuit 14, and (optional) a storage circuit 16. For example, the processing circuit 14 can be connected to the interface circuit 12 and the storage circuit 16. For example, the processing circuit 14 can be configured to provide the functionality of the apparatus in cooperation with the interface circuit 12 (for exchanging information with other devices, such as the first device 100, the second device 200, or the user device 250) and the storage circuit 16 (for storing information, such as machine-readable instructions). In general, the functionality of the processing circuit 14 can be performed by the processing circuit 14 executing machine-readable instructions. Thus, any feature (function) attributable to the processing circuit 14 can be defined by one or more of a plurality of machine-readable instructions. Device 10 may include machine-readable instructions, for example, in memory circuitry 16 .

[0034] Processing circuitry 14 is configured to obtain, via interface circuitry 12, a request to share a digital vehicle key for one or more vehicles from first device 300 to second device 200, 250. Processing circuitry 14 is configured to determine whether the second device identified by the request is user device 250 or server 200. Processing circuitry is configured to process the request to share the digital vehicle key based on whether the second device identified by the request is a user device or a server.

[0035] 1b shows a flowchart of an example of a corresponding method for the digital vehicle key sharing server 100. The method includes obtaining 110 a request to share digital vehicle keys for one or more vehicles from a first device to a second device. The method includes determining 120 whether the second device identified by the request is a user device or a server. The method includes processing 130 the request to share the digital vehicle key based on whether the second device identified by the request is a user device or a server. For example, the method can be performed by the digital vehicle key sharing server 100.

[0036] In the following, features of the device 10, the digital vehicle key sharing server 100, and corresponding methods (and computer programs) are described with respect to the device 10. Features introduced in relation to the device 10 may likewise be included in the corresponding digital vehicle key sharing server, method, and computer program.

[0037] The process begins with a request to a second device 200, 250 to share digital vehicle keys for one or more vehicles. The request is issued by a first device 300, which is a user device (such as a smartphone, computer, wearable device, etc.) of the owner (also referred to as the vehicle's "sharer"). While in this example we consider the first device to be a user device, the proposed concept can also be used in a purely server-based set, where the first device is a server requesting to share digital vehicle keys with user devices or other servers. While in some systems the first device 300 is responsible for signing digital vehicle keys, in the proposed concept this task is delegated to a digital vehicle key sharing server. However, for compatibility reasons, signing of digital vehicle keys can still be performed by the first device (in addition to the digital vehicle key sharing server).

[0038] In the proposed concept, two cases are distinguished: in the first case, a first device requests a shared digital vehicle key for a user device (e.g., a smartphone, a computer, a wearable device, etc.), and in the second case, the first device requests a shared digital vehicle key for another server (e.g., a "second server"). In the following, the first case is also called direct sharing, while the second case is called indirect sharing or delegated sharing. The first case is illustrated in Figure 1c, and the second case is illustrated in Figure 1d.

[0039] 1c shows a schematic diagram of an example of a system including a digital vehicle key sharing server 100, a first device 300, and a second device, which is a user device 250. In this case, the first device 300 requests the digital vehicle key sharing server to issue a shared digital vehicle key for the user device 250. In FIG. 1d, a schematic diagram of an example of a system including the digital vehicle key sharing server 100, the first device 300, and a second device, which is a second server 200. In this case, the first device 300 requests the digital vehicle key sharing server to allow the second device, which is the second server 200, to issue a request for a shared digital vehicle key. Thus, the second server can request the digital vehicle key sharing server to issue a shared digital vehicle key for the user device 250 (on behalf of the user device).

[0040] To distinguish between these two cases, the request indicates the "type" of the second device, i.e., whether the second device is a user device or a server. The processing circuitry then processes the request to identify whether the second device identified by the request is a user device 250 or a server 200, and processes the request to share the digital vehicle key based on whether the second device identified by the request is a user device or a server.

[0041] As further shown in FIG. 1c, in the first case, i.e., when the request indicates that the second device is a user device, the processing circuitry can be configured to provide, via the first device or directly, an invitation to the second device, which is the user device, to provide the public key of the digital vehicle key (e.g., a certificate including the public key of the digital vehicle key) for signing to the digital vehicle key sharing server. In particular, the invitation can include a uniform resource locator (URL) accessible by the user device to obtain the digital vehicle key (or the certificate including the public key of the digital vehicle key) signed by the digital vehicle key sharing server. In the proposed concept, the user device is provided with key parameters for generating the digital vehicle key and the digital vehicle key generated by the user device (e.g., within a secure element / secure enclave / trusted execution environment of the user device). For example, the digital vehicle key generated by the user device includes the above-mentioned certificate, which can also include the public key of the digital vehicle key together with information about the entitlements carried by the digital vehicle key. For example, the digital vehicle key can include a key pair including a public key and a private key. Once generated, the digital vehicle key public key or a certificate bearing the public key can be provided by the user device to the digital vehicle key sharing server for signing. Consequently, the processing circuitry can be configured to obtain, via the interface circuitry, a request to sign the digital vehicle key public key or a certificate from the user device, to sign the digital vehicle key public key (e.g., a certificate bearing the public key) with the digital vehicle key sharing server's private key, and to provide (via the interface circuitry) the signed digital vehicle key public key (e.g., a signed certificate) to the user device. For example, a request to sign the digital vehicle key public key or a certificate can be obtained in response to an invitation to provide the digital vehicle key public key or a certificate.The user device can provide the signed public key (as part of the certificate) to the vehicle, and the vehicle uses the signed public key (e.g., the signed certificate with the public key) to verify the digital vehicle key used by the user device, and the public key of the digital vehicle key sharing server is stored (saved) on the vehicle where it is used to perform the verification.

[0042] In this disclosure, the terms "signature," "signing," and "authenticating" may be used synonymously. For example, once a digital vehicle key sharing server signs a digital vehicle key (or a second server's public key), it can use its private key to generate a digital signature or digital certificate based on the respective public key. Thus, a "signed public key" or a "signed certificate" may correspond to a digital certificate based on the respective public key or certificate.

[0043] In the second case, the second server is added to a list of entities authorized to issue requests to share a digital vehicle key. For example, if the second device is a server, the processing circuitry can be configured to add the public key of the second device to a storage unit (within the storage circuitry 16) containing one or more public keys (i.e., corresponding to authorized entities) authorized to issue requests to share a digital vehicle key. For example, the public key of the second server can be included in a request to share a digital vehicle key obtained from the first device. The processing circuitry can be configured to extract the public key of the second server from the request. Furthermore, the processing circuitry can be configured to verify the request to share a digital vehicle key based on the public key of the first device contained in the storage unit containing one or more public keys authorized to issue requests to share a digital vehicle key for one or more vehicles. For example, the storage unit can be supported by a database containing associations between vehicles and entities / public keys authorized to issue requests to share a digital vehicle key for each vehicle. When a first device is first paired with a vehicle, the public key of the first device can be added to the store (and thus the database).

[0044] In some examples, the second server may also be provided with a signed public key (or certificate) of the digital vehicle key. For this purpose, the same mechanism used for the second device, which is a user device, may be used. For example, the processing circuitry may be configured to provide, via the first device or directly, to the second device, which is a server, an invitation to provide the public key of the digital vehicle key (e.g., a certificate including the public key of the digital vehicle key) for signing to the digital vehicle key sharing server. For example, the second server may be provided with key parameters for generating the digital vehicle key and the digital vehicle key generated by the second server (e.g., within the secure element / secure enclave / trusted execution environment of the second server). After generation, the public key of the digital vehicle key or a certificate including the public key may be provided by the second server to the digital vehicle key sharing server for signing. As a result, the processing circuitry can be configured to obtain a request or authentication from the user device via the interface circuitry to sign the public key of the digital vehicle key, to sign the public key of the digital vehicle key using the private key of the digital vehicle key sharing server (e.g., authentication with the public key), and to provide the signed public key of the digital vehicle key (e.g., signed authentication) to the user device (via the interface circuitry).

[0045] In addition to storing the second server's public key in the memory unit, the public key can be signed by the digital vehicle key sharing server (i.e., a signature or certificate can be generated based on the digital vehicle key sharing server's private key). For example, if the second device is a server, the processing circuitry can be configured to sign the second device's public key with the digital vehicle key sharing server's private key and to provide the second device's signed public key to the second device for future certification.

[0046] If the second server is found to be authorized to issue requests for shared vehicle keys, it may also provide a request to share the digital vehicle key (e.g., on behalf of the client or to further delegate to another server). For example, the processing circuit may be configured to obtain, via the interface circuit, a second request to share a digital vehicle key for a vehicle from the second device, which is a server, to the user device, and to provide, via the second device or directly, an invitation to the digital vehicle key sharing server providing the digital vehicle key's public key for signing (e.g., a certificate including the public key). Again, the processing circuit may be configured, via the interface circuit, in response to the invitation, to obtain from the user device a request to sign the digital vehicle key's public key (e.g., a certificate having the public key), to sign the digital vehicle key's public key (e.g., a certificate having the public key) with the digital vehicle key sharing server's public key, and to provide the signed digital vehicle key's public key to the user device. As a result, the user device may itself be the second device (first case), or the user device may be the user device that requested the signature of the public key of the digital vehicle key via the second device (second case).

[0047] In some cases, the request to sign the digital vehicle key public key (or certificate) can be verified to avoid the digital vehicle key public key of the “wrong” user device being signed (e.g., by the “wrong” user device blocking the invitation). For example, the request to share the digital vehicle key may include authentication verification information (the user device's public key, information (e.g., a hash) derived from a user account identifier associated with the user device, and information (e.g., a hash) derived from a phone number associated with the user device). The digital vehicle key sharing server can use the authentication verification information to verify the request to share the digital vehicle key public key (or certificate). In other words, the processing circuitry can be configured to verify the request to sign the digital vehicle key public key (or certificate) from the user device based on the authentication verification information. For example, the digital vehicle key public key can be derived from the private key of a key pair that includes the user device's public key. Thus, the digital vehicle key public key can be verified (matched) against the user device's public key. Additionally, the digital vehicle key public key or certificate may contain, as metadata, more information about the user device, such as a user account identifier (or a hash thereof) and / or a phone number (or a hash thereof) that are verified (matched) against information obtained from a user account identifier associated with the user device and against information obtained from a phone number associated with the user device, respectively.

[0048] Further details about the communication between the first device, the digital vehicle key sharing server, and the user device can be seen in Figure 4 (the first device is the sharer in Figure 4, the digital vehicle key sharing server is the vehicle OEM server, and the user device is the sharee). Further details about delegated sharing can be seen in Figure 6 (the second server is the car sharing provider).

[0049] Interface circuitry 12 may support one or more inputs and / or outputs for receiving and / or transmitting information, which may be in digital (bit) values ​​according to codes specified within a module, between modules or between modules of different entities. For example, interface circuitry 12 may include circuitry configured to receive and / or transmit information.

[0050] For example, processing circuitry 14 can be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer, or programmable hardware components operable by appropriately adapted software. In other words, the above-described functions of processing circuitry 14 can also be implemented in software, and the software is executed in one or more programmable hardware components. Such hardware components can include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0051] For example, the memory circuitry 16 may include at least one element of the group of computer-readable storage media such as magnetic or optical storage media, e.g., hard disk drives, flash memory, floppy disks, random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), or network storage.

[0052] Further details and aspects of the device, method, and computer program for the digital vehicle key sharing server, and the digital vehicle key sharing server, are mentioned in relation to the proposed concept or one or more examples described above or below (e.g., FIGS. 2a-6). The device, method, and computer program for the digital vehicle key sharing server, and the digital vehicle key sharing server may include any one or more additional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

[0053] FIG. 2a shows a schematic diagram of an example of an apparatus 20 for a second server 200 and the second server 200 including such an apparatus 20. The apparatus 20 includes electrical circuitry configured to provide the functionality of the apparatus 20. For example, the apparatus 20 of FIG. 2a includes an interface circuit 22, a processing circuit 24, and (optional) a storage circuit 26. For example, the processing circuit 24 can be connected to the interface circuit 22 and the storage circuit 26. For example, the processing circuit 24 can be configured to provide the functionality of the device in cooperation with the interface circuit 22 (e.g., for exchanging information with other devices, such as the digital vehicle key sharing server 100 and / or the user device 250) and the storage circuit 26 (for storing information, such as machine-readable instructions). In general, the functionality of the processing circuit 24 can be performed by the processing circuit 24 executing machine-readable instructions. Thus, any features attributed to the processing circuit 24 can be defined by one or more of a plurality of machine-readable instructions. Device 20 may include machine-readable instructions, for example, in memory circuitry 26 .

[0054] Processing circuitry 24 is configured to obtain, via interface circuitry 22, a first request to access a vehicle from user device 250. Processing circuitry 24 is configured to provide, via interface circuitry 22, a second request to digital vehicle key sharing server 100 based on the first request to provide a digital vehicle key for the vehicle.

[0055] 2b shows a flowchart of an example of a corresponding method for a second server. The method includes obtaining 210 a first request to access the vehicle from a user device. The method includes providing 220 a second request to share a digital vehicle key for the vehicle to a digital vehicle key sharing server based on the first request. For example, the method can be performed by the second server.

[0056] In the following, features of the device 20, the second server 200 and the corresponding method (and computer program) are described with respect to the device 20. Features introduced in relation to the device 20 may likewise be included in the corresponding second server 200, method and computer program.

[0057] As outlined in connection with Figures 1a-1d, after registering the second server with the digital vehicle key sharing server (by storing a public key in a public key storage section authorized to issue requests to share digital vehicle keys, as illustrated in Figure 5), the second server can also issue such requests on behalf of its clients. For example, the second server can be a car sharing provider's server, a fleet management server, a parking lot server, a road assistance company server, etc. Such a server can be used when the vehicle owner / sharer, via the digital vehicle key sharing server, authorizes the second server to issue requests to share digital vehicle keys, to issue such requests on behalf of its clients, or to delegate sharing to yet another server.

[0058] In various examples, such a request is triggered by a user device equipped with such a digital vehicle key providing the above-mentioned first request for access to a vehicle from user device 250. Typically, such a first request can be received after the user device is registered with the second server and information about the second device, such as its public key, is stored in a storage unit of the second server, such as storage circuit 26. For example, as shown in FIG. 6, the user device (recipient in FIG. 6) first installs a corresponding app (car sharing app in FIG. 6), creates an instance CA key pair to be used, and uploads the public key of the key pair to the second server (car sharing provider in FIG. 6). The second server then stores (stores) the public key and associates it with each user device / client. When the user device issues the first request (vehicle reservation in FIG. 6), the second server can use the stored information, including the stored public key, to generate and provide a second request to the digital vehicle key sharing server. In other words, the processing circuitry can be configured to obtain, via the interface circuitry, the public key of the user device (operation 3 in FIG. 6) and a second request corresponding to the public key of the user device (operation 6 in FIG. 6).

[0059] As described above in connection with FIG. 1d, the digital vehicle key sharing server provides an invitation to the user device, e.g., directly or via a second server, to invite the user device to sign the digital vehicle key public key / generate a corresponding certificate. In the latter case, the processing circuitry can be configured to obtain an invitation (Request Key Response (URL) in FIG. 6) to provide the user device's digital vehicle key public key (or a certificate including the public key) to the digital vehicle key sharing server for signing, and to forward the invitation (URL link in FIG. 6) to the user device. From there, the generation and signing of the digital vehicle key may correspond to acts 6-22 (including several optional acts) of FIG. 4. For example, as a next act, the user device can issue a request to sign the digital vehicle key public key (Signing Key Request in FIG. 6).

[0060] In some examples, to authenticate to the digital vehicle key sharing server, the processing circuitry can be configured to obtain a signed version of the second server's public key (or certificate) from the digital vehicle key sharing server (as a result of the second server's registration with the digital vehicle key sharing server). Further details can be found in relation to Figure 5. The second server, and therefore the processing circuitry, can then use the signed public key / certificate to generate a signing endpoint used to authenticate the second server to the digital vehicle key sharing server.

[0061] In some examples, the second server's registration with the digital vehicle key sharing server is not limited to registering (e.g., whitelisting) the second server's public key with the digital vehicle key sharing server. Alternatively, or in addition, the second server may be provided with a valid digital vehicle key. In other words, the processing circuitry may be configured to obtain an invitation to provide the digital vehicle key sharing server with the public key (or a certificate including the public key) of the digital vehicle key for signing, to generate such a digital vehicle key (including the public key, private key, and optionally the certificate), and to provide the digital vehicle key sharing server with a request to sign the public key of the digital vehicle key (or the certificate) with the public key of the digital vehicle key or the certificate (including the public key). In response to the request, the processing circuitry may be configured to obtain the signed public key or certificate from the digital vehicle key sharing server.

[0062] Interface circuitry 22 may support one or more inputs and / or outputs for receiving and / or transmitting information, which may be in digital (bit) values ​​according to codes specified within a module, between modules or between modules of different entities. For example, interface circuitry 22 may include circuitry configured to receive and / or transmit information.

[0063] For example, processing circuitry 24 can be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer, or programmable hardware components operable by appropriately adapted software. In other words, the above-described functions of processing circuitry 24 can also be implemented in software, and the software is executed in one or more programmable hardware components. Such hardware components can include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0064] For example, the memory circuitry 26 may include at least one element of the group of computer-readable storage media such as magnetic or optical storage media, e.g., hard disk drives, flash memory, floppy disks, random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), or network storage.

[0065] Further details and aspects of the apparatus, method, and computer program for the second server, and the second server, are mentioned in relation to the proposed concept or one or more examples described above or below (e.g., FIGS. 1a-1d, 3a-6). The apparatus, method, and computer program for the second server, and the second server, may include any additional one or more features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

[0066] FIG. 3 a shows a schematic diagram of an example of an apparatus 30 for a first server 300 and a first server 300 including such an apparatus 30. The apparatus 30 includes electrical circuitry configured to provide the functionality of the apparatus 30. For example, the apparatus 30 of FIG. 3 a includes an interface circuit 32, a processing circuit 34, and (optional) a storage circuit 36. For example, the processing circuit 34 can be connected to the interface circuit 32 and the storage circuit 36. For example, the processing circuit 34 can be configured to provide the functionality of the apparatus in cooperation with the interface circuit 32 (for exchanging information with other devices, such as the digital vehicle key sharing server 100 and / or the user device 250) and the storage circuit 36 ​​(for storing information, such as machine-readable instructions). In general, the functionality of the processing circuit 34 can be performed by the processing circuit 34 executing machine-readable instructions. Thus, any features attributed to the processing circuit 34 can be defined by one or more of a plurality of machine-readable instructions. Device 30 may include machine-readable instructions, for example, in memory circuitry 36 .

[0067] The processing circuitry 36 is configured to generate a request to a second device 200; 250 to share a digital vehicle key for one or more vehicles, the request indicating whether the second device identified by the request is a user device or a second server. The processing circuitry is configured to provide the request to the digital vehicle key sharing server 100.

[0068] 3b shows a flowchart of an example of a corresponding method for a first device. The method includes generating 310 a request to a second device to share digital vehicle keys for one or more vehicles, the request indicating whether the second device identified by the request is a user device or a second server. The method includes providing 320 the request to a digital vehicle key sharing server. For example, the method can be performed by the first device 300.

[0069] In the following, features of the apparatus 30, the first device 300 and the corresponding methods (and computer programs) are described with respect to the apparatus 30. Features introduced in relation to the apparatus 30 may likewise be included in the corresponding first device 300, methods and computer programs.

[0070] In the proposed concept, the first device 300 is the initiator of the sharing procedure, either directly to a user device or to a second server to delegate the sharing rights. Initially, the first device 300 is the entity that holds the right to create a shared digital vehicle key for the vehicle, for example, because the first device 300 is the user device of the vehicle co-owner / owner who is paired with the vehicle. To distinguish between the two cases described above, the processing circuit is configured to generate each request such that the request indicates whether the second device identified by the request is a user device or a second server. As shown in relation to FIG. 4 , a “device profile” tag can be included in the request, and the tag has two possible values: “device” and “server.” The request can further include additional information, such as information about one or more vehicles to be shared and information about the second device (including the second device’s public key for the purpose of generating a signed version / certificate of the public key for the second device’s verification and / or authentication purposes). More information about the possible fields of the request is provided in connection with FIG. 4, and particularly with operation 1 of FIG.

[0071] In cases where the second device is a user device (or in some cases where the second device is a server), at least some portion of the communication between the digital vehicle key sharing server and the second device can occur via the first device. In particular, as shown in Figure 4, the processing circuitry can be configured to obtain an invitation from the digital vehicle key sharing server to provide the public key of the digital vehicle key of the user device (or second server) to the digital vehicle key sharing server for signing (e.g., operations 4 and 5 of Figure 4), and to forward the invitation to the second device / user device. For example, the invitation can be shared using a messaging protocol or via an application of the vehicle's original equipment manufacturer (OEM).

[0072] The interface circuitry 32 may support one or more inputs and / or outputs for receiving and / or transmitting information, which may be in digital (bit) values ​​according to codes specified within the modules, between modules or between modules of different entities. For example, the interface circuitry 32 may include circuitry configured to receive and / or transmit information.

[0073] For example, processing circuitry 34 can be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer, or programmable hardware components operable by appropriately adapted software. In other words, the above-described functions of processing circuitry 34 can also be implemented in software, and the software is executed in one or more programmable hardware components. Such hardware components can include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0074] For example, the memory circuitry 36 may include at least one element of the group of computer-readable storage media such as magnetic or optical storage media, e.g., hard disk drives, flash memory, floppy disks, random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), or network storage.

[0075] Further details and aspects of the apparatus, method, and computer program for the first device, and the first device, are mentioned in relation to the proposed concept or one or more examples described above or below (e.g., FIGS. 1a-2b, 4-6). The apparatus, method, and computer program for the first device, and the first device, may include any additional one or more features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

[0076] Various examples of the present disclosure relate to a concept for a server based key sharing of digital keys. In the proposed concept, an unpaired owner (i.e., sharer) may be required for key sharing. Instead of or in addition to a paired owner, key sharing can be done by a server instance (i.e., a digital vehicle key sharing server, hereinafter referred to as a vehicle OEM server). The vehicle OEM server can enable key sharing between devices, between a server and a device, and authentication of the server for key sharing for one or several vehicle identifiers (e.g., for purposes such as fleet management server, parking, road assistance, etc.).

[0077] The public key for verifying the vehicle OEM server's signature on the shared key may be known to the vehicle (eg, stored in the vehicle's secure element).

[0078] A requesting instance (further referred to as a sharer), which may be a user device (phone, watch, etc.) or a server, can request a shared key at a key management server (i.e., vehicle OEM server / digital vehicle key sharing server) by providing information about the key characteristics and the key recipient (further referred to as a sharee, i.e., a second device). For example, the sharer may be a user device (phone, watch, etc.) or a server. The sharer may be known by the key management server by its endpoint public key.

[0079] In the case where the sharer is a server, a digital key may not be created (at that time). Instead, the sharee instance CA public key (i.e., the public key of the second server) can be whitelisted (i.e., added to a store containing one or more public keys that can issue requests to share a digital vehicle key) at the vehicle OEM server to enable it to request a shared key for the requested vehicle identifier.

[0080] In the proposed concept, the vehicle OEM server can create a key creation request that is sent to the recipient. The recipient can create a digital key and send a key signing request. After receiving the key signing request from the recipient, the vehicle OEM server can sign it with its endpoint private key. Because the vehicle OEM server's endpoint public key is known in the vehicle, the vehicle can verify the authenticity of the shared key and grant access to the vehicle.

[0081] The following describes one exemplary implementation of sharing digital vehicle keys via a digital vehicle key sharing server (hereinafter referred to as a "vehicle OEM server," where OEM is an original equipment manufacturer, such as an automobile manufacturer).

[0082] In this example, the vehicle OEM server can enable key sharing between devices, between the server and the device, and authentication of the server (e.g., fleet management server, parking, road assistance, etc.) for sharing of keys for one or several vehicle identifiers, i.e., one or more vehicles. To authenticate a server (i.e., a second server) as a possible sharer, the server's public key is sent to the vehicle OEM server. The vehicle OEM server can maintain a database of vehicle identifiers (representing corresponding vehicles) and authenticated public keys can request keys for build-up; database maintenance is outside the scope of this disclosure.

[0083] Increased security during key sharing can be achieved by verifying the sharee (i.e., user device) before signing the shared key. To this end, the vehicle OEM server can, for example, compare a hash of the sharer's intended recipient's account ID with the actual recipient of the digital key, or can use a hash of the sharer's phone number or public key for this purpose.

[0084] The following sequence diagrams explain key sharing via the vehicle OEM server in more detail. Figure 4 shows a sequence diagram of an example of server-based key sharing to a user device. Five entities are shown in the sequence diagram of Figure 4: a sharer (which can be a first device or a second server), a vehicle OEM server (i.e., a digital vehicle key sharing server), an optional relay server (an optional communication relay between the vehicle OEM server and the sharee), a sharee (i.e., a user device), and an optional KTS (Key Tracking Server).

[0085] The following describes in more detail operations 1-22 shown in Figure 4. As will become apparent, at least some of these operations are optional.

[0086] In operation 1 (Request for Sharing, i.e., providing a request to share a digital vehicle key), the sharer sends the information necessary to create the key to the vehicle OEM server. If the instance CA public key (i.e., the sharee's public key) is known to the sharer (e.g., through a pre-provisioned trust relationship or trusted server lookup), the sharer can add the sharee's instance CaPk (i.e., the sharee's public key) to the request. The sharer can optionally request the use of a second factor to activate the shared key by setting the activation required flag. If the share is directed to a server instance (i.e., if the request indicates that a second device is a server to enable the sharee for delegated sharing), a tag indicating that the sharee is a server (hereinafter referred to as a "device profile") can be included in the request. The sharer can specify a designated relay server to be used in the share. The request can be signed by the sharer, followed by authentication of any data, such as a SHA-256 hash value of the request, with the sharer's key (i.e., the sharee's private key). For example, the request may include one or more of the following fields: a field containing one or more vehicle identifiers for one or more vehicles to be shared, a key configuration information field, a server key field, an activation request field, a device pin field, a maximum number of device pin attempts field, a recipient one-time account identifier hash field, a field containing a nonce used to create the recipient one-time account identifier hash, a recipient phone number hash field, a field containing a nonce used to create the recipient phone number hash, and a recipient instance CA public key field (i.e., the recipient's public key). The latter entry can be used to authenticate the recipient.

[0087] A request containing one or more of the above fields can be signed with the sharer's private key, and the signature can be transmitted along with the request.

[0088] In acts 2-4 (Create Key Creation Request), if the sharer sends the sharer instance CaPk, the vehicle OEM server can store the key for future requests for a shared key for a matching vehicle identifier. If the device profile is set to "Server" (i.e., the second device is the server), in some examples, the vehicle OEM server can send only a RequestKeyResponse() message (without acts 2 and 3) and the process can end. Alternatively, the entire process can be completed, including providing a representation of the digital key to the sharee, who is the server.

[0089] At least when the device profile is set to "Device" (i.e., "User Device"), and in some instances when the device profile is set to "Server," the vehicle OEM server can create a key creation request (including the device profile and the maximum number of shares allowed). If an intermediary server is used as an intermediary between the vehicle OEM server and the sharee, it can generate a secret used to encrypt the payload for the mailbox creation API, as described in the Internet Engineering Task Force (IETF). Secure Credential Transfer - Drafting Secure Credential Transfer - 03 The vehicle OEM server can send a mailbox creation request to the intermediary server. After receiving the mailbox link, the vehicle OEM server can send a response, a Request Key Response, to the sharer device.

[0090] In operations 5 to 8 (key creation), the sharer can forward the invitation to the sharee. After downloading the key creation request, the sharee can create a digital key. The sharee can create a signature request (i.e., a request to sign the public key of the digital vehicle key) including the sharee instance CaPk (i.e., the sharee's public key) and upload it to the mailbox of the relay server.

[0091] In operations 9-13 (Key Signing), after downloading the key signing request from the relay server, the vehicle OEM server can optionally compare the recipient one-time account ID hash or recipient instance CaPk included in the signing request with the one received from the sharer in the request for the key. If the keys match, the vehicle OEM server can sign the key (i.e., the public key of the digital vehicle key) and create an import request. The vehicle OEM server can upload the import request to the relay server's mailbox.

[0092] In operations 14 to 17 (import of key data), the sharee can download the import request and can also request erasure of the mailbox of the relay server (if a relay server is used for communication).

[0093] In operations 18-20 (Optional Key Tracking), if key tracking is required, the recipient can request a signed certificate from the key tracking server. Optionally, the key tracking server can notify the vehicle OEM server of the success of the key tracking.

[0094] In operation 21 (Notify Sharer), the vehicle OEM server may notify the sharer of the successful key sharing after uploading the import request to the relay server or after any key tracking.

[0095] In some examples, it is possible to perform secure recipient verification. For example, verification may be performed via a device OEM account identifier hash. To improve security during key sharing, the vehicle OEM server can optionally compare the identity of the sharer's intended recipient with the actual recipient of the digital key. For example, the identity may be one of the following: an account identifier hash, a phone number hash, and the recipient's public key.

[0096] For example, the sharer can request a one-time hash of the intended sharee's account ID hash from the account database server (hereinafter, e.g., this is the device OEM server, where both the sharer and the sharee belong to the same device OEM). The account database server can select a nonce that can be added to the account ID hash to anonymize the ID. The nonce can be shared by the sharer and forwarded to the vehicle OEM server. Using the account ID hash included in the instance CA certificate (i.e., the sharee's public key) sent by the sharee in the key signing request, the vehicle OEM server can recalculate the one-time account ID and compare it to the one received in the request key request from the sharer.

[0097] The following is an example implementation of delegated key sharing (i.e., key sharing via a second server). Such delegated sharing can enable consumer-to-business use cases (enabling a third-party service provider to share keys for personally owned vehicles) and business-to-consumer use cases (a third-party service provider sharing keys with consumers or employees for vehicles in a personally owned or full commercial fleet). The public key of the provider's server (i.e., the public key of the second server) can be registered with the vehicle OEM server (i.e., the digital vehicle key sharing server) so that a third-party service provider (e.g., car sharing, parking, or roadside assistance) can issue keys to its subscribers / consumers for a vehicle. After registration, the service provider can hold an instance CA certificate via its public key (i.e., the signature of the second server's signed public key) signed by the vehicle OEM server. The instance CA certificate can be used by the service provider to create an endpoint certificate that can be used to sign an online sharing request (i.e., a second request to share a digital vehicle key) when sending a request key message to the vehicle OEM server.

[0098] Once registered, each shared digital key holder can choose to authorize the service provider to request keys for the vehicle associated with the holder's digital key. This can be done in an application or web interface by selecting the service provider from a list provided by the vehicle OEM. The process of registering a public key is beyond the scope of this disclosure, but for completeness, an example is provided below.

[0099] To register a third-party service provider server (i.e., a second server) and thus obtain an instance CA certificate for the service provider server, a key pair is created and a certificate signing request (CSR) is sent to the vehicle OEM server. This is shown in the following sequence as an example of registering a car sharing provider. FIG. 5 shows a sequence diagram of an example of registering a car sharing server in a digital vehicle key sharing server. As shown in FIG. 5, the car sharing provider server can create a key pair (including a secret / private key (sk) and a public key (pk)) in operation (1) and register the public key with the vehicle OEM server in operation (2). The vehicle OEM can generate a certificate based on the public key (i.e., a signature on the public key) that can be used as an instance CA for the car sharing provider server and provide the certificate to the car sharing provider server in operation (3). In operation (4), the car sharing provider server can create an endpoint signed by the instance CA. The third-party service provider can create an endpoint signed by the instance CA that is used to sign a request key request.

[0100] In this disclosure, an endpoint is the end of a certificate chain. The purpose of the certificate chain is to allow the sharer's Secure Element (SE) or the Key Management Server's Secure Element (SE) to verify that the sharee's endpoint is authorized to participate in the sharing protocol. This verification is necessary to confirm that the sharee's key pair was actually generated in an authorized SE and to ensure that secret data transferred from the sharer's confidential mailbox to the sharee's confidential mailbox is properly processed. Each sharer endpoint may include one or several certified public keys (Auth_PKs) configured by the vehicle during the owner / sharer pairing process. The Authentication_PK list includes at least the public key of the vehicle OEM CA. The external CA is typically the device OEM CA used to issue the instance CA certificate for the Digital Key Applet. The instance CA then issues the endpoint certificate. Validation of the sharee's endpoint proceeds through the following validation chain: Each element to the right of the arrow is attested by the element before it: Certified CA (Vehicle OEM CA) → External CA (Device OEM CA) → Instance CA → Endpoint → Endpoint Encryption Key

[0101] A sharer can authorize a third-party service provider's server to issue keys for its vehicle by sharing the key with the server. When sending a share request, the sharer can set the server key flag (by setting the device profile to "server") and include the service provider's public key (i.e., the public key of the second server).

[0102] Once a sharee is registered with the vehicle OEM server, the trusted sharee server can issue a key to the sharee. An authorized third-party service provider can request a key for that consumer / employee by sending its public key to the vehicle OEM server as the sharee information (i.e., as part of the second request to share the digital vehicle key). This allows the vehicle OEM server to verify the key recipient before signing the shared key.

[0103] The sharee's public key may be known to the third-party service provider prior to requesting the key, and the process of sending the public key to the third-party service provider and forwarding the sharing URL to the sharee is outside the scope of this disclosure but is included in the sequence shown in Figure 6 for completeness. Figure 6 shows a sequence diagram of a simplified example of server-based key sharing to a user device via a car sharing server.

[0104] In operations 1 to 3, the service provider obtains the public key of the recipient. For example, a third-party service provider application installed on the recipient's device can request an instance CA from its native OS when making a reservation or installing the third-party service provider's app, and send it to the service provider's server.

[0105] In operations 4-7 (forward to mailbox, uniform resource locator, URL), the service provider server creates a request key request and signs it with the endpoint secret key (signed by the pre-registered instance CA). The request (i.e., the second request to share the digital vehicle key) can carry the recipient's public key, which can be used by the vehicle OEM server to verify the recipient of the shared key before signing it. The URL (i.e., invitation) received from the vehicle OEM server can be forwarded to the app on the recipient's device.

[0106] In operations 8-11 (creating and signing a shared key), a key is created on the recipient's device and a key signing request is sent to the vehicle OEM server. The vehicle OEM server can verify the authenticity of the created key by comparing the public key of the instance CA in the key signing request from the recipient with the public key received in the request key request from the recipient. If the two keys match, the vehicle OEM server can sign the key and send an import request to the recipient's device.

[0107] Below we provide some examples of the entities mentioned above.

[0108] For example, the vehicle OEM server can host the sharer account associated with the sharee's vehicle; can sign the shared digital key structure for acceptance by the vehicle while ensuring business policies are checked, and the digital key is tracked; can provide the vehicle (when online) with the necessary attestations so that the shared sharer's digital key is accepted by the vehicle in the first sharee's transaction; can sign the vehicle's public key; can provide the necessary certificates to the device OEM; can provide the vehicle OEM and (optionally) the device OEM's public keys to the vehicle for sharer pairing and sharee sharing; can have a trust relationship with the supplier (based on public key infrastructure PKI); can issue provisioning keys; can manage relay server mailbox links for digital key distribution; can verify the legitimate recipient of the shared key.

[0109] The (user) device can include a secure processing and storage environment (such as a secure element, secure enclave, trusted execution environment, or equivalent) that runs the Digital Key Applet. It can take on the roles of a sharer's device and a recipient's device. The sharer's device can perform functions such as digital key agreement and store (store) the necessary certificates. The sharer can be any entity that has a (PKI)-based trust relationship with the vehicle OEM server, including the sharer's device and the recipient's server. The recipient's device can perform functions such as digital key agreement (as a receiver) and store (store) the necessary certificates.

[0110] The third-party service provider's server (i.e., the second server) can be pre-registered with the vehicle OEM server and can be authenticated by the sharer's key (or by the administrator) to initiate digital key sharing with other participants.

[0111] The intermediary server can provide a standardized communication channel to support key agreement between two devices from different (or the same) OEMs. It can perform push notifications and supports a polling mechanism to keep the device informed during the key agreement process.

[0112] Digital key systems are based on signature verification using asymmetric cryptography: a vehicle will unlock its doors or start its engine only if the attempt is signed by a private key that corresponds to a public key registered in the vehicle.

[0113] After the sharer's device and the vehicle are paired, the sharer possesses a private key for which a corresponding public key is stored on the vehicle. For key sharing via the vehicle OEM server, the vehicle OEM server public key can be registered on the vehicle during the manufacturing process or when the vehicle software is configured for digital key use.

[0114] To make the shared key accessible to the vehicle, the sharer or vehicle OEM server can use its private key to sign the sharee's public key. Upon presenting the sharer's signature or the vehicle OEM server's signature on the sharee's public key, the vehicle can then accept the shared key as a new vehicle user and save (store) the sharee's public key. To activate the vehicle OEM server to use the private key to sign the sharee's public key, the device can authenticate the OEM server.

[0115] Digital key sharing can involve a sharer sending an invite URL to a sharee, and a stateful exchange of key creation, key signing, and data import requests. If a secure sharing channel is used, such as a proprietary messaging channel managed by the device OEM, the invite and stateful sharing messages can all be sent over that channel.

[0116] In general, a digital key may contain various elements, including one or more vehicle identifiers (to uniquely identify the vehicle), an endpoint identifier (for key management within the device), a digital key identifier, and an instance CA identifier (for the instance that signed the digital key).

[0117] Before signing the recipient's public key, the sharer can verify that the recipient's public key pair was created in a qualified SE. The verification chain begins with a certified public key in the sharer's digital key structure provided and trusted by the vehicle, e.g., the vehicle OEM CA public key. The shared digital key can further include a certification package containing the recipient's public key (signed by the sharer / vehicle OEM server) and information about the validity of the shared digital key.

[0118] The proposed concept can be used by vehicle manufacturers, (smart) device manufacturers, car sharing providers, third party service providers (road assistance, valet parking, etc.) and others related to digital car keys.

[0119] Aspects and features described in connection with a particular one of the above examples may also be combined with one or more of the other examples to replace identical or similar features of the other examples or to introduce additional features into the other examples.

[0120] An example may be or relate to a (computer) program including program code for performing one or more of the above-described methods when the program is executed on a computer, processor, or other programmable hardware component. Accordingly, the steps, operations, or processes of different ones of the above-described methods may also be performed by a programmed computer, processor, or other programmable hardware component. An example may also cover a program storage device, such as a digital data storage medium, that encodes machine-readable, processor-readable, or computer-readable and / or machine-executable, processor-executable, or computer-executable programs and instructions. The program storage device may be or include, for example, a digital storage device, a magnetic storage medium such as a magnetic disk and magnetic tape, a hard disk drive, or an optically readable digital data storage medium. Other examples may include a computer, processor, control unit, (Field) Programmable Logic Array ((F)PLA), (Field) Programmable Gate Array ((F)PGA), Graphics Processing Unit (GPU), Application Specific Integrated Circuit (ASIC), Integrated Circuit (IC) or System-on-Chip (SoC) system programmed to perform the steps of the above-described methods.

[0121] It is further understood that the disclosure of several steps, processes, operations, or functions disclosed in this specification or claims should not be construed as implying that these operations are necessarily order dependent unless expressly stated in individual cases or required for technical reasons. Thus, the above description does not limit the execution of several steps or functions to a particular order. Furthermore, in further examples, a step, function, process, or operation may include and / or be divided into several sub-steps, sub-functions, sub-processes, or sub-operations.

[0122] When some aspects are not described in the context of an apparatus or system, the aspects should also be understood as a description of a corresponding method. For example, a block, an apparatus, or a functional aspect of an apparatus or system may correspond to a feature such as a method step of a corresponding method. Thus, aspects described in the context of a method should also be understood as a description of a corresponding block, a corresponding element, a characteristic or functional feature of a corresponding apparatus, or a corresponding system.

[0123] Each claim below is hereby incorporated into the detailed description, and each claim may stand alone as a separate example. It should also be noted that although each claim may refer to a specific combination of an independent claim with one or more other claims, other examples may also include the combination of the independent claim with any other dependent or independent claim structure. This explicitly suggests such a combination, unless stated in individual cases that a specific combination is not intended. Furthermore, each claim structure should also be included with any other independent claim, even if that other independent claim is not directly defined as dependent on that other independent claim.

Claims

1. A device (10) for a digital vehicle key sharing server (100), wherein the device is Interface circuit (12) and Through the interface circuit, a request is received from the first device (300) to the second devices (200; 250) to share a digital vehicle key for one or more vehicles. To specify whether the second device identified by the request is a user device (250) or a server (200), and Based on whether the second device identified by the request is a user device or a server, the system processes the request to share the digital vehicle key. The configured processing circuit (14) and A device that includes this.

2. The apparatus according to claim 1, wherein the processing circuit is configured to verify a request to share a digital vehicle key based on the public key of the first device contained in a storage unit which contains one or more public keys that are permitted to issue requests to share a digital vehicle key for one or more vehicles.

3. The apparatus according to claim 2, wherein, when the second device is a server, the processing circuit is configured to add the public key of the second device to the storage unit which contains one or more public keys that are permitted to issue requests for sharing digital vehicle keys.

4. The apparatus according to claim 3, wherein, when the second device is a server, the processing circuit is configured to sign the public key of the second device using the private key of the digital vehicle key sharing server, and to provide the signed public key of the second device to the second device for future authentication.

5. The apparatus according to any one of claims 1 to 4, characterized in that the processing circuit is configured to obtain a second request from the second device, which is a server, to the user device via the interface circuit for sharing a digital vehicle key for a vehicle, and to provide the user device with an invitation to provide the public key of the digital vehicle key for signing the digital vehicle key sharing server, either via the second device or directly.

6. The apparatus according to any one of claims 1 to 4, characterized in that the processing circuit is configured to provide the second device with an invitation to provide the public key of a digital vehicle key for signing the digital vehicle key sharing server, either via the first device or directly.

7. The apparatus according to claim 5, wherein the processing circuit is configured to sign the public key of the digital vehicle key using the private key of the digital vehicle key sharing server, and to provide the signed public key of the digital vehicle key to the second device, so as to obtain a request from the second device via the interface circuit to sign the public key of the digital vehicle key.

8. The apparatus according to claim 7, characterized in that a request to sign the public key of the digital vehicle key is obtained in response to an invitation to provide the public key of the digital vehicle key.

9. The apparatus according to claim 7, characterized in that a request for sharing a digital vehicle key includes authentication verification information, and the processing circuit is configured to verify a request for signing the public key of the digital vehicle key based on the authentication verification information.

10. A device for a second server (200), wherein the device is Interface circuit (22) and To obtain a first request from a user device (250) to access the vehicle via the interface circuit (22), Based on the first request, a second request for sharing a digital vehicle key for the vehicle is provided to the digital vehicle key sharing server (100). The configured processing circuit (24) and An apparatus characterized by containing

11. Apparatus for a first device (300), wherein the apparatus is Interface circuit (32), To generate a request to a second device (200; 250) for sharing digital vehicle keys for one or more vehicles, indicating whether the second device identified by the request is a user device or a server, The request is to be provided to the digital vehicle key sharing server (100). The configured processing circuit (34) and An apparatus characterized by containing

12. A method for a digital vehicle key sharing server (100), wherein the method is Obtaining a request from a first device to a second device to share a digital vehicle key for one or more vehicles (110), Identifying whether the second device identified by the request is a user device or a server (120), and Processing a request to share the digital vehicle key based on whether the second device identified by the request is a user device or a server (130) A method characterized by including the following.

13. A method for a second server (200), wherein the method is Obtaining a first request for access to the vehicle from the user device (210), Based on the first request, provide the digital vehicle key sharing server with a second request for sharing a digital vehicle key for the vehicle (220) A method characterized by including the following.

14. A method for a first device (300), wherein the method is Generating the request to share a digital vehicle key for one or more vehicles to the second device, indicating whether the second device identified by the request is a user device or a server (310), To provide the request to the digital vehicle key sharing server (320) A method characterized by including the following.

15. A computer program having program code for performing the method of claim 12, the method of claim 13, or the method of claim 14 when the computer program is executed in a computer, processor, or programmable hardware component.

Images