Digital key cloud services platform for generating vehicle public key certificates

Abstract

A digital key cloud services platform (100) for generating a vehicle public key certificate (172) for a vehicle (104) is provided. In some examples, the digital key cloud services platform includes a vehicle integration service (122) configured to facilitate communications with a vehicle OEM via a vehicle OEM services platform (108) and a key management service (114) configured to generate the vehicle public key certificate for the vehicle in response to receipt of a vehicle public key certificate CSR message from the vehicle OEM services platform.

Description

DIGITAL KEY CLOUD SERVICES PLATFORM FOR GENERATING VEHICLE PUBLIC KEY CERTIFICATESCross Reference

[0001] This application claims the benefits of U.S. Provisional Patent Application No. 63 / 778,012, filed on March 26, 2025, U.S. Provisional Patent Application No. 63 / 778,021, filed on March 26, 2025, U.S. Provisional Patent Application No. 63 / 778,031, filed on March 26, 2025, and U.S. Non-provisional Patent Application No. 19 / 550,464, filed on February 26, 2026. The entire disclosures of the above applications are incorporated herein by reference.

[0002] The present disclosure relates to provisioning devices with a public key certificate, and particularly to a digital key cloud services platform configured for provisioning a vehicle with a vehicle public key certificate.

[0003] Digital keys are increasingly being used to authenticate access to or operation of a vehicle. Digital keys may be stored in the memory of a mobile device (e.g., smartphone, smartwatch, or similar smart wearable devices) and provide convenient access to a vehicle. Typically, a vehicle owner may also assign a temporary digital key to another. This process becomes more complex when the assignee has a mobile device from a device manufacturer that is different from the vehicle owner.

[0004] This section provides a general summary of the disclosure and is not a comprehensive disclosure of its full scope or all of its features.

[0005] One example of the present disclosure provides a digital key cloud services platform for generating a vehicle public key certificate for a vehicle. In some examples, the digital key cloud services platform includes a vehicle integration service configured to facilitate communications with a vehicle original equipment manufacturer (OEM) of the vehicle via a vehicle OEM services platform and a key management service configured to process a vehicle public key certificate certificate signing request (CSR) message received by the vehicle integration service from the vehicle OEM services platform, wherein the key management service is configured to generate the vehicle public key certificate for the vehicle in response to receipt of the vehicle public key certificate CSR message.

[0006] In some examples, the key management service is configured to determine tenant information for the vehicle in response to the vehicle public key certificate CSR message.

[0007] In some examples, the key management service is configured to determine a certificate authority (CA) type for the vehicle based on the tenant information.

[0008] In some examples, the key management service is configured to request a vehicle CA of the vehicle OEM services platform to provide the vehicle public key certificate to the vehicle integration service in response to the CA type corresponding with a vehicle integration designation.

[0009] In some examples, the vehicle integration service is configured to communicate a vehicle CA retrieved certificate message to the vehicle CA to request the vehicle CA to provide the vehicle public key certificate.

[0010] In some examples, the vehicle integration service is configured to receive a vehicle CA certificate message including the vehicle public key certificate from the vehicle CA in response to the vehicle CA retrieved certificate message.

[0011] In some examples, the key management service is configured to generate and transmit to the vehicle OEM services platform a vehicle public key certificate message having the vehicle public key certificate included in the vehicle CA certificate message in response to the vehicle CA certificate message.

[0012] In some examples, a cloud CA service of the key management service is configured to generate the vehicle public key certificate in response to the CA type corresponding with an internal designation.

[0013] In some examples, the cloud CA service is configured to generate and cryptographically sign an X.509 certificate as part of the vehicle public key certificate.

[0014] In some examples, the key management service is configured to generate and transmit to the vehicle OEM services platform a vehicle public key certificate message having the vehicle public key certificate generated with the cloud CA service.

[0015] In some examples, the key management service is configured to determine the CA type based on a vehicle identifier (vehicleId) for the vehicle included as part of the vehicle public key certificate CSR message.

[0016] In some examples, the vehicle public key certificate is a certificate [K] defined within the Car Connectivity Consortium (CCC, registered trademark) Version 1.1.0 specification.

[0017] In some examples, a server-based owner device (SBOD) service, a CCC application programming interface (API) broker service, a key tracking service, and an administrative support service are provided.

[0018] One example of the present disclosure provides a method for generating a vehicle public key certificate for a vehicle. In some examples, the method includes receiving a vehicle public key certificate CSR message from a vehicle OEM services platform of a vehicle OEM of the vehicle at a vehicle integration service of a digital key cloud services platform, determining tenant information for the vehicle with a key management service of the digital key cloud services platform in response to receipt of the vehicle public key certificate CSR message at the vehicle integration service, and generating the vehicle public key certificate for the vehicle at the key management service based on the tenant information.

[0019] In some examples, the method includes determining a CA type for the vehicle with the key management service based on the tenant information.

[0020] In some examples, the method includes requesting a vehicle CA of the vehicle OEM services platform to provide the vehicle public key certificate to the vehicle integration service in response to the CA type corresponding with a vehicle integration designation.

[0021] In some examples, the method includes requesting a cloud CA service of the key management service to generate the vehicle public key certificate in response to the CA type corresponding with an internal designation.

[0022] In some examples, the method includes generating the vehicle public key certificate with a cloud CA service of the key management service in response to the CA type corresponding with an internal designation and with a vehicle CA of the vehicle OEM services platform in response to the CA type corresponding with a vehicle integration designation.

[0023] In some examples, the method includes the key management service being configured to determine the CA type based on a vehicle identifier (vehicleId) for the vehicle included as part of the vehicle public key certificate CSR message.

