Scheme for server-based sharing of digital keys

Abstract

Examples relate to an approach for server-based sharing of digital keys, and more particularly, but not exclusively, to apparatuses, methods, and computer programs for a digital vehicle key sharing server, for a second server, and for a first device. An apparatus (10) for a digital vehicle key sharing server (100) is configured to obtain, via an interface circuit, data from a first device (300) for transmitting data to a second device (200; the method includes receiving a request for sharing a digital vehicle key for one or more vehicles from a second device specified by a user device (250), determining whether the second device specified by the request is the user device (250) or a server (200), and processing the request for sharing the digital vehicle key based on whether the second device specified by the request is the user device or the server.

Description

Technical Field

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

[0002] The digital car key defined in the Car Connectivity Consortium (CCC) standard versions 2 and 3 standardizes an access system including smart devices, vehicles, and backend systems. Smart devices use software that carries a digital key embedded in a secure storage device on the smart device, provide an interface from the secure storage device to the smartphone operating system and provide an interface from the smartphone operating system to other applications running on the smartphone (e.g., applications of the vehicle OEM). The vehicle allows the carrier of the digital key to operate certain vehicle functions. The backend system interconnects the smart device and the vehicle, allowing the digital key to be shared and managed and providing additional services.

[0003] Typically, a digital key for a specific vehicle can only be key shared by the owner 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 passes these parameters to the "shared" device (via a relay server). After the key is created by the sharee device (in its secure element) and an "endpoint certificate" containing the parameters that the key has been created is derived, the sharee device sends a key signing request including the sharee certificate chain back to the owner, and the owner proves that the key has been created based on the key creation request by signing the endpoint certificate with its (endpoint's) private key ("key sharing proof"). The owner's public key is known to the vehicle through the owner pairing process. Optionally, the sharee sends a key tracking request to a key tracking server.

[0004] During the first contact between the sharee and the vehicle, using the owner's public key, the vehicle verifies the owner's signature with the sharee key (which is included in the attestation package) to ensure that the presented key is legitimate. After signature verification, the sharee key can be used for engine starting.

[0005] However, in the above system, keys can only be shared from one paired owner device, because only that device contains the necessary private key. In addition, it is impossible for the sharee key to further share keys, nor is it possible for the owner to delegate sharing authority to another key or entity.

[0006] There may be a desire for improved solutions for key sharing of digital keys for vehicles. Summary of the invention

[0007] This expectation is solved by the subject-matter of the independent claims.

[0008] The solution proposed in the present disclosure is based on the discovery that a server-based approach can be used to alleviate the above-mentioned shortcomings. Instead of having the sharer / owner's device (hereinafter referred to as the "first device") sign the digital car key being shared, the sharer device is only used to trigger the sharing process at the digital vehicle key sharing server. In order to support both direct sharing of the sharee device (hereinafter referred to as the "user device") and indirect sharing via another server (hereinafter referred to as the "second server", which can be a server of a car sharing service), the owner device or entity with sharing authority sends a request to the second device for sharing digital vehicle keys for one or more vehicles, indicating whether the second device is a user device or a server. The digital vehicle key sharing server can then take appropriate actions depending on whether the second device is a sharee 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 comprising an interface circuit and a processing circuit. The processing circuit is configured to obtain a request for sharing a digital vehicle key for one or more vehicles to a second device via the interface circuit from a first device. The processing circuit is configured to determine whether the second device specified by the request is a user device or a server. The processing circuit is configured to process the request for sharing a digital vehicle key based on whether the second device specified by the request is a user device or a server. By including a digital vehicle key sharing server, sharing is not bound to a single device of the owner. In addition, the sharing process is untied from the device so that sharing can be performed even when the owner's device is offline. Finally, the same mechanism can be used to achieve both direct sharing of the sharee's device (i.e., user device) and indirect sharing (via the second server).

[0010] For example, the processing circuitry may be configured to verify a request to share a digital vehicle key based on a public key of a first device contained in a storage device that includes one or more public keys that are permitted to issue a request to share a digital vehicle key for one or more vehicles. Thus, the same mechanism may be used for sharing by the first device and for sharing by the second server. Furthermore, additional devices of the owner may be added to the devices that are permitted to issue a request to share a digital vehicle key for one or more vehicles.

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

[0012] In various examples, the processing circuitry may be configured to, if the second device is a server, sign the public key of the second device using the 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 authentication. The signed public key may then be used by the second server to authenticate the relationship with the digital vehicle key sharing server.

[0013] The processing circuit may be configured to obtain a second request for sharing a digital vehicle key for a vehicle with a user device via an interface circuit from a second device as a server, and provide an invitation to provide a public key of a digital vehicle key for signing to a digital vehicle key sharing server via the second device or directly to the user device. For example, the public key of the digital vehicle key may be part of a certificate that includes information about the rights of the public key and the digital vehicle key. Therefore, the processing circuit may be configured to provide an invitation to provide a certificate including a public key of a digital vehicle key for signing to a digital vehicle key sharing server via the second device or directly to the user device. The same mechanism may also be used for a second device as a user device. Therefore, the processing circuit may be configured to provide an invitation to provide a public key of a digital vehicle key for signing (or a certificate including a public key) to a second device (as a user device or a server) via the first device or directly to the second device. The user device or the second server may use the invitation to have its corresponding public key signed by the digital vehicle key sharing server.

[0014] According to an example, the processing circuit may be configured to obtain a request for signing a public key of a digital vehicle key (or a certificate including a public key) from a second device (e.g., from a user device or from a second server) via an interface circuit, sign the public key of the digital vehicle key (e.g., a certificate with a public key) using a private key of a digital vehicle key sharing server, and provide the signed public key of the digital vehicle key (e.g., a signed certificate including a public key) to the second device (e.g., to the user device or to the second server). As discussed above, a request for signing a public key or a certificate of a digital vehicle key may be obtained in response to an invitation to provide a public key of a digital vehicle key. In the vehicle, the public key of the digital vehicle key sharing server is stored in a key repository. The signed public key of the digital vehicle key, such as a signed certificate, may then be used to authenticate the relationship of the user device (or the second server) to the vehicle, which may verify the signed public key or certificate of the digital vehicle key using the public key of the digital vehicle key sharing server.

[0015] According to an example, the user device may be the second device, or the user device may be a user device that has requested a signature of a public key (or certificate) of a digital vehicle key via the second device (as a server). In other words, both direct key sharing and indirect key sharing are supported.

[0016] In various examples, the request to share the digital vehicle key may include authentication verification information. The processing circuitry may be configured to verify the request to sign the public key (or certificate) of the digital vehicle key on the authentication verification information. This may provide additional security in the event that the invitation is provided to a "wrong" 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. These features may all be used to bind the invitation to a specific 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 obtain a first request for accessing a vehicle from a user device via the interface circuit. The processing circuit is configured to provide a second request for sharing a digital vehicle key for a vehicle to a digital vehicle key sharing server 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. Prior to assuming the intermediary role, the public key of the second server may have been added to a storage device including one or more public keys that are allowed to issue requests for sharing digital vehicle keys.

[0019] In some examples, the processing circuit may be configured to obtain a public key of the user device via the interface circuit. The second request may include the public key of the user device. This may implement a form of authentication of the user device. Alternatively or additionally, the user device may include the aforementioned 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 an example, the processing circuit may be configured to obtain an invitation for providing a public key (or a certificate including a public key) of a digital vehicle key of a user device for signing to a digital vehicle key sharing server, and forward the invitation to the user device. The invitation may then allow the user device to provide a public key (e.g., a certificate with a public key) of a digital vehicle key of the user device for signing to the digital vehicle key sharing server.

[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 for sharing a digital vehicle key for one or more vehicles with a second device. The request indicates whether the second device specified 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 may then take appropriate actions, as outlined above.

[0022] For example, the request may include information about the one or more vehicles being shared and information about the second device. The former information may be used by the digital vehicle key sharing server to determine the scope of sharing, and the latter information may be used by the digital vehicle key sharing server to determine the recipient of sharing.

[0023] Some aspects of the present disclosure relate to a method for a digital vehicle key sharing server. The method includes obtaining a request from a first device to share a digital vehicle key for one or more vehicles with a second device. The method includes determining whether the second device specified by the request is a user device or a server. The method includes processing the request for sharing a digital vehicle key based on whether the second device specified 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 includes obtaining a first request for accessing a vehicle from a user device. The method includes providing a second request for sharing a digital vehicle key for a vehicle to a digital vehicle key sharing server based on the first request.

[0025] Some aspects of the present disclosure relate to a method for a first device. The method includes generating a request for sharing a digital vehicle key for one or more vehicles with a second device. The request indicates whether the second device specified by the request is a user device or a server. The method includes providing the request to a digital vehicle key sharing server.

[0026] One aspect of the present disclosure relates to a computer program having a program code for performing one of the above methods when the computer program is executed on a computer, a processor or a programmable hardware component. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0028] Figure 1a A schematic diagram showing an apparatus for a digital vehicle key sharing server, an example of a digital vehicle key sharing server including such an apparatus;

[0029] Figure 1b A flow chart illustrating an example of a method for a digital vehicle key sharing server;

[0030] Figure 1c A schematic diagram showing an example of a system including a digital vehicle key sharing server, a first device, and a second device as a user device;

[0031] Figure 1d A schematic diagram showing an example of a system including a digital vehicle key sharing server, a first device, a second device as a second server, and a user device;

[0032] Figure 2a A schematic diagram showing an example of an apparatus for a second server and a second server including such an apparatus;

[0033] Figure 2b A flow chart illustrating an example of a method for a second server;

[0034] Figure 3a schematic diagram showing an example of an apparatus for a first device and a first device comprising such an apparatus;

[0035] Figure 3b A flow chart illustrating an example of a method for a first device;

[0036] FIG4 illustrates a timing diagram of an example of a server-based key shared to a user device;

[0037] Figure 5 A timing diagram showing an example of registering a car sharing server at a digital vehicle key sharing server; and

[0038] Figure 6 A timing diagram showing a simplified example of server-based key sharing to a user device via a car sharing server. DETAILED DESCRIPTION

[0039] Some examples are now described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of features and equivalents and substitutes of features. In addition, the terms used to describe some examples herein should not limit further possible examples.

[0040] In the description of the entire drawings, the same or similar reference numerals represent the same or similar elements and / or features, which may be implemented in the same or modified form while providing the same or similar functions. For clarity, the thickness of the lines, layers and / or regions in the drawings may also be exaggerated.

[0041] When two elements A and B are combined using "or", this should be understood to disclose all possible combinations, i.e., only A, only B, and A and B, unless otherwise explicitly limited in individual cases. As alternative wording for the same combination, "at least one of A and B" or "A and / or B" can be used. This applies equally to combinations of more than two elements.

[0042] If singular forms such as "a", "an", and "the" are used, and the use of only a single element is not explicitly or implicitly defined as mandatory, further examples may also use multiple elements to achieve the same function. If the function is described below as being achieved using multiple elements, further examples may use a single element or a single processing entity to achieve the same function. It should also be understood that the terms "comprise", "comprising", "including", and / or "comprising" when used describe the presence of specified features, wholes, steps, operations, processes, elements, components, and / or groups thereof, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, processes, elements, components, and / or groups thereof.

[0043] FIG. 1a shows a schematic diagram of an example of a device 10 for a digital vehicle key sharing server 100 and a digital vehicle key sharing server 100 including such a device 10. The device 10 includes circuits configured to provide the functions of the device 10. For example, Figure 1aThe device 10 includes an interface circuit 12, a processing circuit 14 and (optionally) a storage circuit 16. For example, the processing circuit 14 can be coupled 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 device in combination with the interface circuit 12 (for example, exchanging information with other devices such as the first device 100, the second server 200, or the user device 250) and the storage circuit 16 (for storing information such as machine-readable instructions). Generally, the functionality of the processing circuit 14 can be implemented by the processing circuit 14 executing machine-readable instructions. Therefore, any feature attributed to the processing circuit 14 can be defined by one or more instructions of a plurality of machine-readable instructions. The device 10 may include, for example, machine-readable instructions within the storage circuit 16.

[0044] The processing circuit 14 is configured to obtain a request to share a digital vehicle key for one or more vehicles with a second device 200, 250 from the first device 300 via the interface circuit 12. The processing circuit 14 is configured to determine whether the second device specified by the request is a user device 250 or a server 200. The processing circuit is configured to process the request for sharing a digital vehicle key based on whether the second device specified by the request is a user device or a server.

[0045] Figure 1b A flow chart of an example of a corresponding method for a digital vehicle key sharing server 100 is shown. The method includes obtaining 110 a request from a first device to share a digital vehicle key for one or more vehicles with a second device. The method includes determining 120 whether the second device specified by the request is a user device or a server. The method includes processing 130 the request for sharing a digital vehicle key based on whether the second device specified by the request is a user device or a server. For example, the method may be performed by the digital vehicle key sharing server 100.

[0046] In the following, features of the apparatus 10, the digital vehicle key sharing server 100 and the corresponding methods (and computer programs) are discussed with respect to the apparatus 10. Features introduced in conjunction with the apparatus 10 may also be included in the corresponding digital vehicle key sharing server, method and computer program.

[0047] The process begins with a request to share a digital vehicle key for one or more vehicles with a second device 200, 250. The request is issued by a first device 300, which is a user device (such as a smart phone, computer, wearable device, etc.) of the owner (also denoted as the "sharer" of the vehicle). Although the current example assumes that the first device is a user device, the proposed scheme can also be used in a purely server-based architecture, where the first device is also a server requesting to share the digital vehicle key with the user device or with another server. Although in some systems the first device 300 is responsible for signing the digital vehicle key, in the proposed scheme, this task is delegated to the digital vehicle key sharing server. However, for compatibility reasons, the signing of the digital vehicle key (in addition to the digital vehicle key sharing server) can still be performed by the first device.

[0048] In the proposed solution, two cases are distinguished - in the first case, the 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 (i.e., the "second server"). In the following, the first case is also denoted as direct sharing, while the second case is denoted as indirect or delegated sharing. Figure 1c The first case is illustrated in Figure 1d The second case is illustrated in .

[0049] Figure 1c 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 as a user device 250 is shown. 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. Figure 1d A schematic diagram of an example of a system including a digital vehicle key sharing server 100, a first device 300, a second device as a second server 200, and a user device 250 is shown. In this case, the first device 300 requests the digital vehicle key sharing server to allow the second device as the second server 200 to issue a request for a shared digital vehicle key. The second server (rather than the user device) can therefore request the digital vehicle key sharing server to issue a shared digital vehicle key for the user device 250.

[0050] To distinguish between the two situations, the request indicates the “type” of the second device, i.e., whether the second device is a user device or a server. The processing circuit then processes the request to determine whether the second device specified by the request is a user device 250 or a server 200, and processes the request for sharing the digital vehicle key based on whether the second device specified by the request is a user device or a server.

[0051] like Figure 1c As further shown, in the first case, i.e., if the request indicates that the second device is a user device, the processing circuit may be configured to provide an invitation to provide a public key of a digital vehicle key for signing (e.g., a certificate including the public key of the digital vehicle key) to a digital vehicle key sharing server via the first device or directly to the second device as a user device. In particular, the invitation may include a uniform resource locator (URL) that the user device can access to have 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 scheme, the user device is provided with key parameters for generating a digital vehicle key, wherein the digital vehicle key is generated by the user device (e.g., within a secure element / secure area / trusted execution environment of the user device). For example, the digital vehicle key generated by the user device includes the aforementioned certificate, which in turn may include the public key of the digital vehicle key, together with information about the rights transmitted by the digital vehicle key. For example, the digital vehicle key may include a key pair, which includes a public key and a private key. After being generated, the public key of the digital vehicle key or a certificate with the public key may be provided by the user device to the digital vehicle key sharing server for signing. Thus, the processing circuit may be configured to obtain a request for signing the public key or certificate of the digital vehicle key from the user device via the interface circuit, sign the public key of the digital vehicle key (e.g., the certificate with the public key) using the private key of the digital vehicle key sharing server, and provide the signed public key of the digital vehicle key (e.g., the signed certificate) to the user device (via the interface circuit). For example, a request to sign the public key or certificate of the digital vehicle key may be obtained in response to an invitation to provide the public key or certificate of the digital vehicle key. The user device may provide the signed public key (e.g., as part of the certificate) to the vehicle, wherein 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, wherein the public key of the digital vehicle key sharing server is stored in the vehicle and is used to perform the verification.

[0052] In the present disclosure, the terms "signature", "signing" and "certificate" may be used synonymously. For example, if the digital vehicle key sharing server signs the public key of the digital vehicle key (or the public key of the second server), it may be generated based on the corresponding public key using its private key, a digital signature or a digital certificate. Therefore, a "signed public key" or a "signed certificate" may correspond to a digital certificate based on the corresponding public key or certificate.

[0053] In the second case, the second server is added to a list of entities that are allowed to issue requests for sharing digital vehicle keys. For example, the processing circuit can be configured to, if the second device is a server, add the public key of the second device to a storage device (e.g., within the storage circuit 16), the storage device including one or more public keys that are allowed (i.e., corresponding to allowed entities) to issue requests for sharing digital vehicle keys. For example, the public key of the second server may be included in the request for sharing digital vehicle keys obtained from the first device. The processing circuit can be configured to extract the public key of the second server from the request. In addition, the processing circuit can be configured to verify the request for sharing digital vehicle keys based on the public key of the first device contained in the storage device, the storage device including one or more public keys that are allowed to issue requests for sharing digital vehicle keys for one or more vehicles. For example, the storage device may be supported by a database, including an association between a vehicle and an entity / public key that is allowed to issue a request for sharing digital vehicle keys for the corresponding vehicle. When the first device is first paired with the vehicle, the public key of the first device can be added to the storage device (and therefore added to the database).

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

[0055] In addition to storing the public key of the second server in the storage device, the public key may be signed by the digital vehicle key sharing server (i.e., a signature or certificate may be generated based on the private key of the digital vehicle key sharing server). For example, the processing circuit may be configured to, if the second device is a server, sign the public key of the second device using the 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 authentication.

[0056] Once it is known that the second server is allowed to issue requests for shared vehicle keys, it may also provide a request for sharing a digital vehicle key (e.g., on behalf of its client, or to delegate sharing to another server). For example, the processing circuit may be configured to obtain a second request for sharing a digital vehicle key for a vehicle to a user device from a second device as a server via an interface circuit, and provide an invitation to provide a public key of a digital vehicle key for signing (e.g., including a certificate of the public key) to the digital vehicle key sharing server via the second device or directly to the user device. Again, the processing circuit may be configured to: in response to the invitation, obtain a request for signing a public key of a digital vehicle key (e.g., a certificate with a public key) from the user device via the interface circuit, sign the public key of the digital vehicle key (e.g., a certificate with a public key) using the private key of the digital vehicle key sharing server, and provide the signed public key of the digital vehicle key to the user device. Therefore, the user device itself may be the second device (the first case), or the user device may be a user device that has requested to sign the public key of the digital vehicle key via the second device (the second case).

[0057] In some cases, a request to sign a public key (or certificate) for a digital vehicle key may be verified to avoid having the public key of a digital vehicle key of a "wrong" user device being signed (e.g., because the "wrong" user device has intercepted the invitation). For example, a request to share a digital vehicle key may include authentication verification information (a public key of a user device, information derived from a user account identifier associated with the user device (e.g., a hash), and information derived from a phone number associated with the user device (e.g., a hash)). The digital vehicle key sharing server may use the authentication verification information to verify the request to sign the public key (or certificate) for the digital vehicle key. In other words, the processing circuit may be configured to verify the request from the user device to sign the public key (or certificate) for the digital vehicle key based on the authentication verification information. For example, the public key of the digital vehicle key may be derived from a private key of a key pair that includes the public key of the user device. The public key of the digital vehicle key may therefore be verified against the public key of the user device. In addition, the public key or certificate of the digital vehicle key may include more information about the user device as metadata, such as a user account identifier (or a hash thereof) and / or a phone number (or a hash thereof), which can be verified against information derived from the user account identifier associated with the user device and information derived from the phone number associated with the user device, respectively.

[0058] More details about the communication between the first device, the digital vehicle key sharing server, and the user device can be found in FIG. 4 (where in FIG. 4 , the first device is the sharer, the digital vehicle key sharing server is the vehicle OEM server, and the user device is the sharee). More details about delegated sharing can be found in Figure 6 Found in (where the second server is the car sharing provider).

[0059] The interface circuit 12 may correspond to one or more inputs and / or outputs for receiving and / or transmitting information, which may be digital (bit) values ​​according to a specified code within a module, between modules, or between modules of different entities. For example, the interface circuit 12 may include a circuit configured to receive and / or transmit information.

[0060] For example, the processing circuit 14 can be implemented using one or more processing units, one or more processing devices, any mechanism for processing, such as a processor, a computer, or a programmable hardware component that can be operated using corresponding adapted software. In other words, the functions of the processing circuit 14 described can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0061] For example, the storage circuit 16 may include at least one element of a computer-readable storage medium group, such as a magnetic or optical storage medium, for example a hard disk drive, a flash memory, a floppy disk, a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electronically erasable programmable read-only memory (EEPROM), or a network storage device. More details and aspects of the apparatus, method, and computer program for a digital vehicle key sharing server and the digital vehicle key sharing server are provided in conjunction with the proposed solution or one or more examples described above or below (for example, Figures 2a to 6 ) Mentioned. An apparatus, method and computer program for a digital vehicle key sharing server and a digital vehicle key sharing server may include one or more additional optional features corresponding to one or more aspects of the proposed solution or one or more examples described above or below.

[0062] Figure 2a A schematic diagram of an example of an apparatus 20 for a second server 200 and a second server 200 comprising such an apparatus 20 is shown. The apparatus 20 comprises circuitry configured to provide the functionality of the apparatus 20. For example, Figure 2a The device 20 includes an interface circuit 22, a processing circuit 24 and an (optional) storage circuit 26. For example, the processing circuit 24 can be coupled 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 combination with the interface circuit 22 (for example, 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). Generally, the functionality of the processing circuit 24 can be implemented by the processing circuit 24 executing machine-readable instructions. Therefore, any features attributed to the processing circuit 24 can be defined by one or more instructions of a plurality of machine-readable instructions. The device 20 may include, for example, machine-readable instructions within the storage circuit 26.

[0063] The processing circuit 24 is configured to obtain a first request for accessing the vehicle from the user device 250 via the interface circuit 22. The processing circuit 24 is configured to provide a second request for sharing a digital vehicle key for the vehicle to the digital vehicle key sharing server 100 via the interface circuit 22 based on the first request.

[0064] Figure 2b A flow chart of an example of a corresponding method for a second server is shown. The method includes obtaining 210 a first request for accessing a vehicle from a user device. The method includes providing 220 a second request for sharing a digital vehicle key for a vehicle to a digital vehicle key sharing server based on the first request. For example, the method can be performed by the second server.

[0065] In the following, features of the apparatus 20, the second server 200 and the corresponding methods (and computer programs) are discussed with respect to the apparatus 20. Features introduced in conjunction with the apparatus 20 may also be included in the corresponding second server 200, methods and computer programs.

[0066] As combined Figures 1a to 1d As outlined, after registering the second server at the digital vehicle key sharing server (by storing its public key in a storage device that is allowed to issue a public key request for sharing a digital vehicle key, such as Figure 5 ), the second server may also issue such a request on behalf of its client. For example, the second server may be a server of a car sharing provider, or a fleet management server, or a server of a parking garage, or a server of a road assistance company, etc. Once the owner / sharer of the vehicle has authorized the second server, it may now be used to issue a request for sharing a digital vehicle key via the digital vehicle key sharing server to issue such a request on behalf of its client, or to delegate the sharing to another server.

[0067] In various examples, such a request is triggered by a user device, which will be equipped with such a digital vehicle key, through which the aforementioned first request for accessing the vehicle is provided from the user device 250. Typically, such a first request may be received after the user device is registered at the second server, and information about the second device, such as its public key, is stored in a storage device of the second server, such as the storage circuit 26. For example, Figure 6 As shown, the user equipment ( Figure 6 The sharee(s) can first install the corresponding application ( Figure 6 ), create an instance CA key pair to use, and then upload the public key of the key pair to the second server ( Figure 6 The second server then stores the public key and associates it with the corresponding user device / client. When the user device then makes a first request ( Figure 6 In other words, the processing circuit may be configured to obtain the public key of the user device ( Figure 6 Action 3 in ), the second request includes the public key of the user device ( Figure 6 Action 6).

[0068] As combined Figure 1dAs discussed, in order to invite the user device to have the public key of the digital vehicle key signed / the corresponding certificate created, the digital vehicle key sharing server provides an invitation to the user device, for example directly or via a second server. In the latter case, the processing circuit may be configured to obtain an invitation (from the digital vehicle key sharing server) for providing the public key of the digital vehicle key of the user device for signing (or a certificate including the public key) to the digital vehicle key sharing server. Figure 6 Request key response (URL) in the , and the invitation ( Figure 6 From there, the creation and signing of the digital vehicle key may correspond to actions 6 to 22 of FIG. 4 (some of which are optional). For example, as a next action, the user device may issue a request to sign the public key of the digital vehicle key ( Figure 6 Signing the key request in ).

[0069] In some examples, to authenticate the relationship with the digital vehicle key sharing server, the processing circuitry may be configured to obtain a signed version (or certificate) of the second server's public key from the digital vehicle key sharing server (as a result of the second server's registration at the digital vehicle key sharing server). Figure 5 Further details may be found at The second server, and therefore the processing circuitry, may then use the signed public key / certificate to create a signing endpoint for authenticating the relationship of the second server to the digital vehicle key sharing server.

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

[0071] The interface circuit 22 may correspond to one or more inputs and / or outputs for receiving and / or transmitting information, which may be digital (bit) values ​​according to a specific code within a module, between modules, or between modules of different entities. For example, the interface circuit 22 may include a circuit configured to receive and / or transmit information.

[0072] For example, the processing circuit 24 can be implemented using one or more processing units, one or more processing devices, any mechanism for processing, such as a processor, a computer, or a programmable hardware component that can be operated using corresponding adapted software. In other words, the described functions of the processing circuit 24 can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0073] For example, the storage circuit 26 may include at least one element from the group of computer-readable storage media, such as a magnetic or optical storage medium, for example a hard drive, a flash memory, a floppy disk, a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electronically erasable programmable read-only memory (EEPROM), or a network storage device.

[0074] More details and aspects of the apparatus, method and computer program for the second server and the second server are provided in conjunction with the proposed solution or one or more examples described above or below (e.g., Figures 1a to 1d , 3a to 6). The apparatus, method and computer program for the second server and the second server may include one or more additional optional features corresponding to one or more aspects of the proposed solution or one or more examples described above or below.

[0075] Figure 3a A schematic diagram of an example of an apparatus 30 for a first device 300 and a first device 300 comprising such an apparatus 30 is shown. The apparatus 30 comprises circuitry configured to provide the functionality of the apparatus 30. For example, Figure 3a The device 30 includes an interface circuit 32, a processing circuit 34 and an (optional) storage circuit 36. For example, the processing circuit 34 can be coupled 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 device in combination with the interface circuit 32 (for example, 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). Generally, the functionality of the processing circuit 34 can be implemented by the processing circuit 34 executing machine-readable instructions. Therefore, any features attributed to the processing circuit 34 can be defined by one or more instructions of a plurality of machine-readable instructions. The device 30 may include, for example, machine-readable instructions within the storage circuit 36.

[0076] The processing circuit 36 ​​is configured to generate a request for sharing a digital vehicle key for one or more vehicles with a second device 200 , 250 , the request indicating whether the second device specified by the request is a user device or a second server. The processing circuit is configured to provide the request to the digital vehicle key sharing server 100 .

[0077] Figure 3b A flow chart of an example of a corresponding method for a first device is shown. The method includes generating 310 a request for sharing a digital vehicle key for one or more vehicles with a second device, the request indicating whether the second device specified 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.

[0078] In the following, features of the apparatus 30, the first device 300 and the corresponding methods (and computer programs) are discussed with respect to the apparatus 30. Features introduced in conjunction with the apparatus 30 may also be included in the corresponding first device 300, methods and computer programs.

[0079] In the proposed scheme, the first device 300 is the initiator of the sharing program, initiating directly to the user device or delegating the sharing authority to the second server. 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 sharer / owner of the vehicle paired with the vehicle. In order to distinguish between the above two situations, the processing circuit is configured to generate a corresponding request so that the request indicates whether the second device specified by the request is a user device or a second server. As shown in conjunction with Figure 4, a "Device Profile" tag can be included in the request, where the tag has two possible values ​​"device" and "server". The request may further include information attachments, such as information about one or more vehicles being shared and information about the second device (including the public key of the second device, the purpose of which is to verify the second device and / or generate a signed version / certificate of the public key for authentication purposes). More information about the possible fields of the request is discussed in conjunction with Figure 4, and in particular action 1 of Figure 4.

[0080] In the case where the second device is a user device (or in some cases even if the second device is a server), at least some portion of the communication between the digital vehicle key sharing server and the second device may be performed via the first device. In particular, as shown in FIG4 , the processing circuit may be configured to obtain an invitation from the digital vehicle key sharing server to provide the digital vehicle key sharing server with a public key (or a certificate including such a public key) of a digital vehicle key of a user device (or second server) for signing, and forward the invitation to the second device / user device (e.g., actions 4 and 5 of FIG4 ). For example, the invitation may be shared using a messaging protocol or via an application of a vehicle original equipment manufacturer (OEM).

[0081] The interface circuit 32 may correspond to one or more inputs and / or outputs for receiving and / or transmitting information, which may be digital (bit) values ​​according to a specified code within a module, between modules, or between modules of different entities. For example, the interface circuit 32 may include a circuit configured to receive and / or transmit information.

[0082] For example, the processing circuit 34 can be implemented using one or more processing units, one or more processing devices, any mechanism for processing, such as a processor, a computer, or a programmable hardware component that can be operated using corresponding adapted software. In other words, the described functions of the processing circuit 34 can also be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0083] For example, the storage circuit 36 ​​may include at least one element of a computer-readable storage medium group, such as a magnetic or optical storage medium, for example a hard drive, a flash memory, a floppy disk, a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electronically erasable programmable read-only memory (EEPROM), or a network storage device.

[0084] More details and aspects of the apparatus, method and computer program for the first device and the first device are provided in conjunction with the proposed solution or one or more examples described above or below (e.g., Figures 1a to 2b , 4 to 6). The apparatus, method and computer program for the first device and the first device may include one or more additional optional features corresponding to one or more aspects of the proposed solution or one or more examples described above or below.

[0085] Various examples of the present disclosure relate to a server-based key sharing scheme for digital keys. In the proposed scheme, a paired owner (i.e., a sharer) may not be required for key sharing. Instead, or in addition to a paired owner, key sharing may be implemented by a server instance (i.e., a digital vehicle key sharing server, hereinafter referred to as a vehicle OEM server). The vehicle OEM server may allow key sharing between devices, between servers and devices, and authorization of the server to share keys for single or multiple vehicle identifiers (e.g., for purposes such as fleet management servers, garages, road assistance, etc.).

[0086] The public key on the shared key used to verify the vehicle OEM server's signature may be known to the vehicle (eg, stored in a secure element of the vehicle).

[0087] The requesting instance (further referred to as the sharer), which can 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 giving information about the key attributes and the recipient of the key (further referred to as the sharee, i.e., the second device). For example, the sharee can be a user device (phone, watch, etc.) or a server. The sharer can be known to the key management server through its endpoint public key.

[0088] In the case where the sharee is a server, a digital key may not be created (at this time). Instead, the sharee instance CA public key (i.e., the public key of the second server) may be whitelisted (i.e., added to a storage device including one or more public keys that are allowed to issue requests for shared digital vehicle keys) in the vehicle OEM server for being allowed to request a shared key for the requested vehicle identifier.

[0089] In the proposed scheme, the vehicle OEM server can create a key creation request that is sent to the sharee. The sharee can create a digital key and send a key signing request. After receiving the key signing request from the sharee, the vehicle OEM server can sign it with its endpoint private key. Since the endpoint public key of the vehicle OEM server is known in the vehicle, the vehicle can then verify the legitimacy of the shared key and allow access to the vehicle.

[0090] Hereinafter, an example implementation of sharing a digital vehicle key via a digital vehicle key sharing server (hereinafter denoted as “vehicle OEM server”, where OEM is an original equipment manufacturer, such as an automobile manufacturer) is given.

[0091] In this example, the vehicle OEM server allows keys to be shared between devices, between servers and devices, and authorizes the server to share keys for single or multiple vehicle identifiers (e.g., fleet management servers, garages, road assistance, etc.), i.e., for one or more vehicles. In order to authorize the server (i.e., the second server) as a potential sharer, the server's public key is transmitted to the vehicle OEM server. The vehicle OEM server may maintain a database of vehicle identifiers (indicating corresponding vehicles) for which authorized public keys are allowed to request keys. The establishment and maintenance of the database is not within the scope of the present disclosure.

[0092] Increased security during key sharing can be achieved by authentication of 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 account ID of the intended recipient of the sharee with the actual recipient of the digital key, or use a hash of the sharee's phone number or public key for this purpose.

[0093] Key sharing via the vehicle OEM server is described in detail in the following sequence diagram. FIG4 shows a sequence diagram of an example of server-based key sharing to a user device. In sequence diagram FIG4, five entities are shown: 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 (which is an optional communication intermediary between the vehicle OEM server and the sharee), a sharee (i.e., a user device), and an optional KTS (key tracking server).

[0094] In the following, actions 1 to 22 shown in Fig. 4 are described in more detail. As will become apparent, at least some of these actions are optional.

[0095] In action 1 (request to share, i.e., provide a request for sharing a digital vehicle key), the sharer sends the information required for key creation to the vehicle OEM server. If the instance CA public key (i.e., the public key of the sharee) is known to the sharer (e.g., a pre-established trust relationship or a trusted server lookup), the sharer can add the "sharee instance CA public key" (i.e., the public key of the sharee) to the request. The sharer can optionally request the use of the second factor for activating the shared key by setting the "activation required" flag. If the sharing destination is a server instance (i.e., if the request indicates that the 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 within the sharing. The request can be signed by the sharer, for example, based on an arbitrary data certificate with a sharer key (i.e., the sharer's private key) using arbitrary data, such as a SHA-256 hash value of the request. For example, the request may include one or more of the following fields: a field including one or more vehicle identifiers of one or more vehicles to be shared, a key configuration information field, a server key field, an activation required field, a device pin field, a maximum number of device pin attempts field, a sharee one-time account identifier hash field, a field including a present value for the sharee one-time account identifier hash creation, a sharee phone number hash field, a field including a present value for the sharee phone number hash creation, and a "sharee instance CA public key" field (i.e., the sharee's public key). The latter entry may be used for sharee authentication.

[0096] A request including one or more of the above fields may be signed with the sharer's private key, and the signature may be transmitted with the request.

[0097] In actions 2 to 4 (Create Key Creation Request), if the sharer sends the "Sharee Instance CA Public Key", the vehicle OEM server may store the key for future requests to share the key according to the "Vehicle Identifier". If the "Device Profile" is set to "Server" (i.e., if the second device is a server), in some examples, the vehicle OEM server may only send a "Request Key Response ()" message (without actions 2 and 3), and the process may be terminated. Alternatively, the entire process may be completed, including providing a representation of the digital key to the sharee as a server.

[0098] At least if the "Device Profile" is set to "Device" (i.e., user device), and in some examples also if the "Device Profile" is set to "Server", the vehicle OEM server may create a key creation request (including the "Device Profile" and the maximum number of times sharing is allowed). If a relay server is used as an intermediary between the vehicle OEM server and the sharee, a secret may be generated that is used to encrypt the payload for the "Create Mailbox API", as described in Internet Engineering Task Force (IETF): Secure Credential Transfer-Draft-Secure Credential Transfer-03. The vehicle OEM server may send a "Create Mailbox" request to the relay server. After receiving the mailbox link, the vehicle OEM server may send a response "Request Key Response" to the sharee device.

[0099] In actions 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 CA public key" (i.e., the sharee's public key), and upload it to the mailbox of the relay server.

[0100] In actions 9 to 13 (key signing), after downloading the key signing request from the relay server, the vehicle OEM server may optionally compare the "sharee one-time account identifier hash" or "sharee instance CA public key" contained in the signing request with the "sharee one-time account identifier hash" or "sharee instance CA public key" received from the sharer in the "Request Key" request. If the two keys match, the vehicle OEM server may sign the key (i.e., the public key of the digital vehicle key) and create an "import request". The vehicle OEM server may upload the "import request" to the mailbox of the relay server.

[0101] In actions 14 to 17 (Importing key data), the sharee can download an "Import Request" and request to delete the mailbox of the relay server (if the relay server is being used for communication).

[0102] In actions 18 to 20 (optional key tracing), if key tracing is required, the sharee may request a signed certificate from the key tracing server. Optionally, the key tracing server may notify the vehicle OEM server about the successful key tracing.

[0103] In action 21 (Notify Sharer), the vehicle OEM server may notify the sharer about the successful key sharing after uploading the "Import Request" to the relay server or after optional key tracking.

[0104] In some examples, secure sharee authentication may be performed. For example, authentication may be performed via a device OEM account identifier hash. To increase security during key sharing, the vehicle OEM server may optionally compare the identity information of the intended recipient of the sharee with the actual recipient of the digital key. For example, the identity information may be one of: an account identifier hash, a phone number hash, and a public key of the sharee.

[0105] For example, the sharer may request a one-time hash of the intended sharee's account ID hash at an account database server (in the following example, this would be the device OEM server, both the sharer and the sharee belong to the same device OEM). The account database server may select a present value that can be added to the account ID hash to anonymize the ID. The present value may be shared with 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 may then recalculate the one-time account ID hash and compare it to the one-time account ID hash received from the sharer with the "Request Key" request.

[0106] In the following, an example implementation of delegated key sharing (i.e., key sharing via a second server) is presented. Such delegated sharing can allow consumer-to-business use cases (allowing a third-party service provider to share keys for private vehicles) and business-to-consumer use cases (a third-party service provider shares keys to customers or employees for private cars or cars in a commercial fleet). In order to allow third-party service providers (e.g., car sharing, garages, or roadside assistance, etc.) to issue keys for certain vehicles to their subscribers / customers, the provider's server's public key (i.e., the second server's public key) can be registered with the vehicle OEM server (i.e., the digital vehicle key sharing server). After registration, the service provider can hold an instance CA certificate through its public key signed by the vehicle OEM server (i.e., the signature of the signed public key of the second server). The instance CA certificate can be used by the service provider to create an endpoint certificate, which can be used to sign an online sharing request (i.e., the second request for sharing a digital vehicle key) when sending a "request key" message to the vehicle OEM server.

[0107] Once registered, the holder of a digital key with corresponding sharing rights may choose to allow the service provider to request keys for the vehicle associated with the holder's digital key. This may be done by selecting the service provider from a list provided by the vehicle OEM in an application or web interface. The process of registering a public key is outside the scope of this disclosure, but an example is given in the following section for completeness.

[0108] Registering a third-party service provider server (ie, second server) and thereby obtaining an instance CA certificate for the service provider server is accomplished by creating a key pair and sending a certificate signing request (CSR) to the vehicle OEM server. This is shown in the following sequence as an example of registering a car sharing provider. Figure 5 A sequence diagram showing an example of registering a car sharing server at a digital vehicle key sharing server. Figure 5 As shown, the car sharing provider's server can create a key pair (including a secret / private key (sk) and a public key (pk) at action (1), and register the public key at the vehicle OEM server at action (2). The vehicle OEM can generate a certificate based on the public key (i.e., "sign" the public key) at action (3), which can be used as an instance CA for the car sharing provider's server, and provide the certificate to the car sharing provider's server. At (4), the car sharing provider's server can create an endpoint signed by the instance CA. The third-party service provider can create an endpoint signed by the instance CA, which will be used to sign the "Request Key" request.

[0109] In the present disclosure, an endpoint is the end of a certificate chain. The goal of a certificate chain is to allow a secure element (SE) of a sharer or key management server to verify that the endpoint of the sharee is authorized to participate in the sharing protocol. This verification is required to ensure that the sharee key pair has actually been generated on an approved SE, and to ensure that any secret data transmitted from the sharer's confidential mailbox to the sharee's confidential mailbox is properly handled. Each sharer endpoint may contain one or more authorized public keys (authorized PKs) set by the vehicle during the owner / sharer pairing process. The authorized PK list contains at least the public key of the vehicle OEM CA. An external CA is typically a device OEM CA for issuing an instance CA certificate for a digital key applet. The instance CA then issues an endpoint certificate. The verification of the sharee's endpoint is handled by the following verification chain. Each element to the right of the arrow is proved by the element before it: authorized CA (vehicle OEM CA) -> external CA (device OEM CA), -> instance CA, -> endpoint -> endpoint encryption key.

[0110] The sharer can authorize the third-party service provider's server to issue keys for its vehicle by sharing the key with the server. When sending a "Request to 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 second server's public key).

[0111] Once the sharee server is registered at the vehicle OEM server, the trusted sharee server can issue keys to the sharee. An authorized third-party service provider can request keys for its customers / employees by sending its public key as sharing information (i.e., as part of the second request for sharing the digital vehicle key) to the vehicle OEM server. This allows the vehicle OEM server to verify the recipient of the key before signing the shared key.

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

[0113] In actions 1 to 3, the service provider obtains the public key of the sharee. For example, a third-party service provider's application installed on the device of the recipient of the shared key can request an instance CA from the local OS and send it to the service provider's server when creating a subscription or installing the third-party provider application.

[0114] In actions 4 to 7 (forward mailbox uniform resource locator, URL), the service provider server creates a "request key" request and signs it with the endpoint secret key (which is signed by the pre-registered instance CA). This request (i.e., the second request for sharing the digital vehicle key) can hold the public key of the sharee device, 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 application on the sharee device.

[0115] In actions 8 to 11 (creation and signing of shared key), a key is created on the sharee device and a key signing request is sent to the vehicle OEM server. The vehicle OEM server can verify the legitimacy of the created key by comparing the public key of the instance CA in the key signing request from the sharee with the public key received with the "Request Key" request from the sharer. If the two keys match, the vehicle OEM server can sign the key and send an import request to the sharee device.

[0116] In the following, some examples are given for the entities mentioned above.

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

[0118] The (user) device may contain a secure processing and storage environment (secure element, secure enclave, trusted execution environment, or equivalent) that runs the digital key applet. It may assume the roles of a sharer device and a sharee device. The sharer device may implement features such as digital key sharing and store necessary certificates. The sharer may be any entity that has a trust relationship (PKI-based) with the vehicle OEM server, including the sharer device and the sharee server. The sharee device may implement features such as digital key sharing (as a receiver) and store necessary certificates.

[0119] The third-party service provider server (ie, the second server) can be pre-registered with the vehicle OEM server and authorized by the sharer key (or by the administrator). It can initiate digital key sharing to other participants.

[0120] The relay server can provide a standardized communication channel to support key sharing between two devices from different (or the same) OEMs. It can implement push notifications and support a polling mechanism to keep devices informed during the key sharing process.

[0121] The digital key system is based on signature verification using asymmetric cryptography. The vehicle unlocks the doors or starts the engine only if the query has been signed with the private key corresponding to the public key registered in the vehicle.

[0122] After the sharer device and the vehicle have been paired, the sharer has a private key for which the corresponding public key is stored in the vehicle. For sharing keys via a vehicle OEM server, the vehicle OEM server public key can be registered in the vehicle during the production process or when configuring the vehicle software for digital key use.

[0123] To allow the shared key to access the vehicle, the sharer or vehicle OEM server may use its private key to sign the sharee's public key. When the sharer or vehicle OEM server's signature is presented on the sharee's public key, the vehicle may then accept the shared key as a new vehicle user and store the sharee's public key. To initiate the vehicle OEM server to sign the sharee's public key using its private key, the device may authorize the OEM server.

[0124] Digital key sharing can include a stateful exchange of an invitation URL sent by the sharer to the sharee, as well as key creation, key signature, and data import requests. When a secure sharing channel is used, such as a proprietary messaging channel controlled by the device OEM, then the invitation and stateful sharing messages can all be sent over the channel.

[0125] Typically, a digital key may include various elements, which may include one or more of a vehicle identifier (for uniquely identifying a vehicle), an endpoint identifier (for device internal key management), and a digital key identifier, an instance CA identifier (of the instance that has signed the digital key).

[0126] Before signing the sharee's public key, the sharer can verify that the sharee's public key pair has been created on a qualified SE. The verification chain starts with an authorized public key in the sharer's digital key structure that has been provisioned and trusted by the vehicle, for example, the vehicle OEM CA public key. The shared digital key may further include a certification package that includes the sharee's public key (signed by the sharer / vehicle OEM server) and information about the validity of the shared digital key.

[0127] The proposed solution can be used by vehicle manufacturers, (smart) device manufacturers, car sharing providers, third-party service providers (roadside assistance, valet parking, etc.) and other parties involved in digital car keys.

[0128] Aspects and features described with respect to a particular example in the previous examples may also be combined with one or more of the further examples to replace the same or similar features of the further examples or to additionally introduce these features into the further examples.

[0129] Each example may further be or relate to a (computer) program including a program code, which is used to perform one or more of the above methods when the program is executed on a computer, a processor or other programmable hardware component. Therefore, the steps, operations or processes of the different methods in the above methods may also be performed by a programmed computer, a processor or other programmable hardware component. Each example may also cover a program storage device, such as a digital data storage medium, which is machine-readable, processor-readable or computer-readable and encodes and / or contains machine-executable, processor-executable or computer-executable programs and instructions. For example, a program storage device may include or be a digital storage device, a magnetic storage medium such as a disk and a tape, a hard drive or an optically readable digital data storage medium. Other examples may also include a computer, a processor, a control unit, a (field) programmable logic array ((F) PLA), a (field) programmable gate array ((F) PGA), a graphics processor unit (GPU), an application-specific integrated circuit (ASIC), an integrated circuit (IC) or a system on a chip (SoC) system programmed to perform the steps of the above methods.

[0130] It is further understood that the disclosure of multiple steps, processes, operations or functions disclosed in the specification or claims should not be interpreted as implying that these operations necessarily rely on the order described, unless explicitly stated in individual cases or necessary for technical reasons. Therefore, the foregoing description does not limit the execution of multiple steps or functions to a certain order. In addition, in further examples, a single step, function, process or operation may include and / or be decomposed into multiple sub-steps, sub-functions, sub-processes or sub-operations.

[0131] If some aspects of a device or system have been described, these aspects should also be understood as descriptions of the corresponding methods. For example, blocks, devices or functional aspects of a device or system may correspond to features of the corresponding methods, such as method steps. Therefore, aspects of a method description should also be understood as descriptions of corresponding blocks, corresponding elements, properties or functional features of the corresponding device or corresponding system.

[0132] The attached claims are hereby incorporated into the detailed description, wherein each claim may be independently presented as a separate example. It should also be noted that, although in the claims a dependent claim refers to a specific combination with one or more other claims, other examples may also include a combination of a dependent claim with the subject matter of any other dependent or independent claim. Such a combination is hereby explicitly proposed, unless it is stated in individual cases that a specific combination is not intended. In addition, the features of a claim should also be included for any other independent claim, even if the claim is not directly defined as being dependent on the other independent claim.

Claims

1. A device (10) for a digital vehicle key sharing server (100), the device comprising an interface circuit (12) and a processing circuit (14), the processing circuit being configured to: obtaining, via the interface circuit, from a first device (300) a request to share a digital vehicle key for one or more vehicles with a second device (200; 250); determining whether the second device specified by the request is a user device (250) or a server (200); as well as The request to share the digital vehicle key is processed based on whether the second device specified by the request is a user device or a server.

2. The device according to claim 1, wherein: The processing circuit is configured to verify the request for sharing a digital vehicle key based on a public key of the first device contained in a storage device, the storage device including one or more public keys permitted to issue requests for sharing digital vehicle keys for the one or more vehicles.

3. The device according to claim 2, wherein: The processing circuit is configured to, if the second device is a server, add a public key of the second device to the storage device, the storage device including one or more public keys permitted to issue a request for sharing a digital vehicle key.

4. The device according to claim 3, wherein: The processing circuit is configured to, if the second device is a server, sign the public key of the second device using the 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 authentication.

5. The device according to any one of claims 1 to 4, wherein: The processing circuit is configured to obtain, via the interface circuit, from the second device acting as a server, a second request for sharing a digital vehicle key for a vehicle with a user device, and to provide, via the second device or directly to the user device, an invitation for providing a public key of the digital vehicle key for signing to the digital vehicle key sharing server.

6. The device according to any one of claims 1 to 5, wherein: The processing circuit is configured to provide, to the second device via the first device or directly, an invitation to provide a public key of the digital vehicle key for signing to the digital vehicle key sharing server.

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

8. The device according to claim 7, wherein: A request to sign the public key of the digital vehicle key is obtained in response to the invitation to provide the public key of the digital vehicle key.

9. The device according to claim 7 or 8, wherein: The request to share the digital vehicle key includes authentication verification information, wherein the processing circuit is configured to verify the request to sign the public key of the digital vehicle key based on the authentication verification information.

10. A device (20) for a second server (200), the device comprising an interface circuit (22) and a processing circuit (24), the processing circuit being configured to: obtaining, via the interface circuit, from a user device (250) a first request for access to a vehicle; A second request for sharing a digital vehicle key for the vehicle is provided to a digital vehicle key sharing server (100) based on the first request.

11. An apparatus for a first device (300), the apparatus comprising an interface circuit (32) and a processing circuit (34), the processing circuit being configured to: generating a request for sharing a digital vehicle key for one or more vehicles to a second device (200; 250), the request indicating whether the second device specified by the request is a user device or a server; The request is provided to a digital vehicle key sharing server (100).

12. A method for a digital vehicle key sharing server (100), the method comprising: obtaining (110) from a first device a request to share a digital vehicle key for one or more vehicles with a second device; determining (120) whether the second device specified by the request is a user device or a server; as well as The request to share the digital vehicle key is processed ( 130 ) based on whether the second device specified by the request is a user device or a server.

13. A method for a second server (200), the method comprising: Obtaining (210) a first request from a user device for access to a vehicle; A second request for sharing a digital vehicle key for the vehicle is provided (220) to a digital vehicle key sharing server based on the first request.

14. A method for a first device (300), the method comprising: generating (310) a request for sharing a digital vehicle key for one or more vehicles to a second device, the request indicating whether the second device specified by the request is a user device or a server; The request is provided (320) to a digital vehicle key sharing server.

15. A computer program having a program code for carrying out the method according to claim 12, the method according to claim 13 or the method according to claim 14 when the computer program is executed on a computer, a processor or a programmable hardware component.

Images