[0024] In some examples, the method includes the vehicle public key certificate being a certificate [K] defined within the Car Connectivity Consortium (CCC, registered trademark) Version 1.1.0 specification.

[0025] Further areas of applicability will become apparent from the description provided herein. The description and specific examples in this summary are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

[0026] The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations and are not intended to limit the scope of the present disclosure.

[0027] Fig. 1 is a functional diagram illustrating a single tenant arrangement and a multi-tenant arrangement in accordance with an example of the present disclosure.Fig. 2 is a functional diagram illustrating a digital key cloud services platform providing digital key sharing in accordance with an example of the present disclosure.Fig. 3 is a functional diagram illustrating a method for provisioning a vehicle with a vehicle public key certificate in accordance with an example of the present disclosure.

[0028] Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.

[0029] Example embodiments will now be described more fully with reference to the accompanying drawings. The example embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.

[0030] In some examples, the present disclosure provides a digital key service for vehicles. The digital key service may implement and expand on the requirements of the Car Connectivity Consortium (CCC, registered trademark) Version 1.1.0 specification (the CCC specification), the disclosure of which is hereby incorporated by reference in its entirety herein, and future versions of the specification.

[0031] The present disclosure may be implemented in a single tenant or multi-tenant hosting environment. In either case, the digital key service optionally operates as a single instance, as shown in FIG. 1. The tenants of the digital key service may be vehicle OEMs. The digital key service may include an application programming interface (API) allowing tenants to communicate with the digital key service.

[0032] The digital key service may allow each tenant to configure the following information: identifying information such as tenant name and CCC ID, CCC-related certificates, whether certificate signing is handled by the tenant or is delegated to the digital key service, connections to and configurations for mobile device OEMs (e.g., Apple, Google, etc.), and connection to and configuration for a vehicle integration service (VIS).

[0033] The digital key service may include support for suspending and resuming digital keys. For example, the digital key service may allow a user (e.g., a vehicle owner or vehicle user) or tenant to suspend a digital key and to resume a digital key that has been suspended. Upon receiving an instruction from the user or tenant to suspend a digital key or to resume a digital key that has been suspended, the digital key service may send a notification to the user or tenant that the vehicle feature has been suspended or the suspended vehicle feature has been resumed. In the example above, the digital key service may send a notification to the tenant that a digital key has been suspended or a suspended digital key has been resumed.

[0034] The tenant may choose whether to support the suspend / resume feature via a customization field that can be set during vehicle creation. Alternatively, the tenant may update the choice of whether to support the suspend / resume feature via a vehicle information update application programming interface (API).

[0035] In executing instructions to resume or suspend a digital key, the digital key service may consider the network connection status of a vehicle (i.e., offline / online). The digital key service may include an offline vehicle notification function in its API to allow tenants to notify the digital key service that a vehicle message could not be delivered, indicating the vehicle may be offline. The offline vehicle notification function may include an option for the tenant to resume attestations once the offline vehicle resumes communication with the digital key service.

[0036] With reference to the figures, FIG. 1 illustrates the digital key service (i.e., Clavis) operating in an example single tenant arrangement and in an example multi-tenant arrangement.

[0037] In the single tenant arrangement, Tenant 1 and Tenant 2 are single tenants. Each tenant interfaces with an instance of the digital key service that is different from the instance of any other tenant. Each application (i.e., App), virtual machine (i.e., VM), and database (i.e., DB1, DB2) is limited to providing services to a single tenant.

[0038] In the multi-tenant arrangement, Tenant 1 and Tenant 2 are tenants that share a single instance of the digital key service. Each application (i.e., App) and virtual machine (i.e., VM) provide services to the single instance of the digital key service and the shared tenants, collectively. However, as in the single tenant arrangement, each database (i.e., DB1, DB2) is limited to providing services to a single tenant. While the multi-tenant arrangement allows for tenants to share a single instance of the digital key service, the digital key service compartmentalizes or silos each tenant and generally prevents communication between tenants. Access to tenant data may be verified on each request by various access control methods, such as JWT verification, certificate-chain verification, and ensuring the caller is part of the requested tenant.

[0039] The digital key service may further implement subdomains to handle vehicle OEM requests. Each tenant may have a specific and separate subdomain that device OEMs can send requests to when performing requests for a specific vehicle OEM.

[0040] Thus, though in a multi-tenant arrangement, the tenant may have the same experience and the same information security as in a single tenant arrangement.

[0041] Referring to FIG. 2, a digital key cloud services platform 100 for providing digital key services is presented in accordance with an example of the present disclosure. In the illustrated instance, the digital key cloud services platform 100 is configured to facilitate digital key sharing between a device 102 and a vehicle 104, optionally based in part on messaging and other communications between a device OEM services platform 106 of a device OEM of the device 102 and a vehicle OEM services platform 108 of a vehicle OEM of the vehicle 104.

[0042] FIG. 2 illustrates a singular instantiation of each of the device 102 and the vehicle 104 for non-limiting purposes. In particular, the present disclosure contemplates the digital key cloud services platform 100 concurrently supporting multiple instantiations of the device 102 and / or the vehicle 104, i.e., supporting interactions with multiple devices and / or multiple vehicles simultaneously.

[0043] In some circumstances, the device 102 corresponds with a friend device, i.e., a device entitled to access to the vehicle 104 as a friend via entitlements provided from an owner, and in other circumstances, the device 102 corresponds with an owner device, i.e., a device entitled to access to the vehicle 104 as an owner via entitlements provided from the vehicle OEM.

[0044] In the event multiple friends and / or owner devices and / or multiple vehicles are simultaneously supported for different OEMs, additional instantiations of the device OEM services platform 106 and / or the vehicle OEM services platform 108 are provided for each OEM.

[0045] In some examples, the digital key cloud services platform 100 includes a server-based owner device (SBOD) service 112, a key management service 114, a key tracking service 116, a CCC application programming interface (API) broker service 118, an administrative support service 120, a vehicle integration service 122, a cloud certificate authority (CA) service 124, and a tenant context (TC) service 128.

[0046] In this regard, the digital key cloud services platform 100 comprises a variety of hardware and software components operable to support a number of processes, protocols, communications, etc. accordingly, the digital key cloud services platform 100 is a comprehensive infrastructure that enables applications, devices, and systems to communicate, share data, and consume functionality across distributed environments. The OEM services platform 108 is similarly configured.

[0047] To this end, the digital key cloud services platform 100 and the OEM services platform 108 support various interfaces and protocols to facilitate the operations described herein and particularly include functionality operable to comply with the requirements of the CCC specification. The platforms, for example, include various APIs, services, service architectures, delivery mechanisms, etc., which are referenced without limitation to represent attendant functions, activities, and actions performed by the digital key cloud services platform 100 and the OEM services platform 108 in furtherance of the digital key services described herein.

[0048] The SBOD service 112 may implement the creation of digital keys. The SBOD service 112 may include the following sub-components. Config: handles configuration of the web service Controller: defines the web APIs and accepts incoming requests to the APIs DAO: data persistence classes DTO: data transfer classes Gateway: handles outgoing requests to the Internet or other web services Repository: handles persisting data Service: contains core business logic of the APIs Util: utility classes useful to other sub-components

[0049] The key management service 114 may implement digital key tracking services and lifecycle management services for the tenant (e.g., vehicle OEM). The key management service 114 may be responsible for digital key termination, digital key suspend / resume, and vehicle unpairing. The key management service 114 may operate in cooperation with the key tracking service 116 to facilitate digital key tracking services and lifecycle management services. The key management service 114 may include the following sub-components. Config: handles configuration of the web service Controller: defines the web APIs and accepts incoming requests to the APIs DAO: data persistence classes DTO: data transfer classes Gateway: handles outgoing requests to the Internet or other web services Repository: handles persisting data Security: implements securing of access to the APIs Service: contains core business logic of the APIs Util: utility classes useful to other sub-components

[0050] The key tracking service 116 implements the tracking of digital keys and provides receipts. In some examples, the key tracking service 116 maintains a digital key database that is configured to associate digital key records with each of the digital keys issued in conjunction with the digital key cloud services platform 100, i.e., to maintain digital key records for digital owner keys and digital friend keys.

[0051] The digital key tracking provided by the key tracking service 116 may provide a ledger of digital key transactions, allowing the digital key cloud services platform 100 to maintain a history of all changes to a digital key. In one example, the key management service 114 may create a record of a digital key transaction originating from a vehicle or phone and then send a request to the key tracking service 116 to create a ledger or entry of the digital key transaction. Upon creating the ledger for the digital key transaction, the key tracking service 116 may further create a receipt of the digital key transaction. The receipt may be returned to the vehicle 104 or device 102, e.g., a mobile or smart phone, by the key tracking service 116 or the key management service 114 as proof that the vehicle 104 or the device 102 successfully completed the key tracking process. The key tracking service 116 may include the following sub-components. Config: handles configuration of the web service Controller: defines the web APIs and accepts incoming requests to the APIs DAO: data persistence classes DTO: data transfer classes Gateway: handles outgoing requests to the Internet or other web services Repository: handles persisting data Service: contains core business logic of the APIs Util: utility classes useful to other sub-components

[0052] A tenant context web service allows the administration service 110 to retrieve the system configurations set up by the tenant. The tenant context web service may include the following sub-components. Config: handles configuration of the web service Controller: defines the web APIs and accepts incoming requests to the APIs DAO: data persistence classes DTO: data transfer classes Gateway: handles outgoing requests to the Internet or other web services Repository: handles persisting data Security: implements securing of access to the APIs Service: contains core business logic of the APIs

[0053] The vehicle integration service 122 routes and translates messages to and from the administration service 110 and the vehicle OEM (i.e., tenant). In other words, the digital key cloud services platform 100 may communicate with the vehicle OEM through the vehicle integration service 122. The vehicle integration service 122 may include the following sub-components. Config: handles configuration of the web service Controller: defines the web APIs and accepts incoming requests to the APIs DAO: data persistence classes DTO: data transfer classes Gateway: handles outgoing requests to the Internet or other web services Repository: handles persisting data Service: contains core business logic of the APIs Util: utility classes useful to other sub-components

[0054] The administrative support service 120 allows tenants to configure and customize their digital key service via an administrative web service API. The administrative support service 120 may include the following sub-components. Config: handles configuration of the web service Controller: defines the web APIs and accepts incoming requests to the APIs DAO: data persistence classes DTO: data transfer classes Gateway: handles outgoing requests to the Internet or other web services Repository: handles persisting data Security: implements securing of access to the APIs Service: contains core business logic of the APIs

[0055] The administrative support service 120 allows a tenant to call the administration web service API via a graphical user interface.

[0056] The digital key cloud services platform 100 may further include a SBOD service proxy service in communication with the SBOD service 112 and a CCC API broker service 118 in communication with the key management service 114.

[0057] The SBOD service proxy service may route incoming calls from a fleet management company service 126 to the SBOD service 112.

[0058] The CCC API broker service 118 may establish a TLS or MTLS connection with the device OEM services platform 106 and route incoming calls to the key management service 114.

[0059] The vehicle OEM services platform 108 may include a vehicle CA service 130, a digital key (DK) service integration service 132 (i.e., DK integration), a vehicle OEM core service 134, and a telematics link service 136. The digital key cloud services platform 100 may be in communication with the vehicle OEM services platform 108 via one or more APIs.

[0060] The vehicle OEM services platform 108 may act as the certificate authority for this CCC product. The digital key cloud services platform 100 may use APIs and methods provided by the vehicle OEM services platform 108 to obtain any necessary certificates and public keys required to perform digital key service functions.

[0061] The vehicle OEM services platform 108 may securely share, generate, provide, provision, etc. a variety of the certificates set forth in the CCC specification.

[0062] In some examples, the vehicle OEM services platform 108 is configured to support a version of certificate [J] (i.e., vehicle OEM CA certificate) and any relevant vehicle OEM CA certificates, such as certificate [F] (i.e., device OEM CA certificate), with the digital key cloud services platform 100. The digital key cloud services platform 100 may use certificates [J] and [F] to verify other certificates in the certificate chain (e.g., certificate [E]), and may use certificate [J]'s private key to sign certificate [K].

[0063] The device 102 includes a variety of services, APIs, applications, etc. to facilitate supporting digital key sharing via the digital key cloud services platform 100 and the vehicle 104. In some examples, the device 102 includes a fleet application 144 to facilitate communications with the fleet management company service 126, a native application 146 (e.g., an operating system), a vehicle application 148 to facilitate communications with the vehicle OEM core service 134, and a DK framework service 150 configured to facilitate digital key sharing via a digital key sharing relay 152, the vehicle 104, and / or other devices and / or vehicles.

[0064] Likewise, the vehicle 104 includes a variety of services, APIs, applications, etc. to facilitate supporting digital key sharing via the digital key cloud services platform 100 and the device 102. In some examples, the vehicle 104 includes one or more anchors 160 (e.g., UWB, BLE, NFC) to facilitate wireless communications with the device 102, a DK electronic control unit (DK ECU) 162 to support digital keys and related processes, and a telematics control unit (TCU) 164 to facilitate communications with the telematics link service 136.

[0065] At several points during the lifetime of a digital key, communication between the vehicle 104 and the digital key cloud services platform 100 is necessary. This includes during key tracking, key suspension and resumption, key termination, and vehicle unpairing. Communication between the digital key cloud services platform 100 and the vehicle 104 may be routed through the vehicle OEM services platform 108.

[0066] The digital key cloud services platform 100 will support at least the incoming and outgoing message types described in Table 1 and Table 2. Table 1: Vehicle to digital key service message types Table 2: digital key service to vehicle message types

[0067] The digital key cloud services platform 100 will use and understand at least the JSON message structure when communicating with vehicles. The digital key cloud services platform 100 will use at least HTTPS as the transport method for vehicle messages.

[0068] The digital key cloud services platform 100 may support the provisioning of a new vehicle during its production phase. Provisioning a vehicle informs the digital key cloud services platform 100 that the vehicle exists and provides the vehicle public key certificate [K] (i.e., vehicle public key certificate) so that the digital key cloud services platform 100 can identify the origin of the vehicle’s public key.

[0069] The vehicle OEM may request certificate [K] creation and owner pairing verifier creation from the digital key cloud services platform 100 during vehicle provisioning.

[0070] The digital key cloud services platform 100 may understand and implement the following API commands and message structure when receiving vehicle management communication from the vehicle OEM: CreateCertificateKRequest(csrHexString *string*) CreateCertificateKResponse(vehicleId *string*, certificateHexString *string*) GenerateOwnerPairingVerifier(password *string*, sendMessage *Boolean*) OwnerPairingVerifier(salt *string*, lx *string*, ly *string*, w0 *string*, nScrypt *integer*, r *integer*, p *integer*, dkLen *integer*) CertificateK(certificate *string*) VehicleInfoResponse(id *string*, vehicleId *string*, tenantId *string*, uiIdentifier *string*, certificateK *string*, brand *string*, model *string*, maxSharedKeys *integer*, updated *string*) LimitedVehicleInfo(uiIdentifier *string*, brand *string*, model *string*, maxSharedKeys *integer*, immobilizerAndSlotIdTag *string*, suspendResumeSupported *boolean*) UpdateLimitedVehicleInfo(uiIdentifier *string*, brand *string*, model *string*, maxSharedKeys *integer*, suspendResumeSupported *boolean*)

[0071] The digital key cloud services platform 100 may support vehicle-initiated provisioning and factory-initiated provisioning.

[0072] In vehicle-initiated provisioning, a key pair is generated on the vehicle and a vehicle public key certificate certificate signing request (CSR) is sent to the digital key cloud services platform 100. The digital key cloud services platform 100 may sign the CSR, create a vehicle public key certificate [K], and return the vehicle public key certificate [K] back to the vehicle 104.

[0073] Initiating vehicle public key certificate [K] signing from the vehicle 104 adds additional security since the secure key never leaves the vehicle. Re-provisioning is possible since the vehicle knows how to regenerate the key pair. Further, vehicle-initiated provisioning may be performed on new vehicles in lieu of factory-initiated provisioning.

[0074] In factory-initiated provisioning, a key pair and vehicle public key certificate [K] are generated outside of the vehicle 104 and are later flashed to the vehicle 104 by the factory or dealer. Once on the vehicle 104, a factory / dealer can initiate vehicle public key certificate [K] signing with the already-generated certificate.

[0075] In some examples, the private key is generated on the vehicle and effectively never leaves the vehicle under most circumstances. In a factory provisioning, a triggering event for generating the private key, for example, includes a diagnostic message from the factory or dealership. In a field provision, in contrast, the triggering event for generating a private key, for example, includes an in-vehicle command, e.g., HMI command, from the dealership or an end-user.

[0076] The digital key cloud services platform 100 may initiate key termination and unpairing when, for example, a tenant or user terminates a key via the vehicle OEM website.

[0077] The digital key cloud services platform 100 may implement the following APIs when sending or receiving key management communication to or from the vehicle OEM: KeyTerminationRequest(keyId *string*, keyType *string*) requestUnpairing(tenantId *string*, vehicleId *string*) requestTermination(tenantId *string*, vehicleId *string*)

[0078] The digital key cloud services platform 100, upon an owner’s initial pairing of their device with a vehicle, may track a new digital key. The owner’s mobile device may be notified once their digital key has been tracked.

[0079] Following successful pairing by the owner, the digital key cloud services platform 100 may allow the sharing of digital keys. Specifically, the key tracking service 116 may create and track new digital keys for each time a key is shared.

[0080] The digital key cloud services platform 100 may further allow owner key unpairing, which will terminate all keys associated with the vehicle in the key tracking service 116. Neither the owner nor any shared keys may access the vehicle.

[0081] The digital key cloud services platform 100 may allow reprovisioning of a vehicle once an owner key is unpaired or if it is otherwise manually triggered. During the reprovisioning, as in owner key unpairing, all keys associated with the vehicle are terminated. Neither the owner nor any shared keys may access the vehicle. The digital key cloud services platform 100 may then proceed to provision the vehicle in a manner discussed above.

[0082] During the owner key unpairing or provisioning process, the digital key cloud services platform 100 may remove all shared keys associated with the vehicle. Shared keys (or friend keys) are digital keys that may be associated with mobile devices belonging to someone other than the owner. In one example, the shared key may be managed by the device OEM of the friend’s mobile device. In this example, the digital key cloud services platform 100 may delete a shared key from the friend’s mobile device by sending a request to the device OEM services platform 106.

[0083] In another example, the shared key may be managed by the vehicle OEM services platform 108. In this example, the digital key cloud services platform 100 may delete a shared key from the friend’s mobile device by sending a request to the vehicle OEM services platform 108.

[0084] The digital key cloud services platform 100 may further allow the suspension and resumption of shared digital keys by the owner or vehicle OEM. This may be done in lieu of deletion of the shared key. Once suspended, a shared digital key may not access the vehicle until the shared key is resumed by the owner or vehicle OEM.

[0085] The digital key cloud services platform 100 may send notification messages to the vehicle OEM services platform 108 at various points during the lifecycle of a digital key. The digital key cloud services platform 100 may communicate with the vehicle OEM services platform 108 through the vehicle integration service. This may include when a key is created, suspended, resumed, or terminated.

[0086] The digital key cloud services platform 100 may implement the following APIs when sending notification messages to or from the vehicle OEM services platform 108: CreateNotificationRequest(scmId *string*, vehicleId *string*, keyId *string*, eventType *string*, eventData *string*) Notification(eventData *string*, eventType *string*, id(notificationId *string*, timestamp *string*), keyId *string*, notificationId *string*, scmId *string*, timestamp *string*, vehicleId *string*) The digital key cloud services platform 100 may retrieve vehicle information from the vehicle OEM services platform 108 at various points during the lifecycle of a digital key. The digital key cloud services platform 100 may implement the following APIs when sending vehicle information requests to the vehicle OEM services platform 108: GetVehicleScmIdResponse(scmId *string*) GetFullVehicleInfo(brand *string*, certificate *string*, maxSharedKeys *integer*, model *string*, uiIdentifier *string*)

[0087] The digital key cloud services platform 100 is predominantly described with respect to enabling digital key sharing in accordance with the CCC specification for non-limiting purposes as the present disclosure is similarly applicable and beneficial in enabling digital key sharing according to other specifications. In order to support digital key sharing according to the CCC specification, however, the vehicle 104 is to be provisioned with a vehicle public key certificate 172, or more specifically, the certificate [K] described therein. In some examples, the vehicle public key certificate 172 is used to support authentications performed between the device 102 and the vehicle 104 as part of the CCC specification.

[0088] Notably, the CCC specification fails to specify a particular methodology or process for generating the vehicle public key certificate 172. To fill this gap, the digital key cloud services platform 100 is configured for generating the vehicle public key certificate 172. In some examples, the digital key cloud services platform 100 is an independent, third-party platform provided to assist vehicle OEMs in provisioning the vehicle 104, and optionally, to alleviate a need for the vehicle OEMs to maintain compliance with the CCC specification.

[0089] To this end, the APIs, services, modules, and other features of the digital key cloud services platform 100 include capabilities for working with existing infrastructures of vehicle OEMs via the vehicle OEM services platform 108 maintained by the vehicle OEMs. In some examples, the digital key cloud services platform 100 provisions the vehicle 104 with the vehicle public key certificate 172 in a manner that is effectively transparent to the vehicle OEMs, or at the least in a manner that minimizes the need for the vehicle OEMs to continuously support the CCC specification and updates thereto.

[0090] Referring to FIG. 3, a method for generating the vehicle public key certificate 172 is shown. At 200, the method includes a preconditioning event representing a need to provision the vehicle 104 with the vehicle public key certificate 172. Such an event, for example, may arise as a result of the vehicle 104 being newly manufactured, i.e., the vehicle 104 is a new vehicle that has not been previously provisioned with a vehicle public key certificate, or as a result of the vehicle 104 being sold, i.e., the vehicle 104 has been previously provisioned with a vehicle public key certificate.

[0091] In some examples, the preconditioning event includes the DK ECU 162 of the vehicle 104 being provided with a key pair, e.g., a private key and a public key. The key pair, for example, may be provided to the DK ECU 162 via proprietary or back-office processing capabilities of the vehicle OEM or through another suitable mechanism. In some instances, the key pair may be generated as part of a Public Key Infrastructure (PKI) to enable public key cryptography.

[0092] At 202, the method includes the vehicle 104 communicating a vehicle public key certificate CSR message including a CSR for the vehicle public key certificate 172 to the vehicle OEM services platform 108. The vehicle public key certificate CSR message, for example, may be communicated from the TCU 166 of the vehicle 104 for receipt at the telematics link service 136 of the vehicle OEM services platform 108, optionally using messaging that complies with the CCC specification or through other suitable messaging protocols. By way of example and without limitation, the vehicle public key certificate CSR message when received at the vehicle OEM services platform 108 may include various attributes, including the public key provided at 200 signed by the private key provided at 200.

[0093] At 204, the method includes the vehicle OEM services platform 108 delivering the vehicle public key certificate CSR message to the digital key cloud services platform 100. The vehicle public key certificate CSR message, for example, may be communicated from the DK integration service 132 of the vehicle OEM services platform 108 and received at the vehicle integration service 122 of the digital key cloud services platform 100. In some instances, the DK integration service 132 is an API supported by the operator of the digital key cloud services platform 100. The vehicle integration service 122, for example, may be operable to support the DK integration service 132 on behalf of the vehicle OEM.

[0094] At 206, the method includes the digital key cloud services platform 100 determining tenant information for the vehicle 104 in response to the vehicle public key certificate CSR message. The key management service 114, for example, determines the tenant information based on data included within the vehicle public key certificate CSR message. Based on the data included within the vehicle public key certificate CSR message, the key management service 114 utilizes the tenant information to generate the vehicle public key certificate 172 for the vehicle 104.

[0095] At 208, the method includes the key management service 114 utilizing the tenant information to identify a CA type for the vehicle 104, i.e., an entity available to generate the vehicle public key certificate 172 for the vehicle 104. As noted above, the digital key cloud services platform 100 is operable with various CAs, particularly CAs configured to generate the vehicle public key certificate 172 in accordance with the CCC specification. Accordingly, in some circumstances, the vehicle CA service 130 of the vehicle OEM services platform 108 is responsible for generating the vehicle public key certificate 172, and in other circumstances, such as when the vehicle OEM desires to outsource CA oversight, the cloud CA service 124 of the digital key cloud services platform 100 is tasked with generating the vehicle public key certificate 172.

[0096] Advantageously, the capability of the digital key cloud services platform 100 to support differing CAs in this manner allows the present disclosure to support vehicle OEMs that have existing infrastructure in compliance with the CCC specification as well as to support vehicle OEMs that lack such an infrastructure and / or those that may desire to migrate CA responsibility at some future time to the digital key cloud services platform 100.

[0097] In some examples, the key management service 114 determines the CA responsible for generating the vehicle public key certificate 172 based on the CA type, e.g., the vehicle CA service 130 is determined to be responsible in the event the CA type corresponds with a vehicle integration designation and the cloud CA service 124 is determined to be responsible in the event the CA type corresponds with an internal designation. In some examples, the CA type is derived from a vehicle identifier (vehicleId) of the vehicle 104 included in the vehicle public key certificate CSR message as part of the tenant information.

[0098] In some instances, the vehicleId is added at 202 by the vehicle 104 when sending the vehicle public key certificate CSR message or at 204 when the vehicle OEM services platform 108 delivers the vehicle public key certificate CSR message to the vehicle integration service 122. The key management service 114, for example, determines the CA type according to CA information provided from the TC service 128. In some examples, the TC service 128 is tasked with correlating CA requirements for a variety of vehicles according to corresponding vehicleIds, e.g., the TC service 128 includes a database that cross-references vehicleIds to the CA responsible for generating the vehicle public key certificate 172.

[0099] At 212, the method includes the digital key cloud services platform 100 communicating a vehicle CA retrieved certificate message to the vehicle OEM services platform 108 in response to the CA type at 204 indicating the vehicle integration designation. The vehicle integration service 122, for example, communicates the vehicle CA retrieved certificate message to the DK integration service 132 of the vehicle OEM services platform 108 in response to corresponding instructions from the key management service 114.

[0100] While the digital key cloud services platform 100 is operable to procure other types of certificates, the method includes generating the certificate [K] in accordance with the CCC specification. In the case of the CA type indicating the vehicle integration designation, the certificate [K] is signed by the vehicle CA service 130. In some circumstances, to assist the vehicle CA service 130 in generating the vehicle public key certificate 172, the vehicle CA retrieved certificate message optionally includes some or all of the various attributes included or added to the vehicle public key certificate CSR message at 202 and / or 204, including the public key signed by the private key of the vehicle 104.

[0101] At 214, the method includes the vehicle CA service 130 generating the vehicle public key certificate 172 in response to the vehicle CA retrieved certificate message. In some examples, the vehicle CA service 130 verifies the vehicle public key certificate CSR and generates the vehicle public key certificate 172, i.e., the certificate [K], according to the CCC specification, which includes the vehicle's public key, identity information, and other relevant details. The vehicle CA service 130 then signs the certificate [K] with its private key, creating a unique digital signature that confirms the vehicle's identity and public key.

[0102] At 216, the method includes the vehicle OEM services platform 108 communicating a vehicle CA certificate message including the vehicle public key certificate 172 to the digital key cloud services platform 100. The DK integration service 132 of the vehicle OEM services platform 108, for example, communicates the vehicle CA certificate message to the vehicle integration service 122 of the digital key cloud services platform 100.

[0103] At 220, the method includes the cloud CA service 124 generating the vehicle public key certificate 172 in response to the vehicle CA retrieved certificate message. In some examples, the cloud CA service 124 verifies the vehicle public key certificate CSR and generates the vehicle public key certificate 172, i.e., the certificate [K], according to the CCC specification, which includes the vehicle's public key, identity information, and other relevant details. The cloud CA service 124 then signs the certificate [K] with its private key, creating a unique digital signature that confirms the vehicle's identity and public key. In some examples, the cloud CA service 124 is configured to generate and cryptographically sign the vehicle public key certificate 172, which may be an X.509 certificate.

[0104] At 222, the method includes the digital key cloud services platform 100 enqueuing the vehicle public key certificate 172 in preparation for communication to the vehicle 104. The vehicle public key certificate 172, for example, may be enqueued relative to messaging protocols or other operating requirements of the vehicle OEM services platform 108 and / or the vehicle 104. The vehicle OEM services platform 108, in some instances, may be tasked with supporting digital key management for a significant quantity of vehicles such that it may be advantageous from an efficiency standpoint to enqueue the vehicle public key certificate 172 with the vehicle integration service 122 in preparation for subsequent communication to the vehicle OEM services platform 108.

[0105] At 224, the method includes the digital key cloud services platform 100 creating a vehicle public key certificate message. The vehicle public key certificate message, for example, includes the vehicle public key certificate 172 and optionally the vehicleId for the vehicle 104. In some examples, the vehicleId is included to apprise the telematics link service 136 of the vehicle OEM services platform 108 of the vehicle 104 intended by the key management service 114 to receive the vehicle public key certificate message, which may be of assistance to the telematics link service 136 in coordinating subsequent delivery of the vehicle public key certificate message.

[0106] At 226, the method includes the digital key cloud services platform 100 forwarding the vehicle public key certificate message to the vehicle OEM services platform 108. The vehicle public key certificate message, for example, is forwarded with the vehicle integration service 122 to the DK integration service 132 of the vehicle OEM services platform 108. Optionally, the forwarding of the vehicle public key certificate message may be timed or otherwise coordinated according to parameters associated with the enqueuing of 222, i.e., the actual transmission of the vehicle public key certificate message may be scheduled so the rate of transmission for this and other messaging for the vehicle OEM services platform 108 and / or the vehicle 104 is manageable.

[0107] At 230, the method includes the vehicle OEM services platform 108, i.e., the telematics link service 136, delivering the vehicle public key certificate message including the vehicle public key certificate 172 to the vehicle 104. The vehicle 104 can then utilize the vehicle public key certificate 172 to facilitate handshake operations with the device 102 or to otherwise confirm its identity and establish trust between parties for a variety of interactions governed according to the PKI.

[0108] At 232, the method includes the digital key cloud services platform 100 receiving a vehicle OEM certificate response message from the vehicle OEM services platform 108 confirming the vehicle 104 has received the vehicle public key certificate message. The vehicle OEM certificate response message, for example, may be transmitted from the DK integration service 132 of the vehicle OEM services platform 108 to the vehicle integration service 122 of the digital key cloud services platform 100.

[0109] The foregoing description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure can be implemented in a variety of forms. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent upon a study of the drawings, the specification, and the following claims. It should be understood that one or more steps within a method may be executed in a different order (or concurrently) without altering the principles of the present disclosure. Further, although each of the embodiments is described above as having certain features, any one or more of those features described with respect to any embodiment of the disclosure can be implemented in and / or combined with features of any of the other embodiments, even if that combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with one another remain within the scope of this disclosure.

[0110] Spatial and functional relationships between elements (for example, between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including “connected,” “engaged,” “coupled,” “adjacent,” “next to,” “on top of,” “above,” “below,” and “disposed.” Unless explicitly described as being “direct,” when a relationship between first and second elements is described in the above disclosure, that relationship can be a direct relationship where no other intervening elements are present between the first and second elements, but can also be an indirect relationship where one or more intervening elements are present (either spatially or functionally) between the first and second elements. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR, and should not be construed to mean “at least one of A, at least one of B, and at least one of C.” In the figures, the direction of an arrow, as indicated by the arrowhead, generally demonstrates the flow of information (such as data or instructions) that is of interest to the illustration. For example, when element A and element B exchange a variety of information but information transmitted from element A to element B is relevant to the illustration, the arrow may point from element A to element B. This unidirectional arrow does not imply that no other information is transmitted from element B to element A. Further, for information sent from element A to element B, element B may send requests for, or receipt acknowledgements of, the information to element A.

[0111] In this application, including the definitions below, the term “module” or the term “controller” may be replaced with the term “circuit.” The term “module” may refer to, be part of, or include: an Application Specific Integrated Circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code; a memory circuit (shared, dedicated, or group) that stores code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip.

[0112] The module may include one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces that are connected to a local area network (LAN), the Internet, a wide area network (WAN), or combinations thereof. The functionality of any given module of the present disclosure may be distributed among multiple modules that are connected via interface circuits. For example, multiple modules may allow load balancing. In a further example, a server (also known as a remote or cloud) module may accomplish some functionality on behalf of a client module.

[0113] The term code, as used above, may include software, firmware, and / or microcode, and may refer to programs, routines, functions, classes, data structures, and / or objects. The term shared processor circuit encompasses a single processor circuit that executes some or all code from multiple modules. The term group processor circuit encompasses a processor circuit that, in combination with additional processor circuits, executes some or all code from one or more modules. References to multiple processor circuits encompass multiple processor circuits on discrete dies, multiple processor circuits on a single die, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above. The term shared memory circuit encompasses a single memory circuit that stores some or all code from multiple modules. The term group memory circuit encompasses a memory circuit that, in combination with additional memories, stores some or all code from one or more modules.

[0114] The term memory circuit is a subset of the term computer-readable medium. The term computer-readable medium, as used herein, does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); the term computer-readable medium may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible computer-readable medium are nonvolatile memory circuits (such as a flash memory circuit, an erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (such as a static random access memory circuit or a dynamic random access memory circuit), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).

[0115] The apparatuses and methods described in this application may be partially or fully implemented by a special purpose computer created by configuring a general purpose computer to execute one or more particular functions embodied in computer programs. The functional blocks, flowchart components, and other elements described above serve as software specifications, which can be translated into the computer programs by the routine work of a skilled technician or programmer.

[0116] The computer programs include processor-executable instructions that are stored on at least one non-transitory, tangible computer-readable medium. The computer programs may also include or rely on stored data. The computer programs may encompass a basic input / output system (BIOS) that interacts with hardware of the special purpose computer, device drivers that interact with particular devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0117] The computer programs may include: (i) descriptive text to be parsed, such as HTML (hypertext markup language), XML (extensible markup language), or JSON (JavaScript Object Notation) (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. As examples only, source code may be written using syntax from languages including C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java (registered trademark), Fortran, Perl, Pascal, Curl, OCaml, Javascript (registered trademark), HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash (registered trademark), Visual Basic (registered trademark), Lua, MATLAB, SIMULINK, and Python (registered trademark).

Claims

1. A digital key cloud services platform for generating a vehicle public key certificate (172) for a vehicle (104), comprising: a vehicle integration service (122) configured to facilitate communications with a vehicle original equipment manufacturer (OEM) of the vehicle via a vehicle OEM services platform (108); and a key management service (114) configured to process a vehicle public key certificate certificate signing request (CSR) message received by the vehicle integration service from the vehicle OEM services platform, wherein the key management service is configured to generate the vehicle public key certificate for the vehicle in response to receipt of the vehicle public key certificate CSR message.

2. The digital key cloud services platform according to claim 1, wherein the key management service is configured to determine tenant information for the vehicle in response to the vehicle public key certificate CSR message.

3. The digital key cloud services platform according to claim 1 or 2, wherein the key management service is configured to determine a certificate authority (CA) type for the vehicle based on the tenant information.

4. The digital key cloud services platform according to claim 3, wherein the key management service is configured to request a vehicle CA of the vehicle OEM services platform to provide the vehicle public key certificate to the vehicle integration service in response to the CA type corresponding with a vehicle integration designation.

5. The digital key cloud services platform according to claim 4, wherein the vehicle integration service is configured to communicate a vehicle CA retrieved certificate message to the vehicle CA to request the vehicle CA to provide the vehicle public key certificate.

6. The digital key cloud services platform according to claim 5, wherein the vehicle integration service is configured to receive a vehicle CA certificate message including the vehicle public key certificate from the vehicle CA in response to the vehicle CA retrieved certificate message.

7. The digital key cloud services platform according to claim 6, wherein the key management service is configured to generate and transmit to the vehicle OEM services platform a vehicle public key certificate message having the vehicle public key certificate included in the vehicle CA certificate message in response to the vehicle CA certificate message.

8. The digital key cloud services platform according to any one of claims 3 to 7, wherein a cloud certificate authority (CA) service of the key management service is configured to generate the vehicle public key certificate in response to the CA type corresponding with an internal designation.

9. The digital key cloud services platform according to claim 8, wherein the cloud CA service is configured to generate and cryptographically sign an X.509 certificate as part of the vehicle public key certificate.

10. The digital key cloud services platform according to claim 9, wherein the key management service is configured to generate and transmit to the vehicle OEM services platform a vehicle public key certificate message having the vehicle public key certificate generated with the cloud CA service.

11. The digital key cloud services platform according to any one of claims 3 to 10, wherein the key management service is configured to determine the CA type based on a vehicle identifier for the vehicle included as part of the vehicle public key certificate CSR message.

12. The digital key cloud services platform according to claim 11, wherein the vehicle public key certificate is a certificate [K] defined within a Car Connectivity Consortium (CCC) Version 1.1.0 specification.

13. The digital key cloud services platform according to claim 12, further comprising a server-based owner device (SBOD) service, a CCC application programming interface (API) broker service, a key tracking service, and an administrative support service.

14. A method for generating a vehicle public key certificate for a vehicle, comprising: receiving a vehicle public key certificate certificate signing request (CSR) message from a vehicle original equipment manufacturer (OEM) services platform of a vehicle OEM of the vehicle at a vehicle integration service of a digital key cloud services platform; determining tenant information for the vehicle with a key management service of the digital key cloud services platform in response to receipt of the vehicle public key certificate CSR message at the vehicle integration service; and generating the vehicle public key certificate for the vehicle at the key management service based on the tenant information.

15. The method according to claim 14, further comprising determining a certificate authority (CA) type for the vehicle with the key management service based on the tenant information.

16. The method according to claim 15, further comprising requesting a vehicle CA of the vehicle OEM services platform to provide the vehicle public key certificate to the vehicle integration service in response to the CA type corresponding with a vehicle integration designation.

17. The method according to claim 15, further comprising requesting a cloud certificate authority (CA) service of the key management service to generate the vehicle public key certificate in response to the CA type corresponding with an internal designation.

18. The method according to claim 15, further comprising generating the vehicle public key certificate with a cloud certificate authority (CA) service of the key management service in response to the CA type corresponding with an internal designation and with a vehicle CA of the vehicle OEM services platform in response to the CA type corresponding with a vehicle integration designation.

19. The method according to any one of claims 15 to 18, wherein the key management service is configured to determine the CA type based on a vehicle identifier for the vehicle included as part of the vehicle public key certificate CSR message.

20. The method according to claim 19, wherein the vehicle public key certificate is a certificate [K] defined within a Car Connectivity Consortium Version 1.1.0 specification.

Images