Application Programming Interface for Certificate Management Systems

Abstract

The system may include a certificate application programming interface (API) device operable to receive an enrollment request at at least one computerized device via an application programming interface (API). The certificate API device may also generate an enrollment package and an end-entity certificate package at the at least one computerized device by obtaining an enrollment package and an end-entity certificate package from a certificate management service (CMS) via the API. The certificate API device may also transmit the enrollment package and the end-entity certificate package to the at least one computerized device via the API. The system may also include a CMS operable to provide the enrollment package and the end-entity certificate package to the certificate API device.

Description

[Technical Field]

[0001] The present disclosure relates generally to systems, devices, and methods for securely generating and providing certain types of digital assets, such as security credentials and digital certificates. More particularly, the present disclosure relates to improved systems, devices, and methods for providing application programming interfaces that enable secure provisioning of digital assets on computerized devices and reduce or eliminate delays in provisioning of digital assets on computerized devices. [Background technology]

[0002] As computers become smaller and more commoditized, manufacturers are producing a wider variety of devices that contain any number of embedded computers and processors. The computers within a computerized device can, among other things, control the operation of the device, collect, store, and share data, communicate with other computers and other computerized devices, and update its own software.

[0003] The Internet of Things (IoT) is a network of computerized physical devices with embedded processors, electronics, software, data, sensors, actuators, and / or network connectivity that allows these devices to connect and exchange data over digital networks, including the Internet, cellular networks, and other wireless networks. Generally, each “thing” is uniquely identifiable through its embedded computing system and can interoperate within the existing Internet infrastructure. “Things” in the IoT sense can refer to a wide variety of computerized devices, including consumer electronics, enterprise devices used in business and corporate environments, manufacturing machinery, agricultural equipment, energy-consuming devices in homes and buildings (such as switches, power outlets, appliances, lighting systems, light bulbs, televisions, garage door openers, sprinkler systems, and security systems), medical and healthcare devices, infrastructure management devices, robots, drones, and transportation devices and vehicles, among others.

[0004] In many instances, modern vehicles and transportation machinery (e.g., automobiles, trucks, airplanes, trains, ships, motorcycles, scooters, etc.) include several embedded processors or embedded computers in their subsystems and are computer-controlled in at least some aspects. Similarly, an increasing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, etc.) include at least one, and often many, embedded processors or embedded computer systems and are computer-controlled in at least some aspects. These computer-controlled elements of transportation networks typically communicate with one another, exchange various types of information, and react, respond, modify their operation, or rely on and use information received / transmitted from / to other vehicles in vehicle-to-vehicle (V2V; also known as vehicle-to-car (C2C)) communication and / or from / to infrastructure elements in vehicle-to-infrastructure (V2I; also known as vehicle-to-infrastructure (C2I)) communication for safe, accurate, efficient, and reliable operation. Together, V2V and V2I systems are commonly referred to as V2X systems or infrastructure. Specifically, when the entities involved in the communication are electric vehicles and charging stations, the system is called an electric vehicle-to-grid (EV2G) system or infrastructure.

[0005] The computers in computerized devices operate according to their software and / or firmware and data. To ensure secure and proper operation, computerized devices must be properly initialized and updated with the appropriate software, firmware, executable instructions, digital certificates (e.g., public key certificates), encryption keys, registration packages, pseudonymous packages, etc. (collectively referred to below as "digital assets" or "software") intended by the manufacturer, so that the IoT consists of devices running authorized, known-good software and data. However, problems arise when unauthorized individuals or organizations (e.g., hackers) replace or modify the software in a computerized device.

[0006] The on-board equipment (OBE) registration certificate is equivalent to a passport in the OBE in that it is used to request other certificates, namely pseudonym and identity certificates. The certification process provides authorization for the OBE to interface with the Secure Certificate Management Service (SCMS) and request a registration certificate during the bootstrapping process. The pseudonym certificate is short-lived and is primarily used for basic safety message authentication and fraud reporting. For privacy reasons, a device is given multiple certificates that are valid simultaneously, allowing these certificates to be changed frequently. The identity certificate is primarily used by the OBE for authorization in V2I applications. An OBE has only one valid identity certificate at a time for a given application. The roadside unit (RSU) registration certificate is equivalent to a passport in the RSU in that it uses the registration certificate to request an application certificate. The certification process provides authorization for the RSU to interface with the SCMS and request a registration certificate during the bootstrapping process. The application certificate is used by the RSU to sign any transmitted wireless messages, such as signal phase and timing or traveler information messages. Because the RSU does not have privacy constraints, only one application certificate is valid at a time for a given application. Collectively, certificates authorized by a registration certificate, including but not limited to pseudonymous, identity, and application certificates, are classified as end-entity certificates. An end-entity certificate is a digital asset that authorizes participation in a particular ecosystem, e.g., V2X, C2C, or EV2G. Throughout this document, when describing any type of end-entity certificate or a group of end-entity certificates, they are referred to as an end-entity certificate, an end-entity certificate package, or an end-entity certificate bundle.

[0007] In conventional systems, computerized devices retrieve digital assets from an external server during the manufacturing process. Typically, conventional systems retrieve digital assets from the external server for each computerized device as it is provisioned. Any network connectivity issues can increase the time required to provision a computerized device at a manufacturing facility. Additionally, conventional systems use synchronous provisioning techniques that can further increase the time required to provision a computerized device.

[0008] The present technology includes improved systems, devices, and methods for providing an application programming interface that addresses the problems and shortcomings of conventional systems. Summary of the Invention

[0009] By way of background, Representational State Transfer (REST) ​​is an architectural style for designing network applications with stateless transactions in a client-server configuration. RESTful applications use HTTP requests to post (create and / or update) data, read (e.g., make queries), and delete data. The Certificate Management Service (CMS) is used for registration and provisioning of On-Board Units (OBUs) and Roadside Units (RSUs) in USDOT vehicles for any (V2X) infrastructure. IEEE 1609.2 is a standard that defines secure message formats and processing for use by Wireless Access in Vehicular Environments (WAVE) devices, including methods for securing WAVE management messages and application messages. IEEE 609.2 also describes the management functions necessary to support core security features. X.509 is an internationally accepted standard for public key infrastructure systems used to manage digital certificates, public key cryptography, and secure communications with the Transport Layer Security (TLS) protocol. The system of the present teachings can support, for example, but not limited to, V2X, C2X (Euro standard), and EV2G. The system creates a registration request, and a REST API performs the registration and initial provisioning on behalf of the device, including polling the CMS to see if certificates are ready. Group readiness (e.g., vehicle OBU) status on client / end entity (EE) devices can be determined, and the REST API allows for management of a ledger of downloads (i.e., what certificates / registrations and provisioning have been completed for a group of devices). As used herein, the term chip refers to any appropriate hardware component within a computerized device to be provisioned, such as an on-board unit, roadside unit, etc.In some configurations, optional parameters for chips that do not include their own storage are stored in off-chip storage, such as, but not limited to, flash storage, allowing registration and other credentials to be generated for chips without storage.

[0010] In some implementations, a system for securely provisioning at least one computerized device can include a certificate application programming interface (API) device, communicatively connected to the at least one computerized device via a first secure communication channel and operable to receive digital assets and load the digital assets onto the at least one computerized device, the digital assets including an enrollment package and an end-entity certificate package. Secure communication, in the context of the present teachings, refers to an encrypted communication channel in which one or more communicating entities are authenticated to another. In some examples, the certificate API device is operable to receive an enrollment request at the at least one computerized device via the application programming interface (API), the enrollment request enabling vehicle-to-vehicle communication or vehicle-to-infrastructure communication. The certificate API device can be used to generate an enrollment package at the at least one computerized device by obtaining the enrollment package from a certificate management service (CMS) via the API, and can be used to generate an end-entity certificate package at the at least one computerized device by obtaining the end-entity certificate package from the CMS via the API. Additionally, the certificate API device can be used to transmit, via the API, the enrollment package and the end-entity certificate package to at least one computerized device, the enrollment package and the end-entity certificate package modifying the at least one computerized device to enable it to exchange secure communications with a further computerized device. The system may also include a CMS connected to the certificate API device via a second secure communications channel and operable to provide the enrollment package and the end-entity certificate package to the certificate API device.

[0011] In some embodiments, the certificate API device may be used to receive, via the API, a request for computerized device status for at least one computerized device from a CMS. The certificate API device may also be used to send a response to the request via the API, the response including metadata indicating whether a registration package has been received from the CMS for the at least one computerized device. In some examples, the certificate API device may be used to receive, via the API, a request for registration status for a group of computerized devices from a CMS and to send, via the API, a response to the request, the response including metadata indicating the number of registration certificates and end entity certificates received for the group of computerized devices.

[0012] In some embodiments, the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device. In some examples, the at least one computerized device comprises an electronic control unit of a motor vehicle. In various implementations, the certificate API device is used to receive and retrieve a wrapped or encrypted key for matching the registration and application package in response to detecting that the at least one computerized device comprises volatile memory. In some embodiments, the certificate API device is used to transmit the wrapped key to the at least one computerized device. In some examples, the certificate API device is used to provide the registration package and the end-entity certificate package to the at least one computerized device without connecting to an external network.

[0013] In some embodiments, at least one computerized device is a roadside unit (RSU), and the certificate API device is operable to provide the registration package to the at least one computerized device without providing a pseudonymous package. In some examples, the roadside unit is a street light sensor or a construction warning sensor. In some embodiments, the certificate API device is operable to generate the pseudonymous package by bundling one or more pseudonymous certificates retrieved from a CMS. In some examples, the certificate API device is operable to generate the registration package by bundling one or more enrollment certificates retrieved from a CMS.

[0014] In some embodiments, a method for securely provisioning at least one computerized device can include receiving a registration request at the at least one computerized device via an application programming interface (API), the registration request enabling vehicle-to-vehicle or vehicle-to-infrastructure communication. The method can also include generating a registration package at the at least one computerized device by retrieving a registration package from a Certificate Management Service (CMS) via the API, and generating an end-entity certificate package at the at least one computerized device by retrieving an end-entity certificate package from the CMS via the API. Further, the method can include sending the registration package and the end-entity certificate package to the at least one computerized device via the API, the registration package and the end-entity certificate package modifying the at least one computerized device to exchange secure communications with additional computerized devices.

[0015] In some embodiments, one or more non-transitory computer-readable media may include a plurality of computer-executable instructions that, when executed by a processor, cause the processor to receive a registration request at at least one computerized device via an application programming interface (API), the registration request enabling vehicle-to-vehicle or vehicle-to-infrastructure communication. The plurality of computer-executable instructions may also cause the processor to generate a registration package at the at least one computerized device by retrieving a registration package from a certificate management service (CMS) via the API, the registration package including one or more registration certificates. The plurality of computer-executable instructions may further cause the processor to generate an end-entity certificate package at the at least one computerized device by retrieving an end-entity certificate package from the CMS via the API, the end-entity certificate package including one or more end-entity certificates. The plurality of computer-executable instructions may also cause the processor to asynchronously transmit the registration package and the end-entity certificate package to the at least one computerized device via the API, the registration package and the end-entity certificate package modifying the at least one computerized device to enable it to exchange secure communications with additional computerized devices. [Brief explanation of the drawings]

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate numerous examples of the features of the disclosed subject matter and, together with the description, serve to explain the principles of the various technologies described herein.

[0017] [Figure 1] FIG. 1 is a block diagram of an example operating environment for a certificate management service, a certificate API device, and a client device consistent with example embodiments described herein.

[0018] [Figure 2] FIG. 10 is a data flow diagram illustrating an example of data flow between a client device, a certificate API device, and a CMS consistent with example embodiments described herein.

[0019] [Figure 3] FIG. 1 is a process flow diagram of an example method for asynchronously transferring an end entity certificate package to several computerized devices via a client device, consistent with example embodiments described herein.

[0020] [Figure 4] FIG. 1 is a process flow diagram of an example method for asynchronously receiving enrollment packages and certificate packages on multiple computerized devices via a client device consistent with example embodiments described herein.

[0021] [Figure 5] FIG. 1 is a block diagram of an example computing system capable of hosting systems and methods consistent with example embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0022] Detailed Description Reference will now be made in detail to various implementations of the technology described herein, examples of which are illustrated in the accompanying drawings. For convenience, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0023] Introduction To ensure safe and proper operation in the field, embedded devices, such as electronic control units (ECUs) used in vehicles, are initialized during manufacturing by provisioning them with digital assets, such as security assets. Digital assets can include various digital certificates, cryptographic keys, unique identifiers, and software. In some examples, the CMS or certificate management service that generates these digital assets and the manufacturing plants where these digital assets are programmed into ECUs are located in different geographic locations that are interconnected via traditionally insecure internet communications. In the context of the present teachings, a secure channel is an encrypted communication channel in which one or more of the communicating entities are authenticated to the other. Therefore, it is desirable to create an end-to-end secure channel from the origin of these digital assets to the device, so that the digital assets cannot be accessed or altered by malicious parties or accidentally. Typically, different manufacturing plants and tenants (e.g., customers and clients) require different numbers of digital assets (e.g., bundles of digital certificates of different sizes). Therefore, to minimize manufacturing time, it is also desirable to minimize delays in providing these digital assets due to computational bottlenecks or communication bandwidth limitations associated with large requests.

[0024] One drawback of traditional or conventional certificate management systems (CMS) and certificate management services is that they issue certificates on a first-come, first-served basis. This creates a technical problem in that when a large request is made and received by a customer, subsequent requests that come to the certificate management system or service after the large request must wait for the large request to complete before being serviced. Conventional techniques for minimizing the delays or bottlenecks associated with waiting for large certificate requests to be fulfilled include having a separate certificate management service with dedicated equipment for each customer. A problem with this traditional approach is that allocating dedicated equipment is expensive and inefficient, and it underutilizes computing resources and bandwidth, as equipment dedicated to a given customer may sit idle while other equipment dedicated to another customer is at maximum capacity. Systems, methods, and devices consistent with the present disclosure address these and other problems of traditional certificate management systems and services and may provide an efficient multi-customer solution.

[0025] Provisioning generally refers to a set of actions taken to prepare a computerized device with appropriate data and software. Provisioning may also include a set of actions taken to properly install a device in its operating environment and prepare it for operation. Actions include loading appropriate digital assets (e.g., operating system, device drivers, middleware, applications, digital certificates, etc.) into the device's digital storage (e.g., memory) and (if necessary) properly customizing and configuring specific digital assets on the device, which may be unique to each particular device. Actions may also include verifying that the computerized device is a legitimate device created by a legitimate device manufacturer and not a copy or counterfeit device.

[0026] Actions may also include properly installing the device in its operating environment and testing the device to verify that it is operating properly. The ability to securely provision only devices that have been verified as secure is complicated by the fact that a device may be built by one manufacturer and later installed into a larger system or device by another. For example, an on-board unit (OBU) built by a parts manufacturer may be installed in an automobile built by an automobile manufacturer. An improperly installed device may function incorrectly.

[0027] The technology described herein The techniques and implementations described herein provide an application programming interface (API) that can enable asynchronous retrieval of computerized device-specific data from a client device, provision of software packages from an external server or certification management system, and provision of the software packages to the computerized device via the client device. The API described herein can provide improved services to selected users, customers, and client devices. The API described herein can reduce latency for retrieving software packages and improve the efficiency of client devices adapted to install software packages on any number of computerized devices. In some examples, the API can enable client devices to retrieve and install software packages despite limited network connectivity, bandwidth issues, low upload data rates, low download data rates, and per-session upload / download limits (i.e., the total number of megabytes or gigabytes that can be uploaded and / or downloaded during a network session). Device-specific information can be obtained during the initial manufacturing phase, and the necessary certificates can then be calculated while the device is being manufactured, so that the calculated certificate bundle is available to the device without delay when the device reaches the end of the manufacturing line. Thus, manufacturing pauses and delays due to certificate preparation can be eliminated.

[0028] Disclosed herein are systems, methods, and devices for providing an application programming interface capable of satisfying requests from client devices to generate specific types of digital assets, such as security credentials and digital certificates. In various implementations, the systems, methods, and devices use a certificate management device, also referred to herein as a certificate API device, to provide an API to clients requesting certificates from a certificate management system (CMS), also referred to herein as a security certificate management system (SCMS). In some implementations, the CMS hosts a certificate management service that accepts requests from the certificate management device to create and provide specific types of digital assets, such as security credentials and public key certificates. In some embodiments, the certificate management device uses the API to request and manage the retrieval of digital assets from the CMS. In various implementations, the certificate management service can create certificates for vehicle-to-vehicle and vehicle-to-infrastructure (V2X) devices, as well as car-to-car and vehicle-to-infrastructure (C2X) devices. In various implementations, the system includes a certificate management device that enables asynchronous retrieval of digital assets requested by client devices. In some embodiments, a certificate management device is communicatively connected to a client device and connected to a CMS via any suitable network connection. The certificate management device can send requests to a certificate management service that generates certificates, such as enrollment certificates and end-entity certificates, in response to receiving requests for such certificates from the client device.

[0029] In various implementations, the system provides an application programming interface that enables requesting certificates from a certificate management service. The application programming interface (API) is operable to receive certificate requests from multiple clients, each certificate request indicating their public key to be used to create the certificate, a timestamp indicating when the certificate request was sent, and the number of computerized devices that need the certificate along with the particular client requesting the certificate. The API can send certificate requests from one or more client devices to the certificate management system. The API can then bundle digital assets received from the certificate management system. For example, the API can bundle any number of digital assets received for each computerized device and send the bundle of digital assets to the client device for provisioning of the computerized device. In some implementations, the group size, which corresponds to a subset of the number of computerized devices that need the certificate, is an adjustable number with a default value of 1 or any other suitable number.

[0030] In certain implementations, the computerized device corresponds to one or more of an on-board unit (OBU), an electronic control unit (ECU), and a roadside unit (RSU), where the OBU is configured to be installed in one or more of a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device, the ECU is configured to be installed in one or more of a vehicle, a watercraft, an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless communication module, a wired communication module, and an IoT device, and the RSU is configured to be installed in one or more of a traffic control device, a pedestrian warning system, a wireless communication system or module, a digital billboard, and an electronic sign.

[0031] In certain implementations, at least one client device, also referred to as a tester device, acts as a proxy between the certificate management service and at least one computerized device requiring a certificate. The tester device may be located at a manufacturer's location, such as a factory. According to such implementations, the at least one computerized device may retrieve the certificate from the tester device after the tester device receives the certificate from the certificate management service. In further implementations, the plurality of clients may include at least one server acting as a proxy between the certificate management service and the at least one computerized device requiring a certificate. According to such implementations, the at least one computerized device may retrieve the certificate from the server after the server receives the certificate from the certificate management service.

[0032] In further implementations, the API is a Representational State Transfer (REST) ​​API or Simple Object Access Protocol (SOAP) API operable, among other things, to receive certificate requests from multiple clients over a communications network, the certificate requests including requests for enrollment certificates, and to transmit, on behalf of the certificate management service, enrollment certificates generated by a registration authority of the certificate management service to the multiple clients over the communications network. According to some implementations, the API request further includes a request for an end-entity certificate, and the API is further operable, on behalf of the certificate management service, to transmit, on behalf of the certificate management service, end-entity certificates generated by the end-entity authority of the certificate management service to the multiple clients over the communications network. According to some implementations, the enrollment certificates are public key certificates that identify the owner of the public key certificate as an authorized participant in an ecosystem including multiple computerized devices, and each authorized participant in the ecosystem can receive one or more end-entity certificates that enable communication with the multiple computerized devices. In some examples, the end-entity certificates enable applications to perform runtime operations such as, among other things, safety-related commands, position-related commands, speed-related commands, and direction or heading-related commands.

[0033] The services and APIs described herein are intended to provide manufacturers of computerized devices, such as chip and ECU manufacturers, with flexibility and reduced latency when initially provisioning digital assets, such as V2X certificates, into end entities (EEs), which are certain types of computerized devices. In some examples, each call to a service or API can be a synchronous HTTPS REST call that can return some immediate state or artifact in Javascript Object Notation (JSON) or any other suitable programming language. The provisioning process of the technology herein can be initiated with a registration request route, which has various options, depending on the needs and constraints of the manufacturing process. In some implementations, to save time on the manufacturing line, this request can be made before manufacturing of the end entity begins. While requests can still be made in real time, this provisioning process has the advantage of reducing line latency and ensuring that all necessary registration packages are always ready for local download. At any time, the state of a particular computerized device, such as a group of chips or an individual chip, can be requested to determine its readiness.

[0034] Initial registration requests can be made for individual chips or batches of chips. Either option allows for status tracking via a group or batch identifier. The process of provisioning a computerized device, such as an OBU, often takes several minutes to complete, depending on the current load on the certificate management service related to the number of assets (e.g., certificates) initially provisioned. In various implementations, the entire registration and provisioning process is a two-stage asynchronous process, for example, where the registration certificate is retrieved in one stage and the end-entity certificate bundle is received in another stage. In another aspect, the basic EE assets needed to create the registration certificate and end-entity certificate are obtained once, and then the registration and end-entity certificate are provided to the tester device for programming via an API. This flexibility allows for the time to generate and download the end-entity certificate bundle, but also allows for separate download locations for each stage. In some instances, batches can be registered before production, if possible, so that the provisioning state can be guaranteed to be “READY” to reduce delays on the manufacturing line. Because registration certificate injection and end-entity certificate provisioning can occur in different locations, multiple options are available for downloading the final bundle. For example, the end-entity certificate may be downloaded at an OEM facility rather than at a Tier 1 site.

[0035] In such an implementation, provisioning an OBU pseudonymous certificate from a certificate management service API can include collecting enrollment certificates and bootstrap information, and provisioning anonymous pseudonymous certificates for weeks. In various implementations, the API described herein abstracts the process from the device and makes individual requests on its behalf. A caller of the API, such as a client device, can monitor or poll the status of the chip request and, once complete, download the final bundle of information all at once, rather than interacting directly with the CMS for all of the various downloads. The API conveniently bundles the bootstrapping and provisioning information into two files that can be processed or unzipped by the client device and installed on the computerized device.

[0036] FIG. 1 illustrates an exemplary operating environment 100 in which a client device 102 (also referred to herein as a “tester device”) interacts with a certificate management service 104, which is an example of one type of service for providing digital assets. In some implementations, the certificate management service 104 may be a V2X certificate management service. In additional or alternative implementations, the certificate management service 104 may be a C2X certificate management service and may be implemented as a server, one or more virtual machines (VMs) on another computing device, or the like. As shown, the client device 102 can submit requests for certificates for one or more computerized devices 106 to the certificate management service 104 via a certificate API device 108 and a network 110, such as the Internet. In particular implementations, the computerized devices 106 correspond to one or more of a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device. For example, the computerized device 106 may correspond to an OBU or ECU of a vehicle, a watercraft, an aircraft, a spacecraft, a robot, a drone, a medical device, or an IoT device. Also, for example, the computerized device 106 may correspond to an RSU of a traffic control device (e.g., a traffic light, a traffic signal, or an electronic traffic sign), a digital billboard, a pedestrian warning system, a motorcycle sensor, a bicycle sensor, an electronic sign, a street light sensor, or a construction warning sensor, among others. In some embodiments, the client device 102 may connect to the certificate API device 108 via any suitable secure communication channel or secure transmission link. In some examples, the certificate API device 108 may connect to the CMS 104 via any suitable secure communication channel or secure transmission link.

[0037] In the operating environment 100, a request for a certificate is received by the certificate API device 108 from the client device 102 via any suitable interface. For example, the certificate API device 108 may implement an API based on the Representational State Transfer (REST) ​​protocol or the Simple Object Access Protocol (SOAP), among others. As shown in FIG. 1 , the certificate API device 108 may implement a public or private API, and the certificate management service 104 may be a V2X or C2X certificate management service. The certificate management service 104 accepts the certificate request, completes the task within a timeframe, and then returns the result (e.g., the generated certificate) to the client device 102 via the certificate API device 108 and the network 110. In some implementations, the timeframe may be minutes, hours, or days, depending on the processing capabilities of the certificate management service 104, among others.

[0038] In some embodiments, the certificate management service 104 can return the result or generated certificate to the computerized device 106 via the certificate API device 108. For example, the computerized device 106 can receive code that enables the computerized device 106 to communicate directly with the certificate API device 108 while bypassing the client device 102. In some examples, the computerized device 106 can be pre-programmed with software to communicate directly with the certificate API device 108. In some embodiments, the computerized devices 106 can communicate in a mesh configuration, where a computerized device 106 acts as a client device 102 of a further downstream computerized device 106.

[0039] The certificate management service 104 includes components for generating requested certificates. In the example of Figure 1, these components include a registration authority 112, a registration certificate authority 114, an end entity certificate authority 116, a cooperation authority 1 118, and a cooperation authority 2 120.

[0040] In additional or alternative implementations, the components of the certificate management service 104 may differ depending on whether the certificate management service 104 is configured as a V2X or C2X certificate management service. For example, if the certificate management service 104 functions as a C2X certificate management service, the certificate management service 104 may include a registration authority (EA) configured to play a role similar to that of the registration authority 114. Similarly, if the certificate management service 104 is embodied as a C2X certificate management service, the certificate management service 104 may include an authorization authority (AA) that plays a role similar to that of the end entity certificate authority 116. The components of the certificate management service 104 are described in the following paragraphs.

[0041] In one example, the certificate management service 104 may be embodied as a CMS. Various implementations of the certificate management service 104 may be used for extremely high-volume device transaction and certificate generation processing. In various implementations, the certificate management service 104 may be implemented using multiple servers, multiple hardware security modules (HSMs), multiple calculation or computing engines, and multiple application platforms. In an exemplary implementation, the application platforms may each include one or more VMs for hosting the registration authority 112, the registration certificate authority 114, the end-entity certificate authority 116, and the cooperation authorities 118 and 120. In additional or alternative implementations, the application platforms may each include one or more hardware platforms, such as, for example, application servers, computers, or other computer hardware capable of hosting and executing software applications. In the example of FIG. 1 , the application platform at the registration certificate authority 114 may be one or more VMs executing the application at the registration certificate authority 114, and the application platform at the end-entity certificate authority 116 may be one or more VMs operable to host and execute the application of the end-entity certificate authority 116. Similarly, the application platform in cooperating station 1 118 may be one or more VMs configured to host and execute applications for cooperating station 1, and the application platform 120 in cooperating station 2 may be one or more VMs operable to host and execute applications for cooperating station 2. Non-limiting examples of certificate management service 104 may be implemented in a private data center, a cloud data center such as Amazon's Amazon Web Services (AWS), or a hybrid of a private data center and a cloud data center.

[0042] In some implementations, the certificate management service 104 may provide security certificates, such as registration certificates and end-entity certificates, to be used by a manufacturer's tester device or a distributor appliance. In particular embodiments, the certificate management service 104 may interact with a digital asset management system (DAMS, not shown) to provide certificates to a distributor appliance (not shown) or a client device 102.

[0043] 1 , the architecture of certificate management service 104 includes registration authority 112, registration certificate authority 114, end entity certificate authority 116, coordination authority 1 118, and coordination authority 2 120. Each of these components may utilize a respective dedicated computation engine (not shown) to perform tasks. For example, registration authority 112 may utilize a registration authority computation engine, registration certificate authority 114 may utilize a registration certificate authority computation engine, end entity certificate authority 116 may utilize an end entity certificate authority computation engine, coordination authority 1 118 may utilize a coordination authority 1 computation engine, and coordination authority 2 120 may utilize a coordination authority 2 computation engine. The functionality of each of these components is described in the following paragraphs.

[0044] In some embodiments, the architecture of the certificate management service 104 advantageously separates non-security-related applications from security functions. As shown in the example of FIG. 1 , the registration authority 112, the registration certificate authority 114, the end entity certificate authority 116, and the cooperation authorities 118 and 120 are implemented as applications on their own VMs running on their own dedicated compute engines, all of which are separate from non-security-related applications and functions. This provides both technical and security advantages and improvements over conventional systems where HSMs are slow, cloud service providers are unable to supply HSMs, or proper management of HSMs is uncertain. In the certificate management service 104, cryptographic operations that utilize HSMs are performed on a compute engine (e.g., one or more of the compute engines).

[0045] As shown in FIG. 1 , by separating critical security functions into separate computational engines, computationally intensive encryption and security functions (e.g., elliptic curve butterfly expansion calculations or elliptic curve digital signatures), such as those performed by the registration authority 112, registration certificate authority 114, end-entity certificate authority 116, and collaboration authorities 118 and 120, are performed significantly faster than existing, conventional systems. This design, in conjunction with the certificate API device 108 described below, enables significantly improved transaction processing in multi-client environments by ensuring that network 110-related issues do not interfere with or delay the provisioning of computerized devices 106 with digital assets retrieved from the certificate management system 104 or client devices 102. The client devices 102 can batch process the raw data required for certificate creation and send the data to the certificate API device 108, eliminating latency / interruptions and allowing for the accumulation of raw data from multiple sites at different times. For example, the client devices 102 can retrieve or preload enrollment packages, end-entity certificate packages, etc. from the CMS 104. Thus, the certificate API device 108 can provide the retrieved enrollment package and end-entity certificate package to the computerized device 106 during the provisioning process without network delays that may exist between the certificate API device 108 and the CMS 104. In some examples, the certificate API device 108 can avoid bandwidth issues, network connectivity issues, etc. while provisioning the computerized device 106. Furthermore, the certificate API device 108 can, in some examples, asynchronously retrieve the enrollment package and end-entity certificate package from the CMS 104 and asynchronously provide the enrollment package and end-entity certificate package to the computerized device 106.Asynchronous retrieval and delivery of enrollment packages and end-entity certificate packages can further reduce the time of the provisioning process for each computerized device. Accordingly, implementations consistent with this disclosure provide particularly technically advantageous system architectures for asynchronously providing digital assets to, retrieving digital assets from, and bundling digital assets on computerized devices 106.

[0046] In some embodiments, if the scale of the registration authority application executed by the registration authority 112 is to be modified, additional VMs can be added, but no change is required to the secure computation capabilities of the registration authority compute engine. Alternatively, if security computations are performance-limiting, additional secure registration authority compute engines can be added. This same multidimensional scaling applies to other components of the certificate management service 104. These capabilities provide significant performance improvements and scalability over existing traditional certificate management services (CMS). In some implementations, the application platforms of the registration authority 112, registration certificate authority 114, end entity certificate authority 116, and collaboration authorities 118 and 120 are communicatively connected to the compute engine via respective sets of input message queues, allowing all of these components of the certificate management service 104 to scale independently of each other.

[0047] As previously described and shown in the non-limiting example of Figure 1, each of the registration authority 112, the certificate authorities 114, 116, and the cooperating authorities 118, 120 may be implemented as an application on its own VM. In additional or alternative implementations, one or more of the registration authority 112, the certificate authorities 114, 116, and the cooperating authorities 118, 120 may run on a hardware platform (e.g., a server or a computing engine). The role and functionality of each of these applications running on an application platform (e.g., a VM or hardware platform) are described in the following paragraphs.

[0048] In various implementations, the registration authority 112 can be an authority within a provisioning network that validates user requests for digital certificates or other types of digital security assets, enabling certificate authorities (e.g., the registration certificate authority 114 and the end-entity certificate authority 116) to issue digital certificates. In various implementations, the registration authority 112 can implement any suitable public key infrastructure (PKI) technology. In various implementations, the certificate API device 108 can pass certificate requests to the registration authority 112, which can be implemented as a Representational State Transfer (REST) ​​web service or a SOAP-based service, among others. In various implementations, multiple instances of the registration authority 112 can run simultaneously. This is similarly expressed with respect to the other components of the certificate management service 104 shown in FIG. 1 . The registration authority functionality of the certificate management service 104 is decentralized in that its functionality can be performed by multiple instances of the registration authority 112 implemented as a REST web service. One role of the registration authority 112 is to authorize and fulfill certificate provisioning requests while preventing the signing end-entity certificate authority 116 from determining which certificates are stored on a particular computerized device. The registration authority 112 can interact directly with the end-entity certificate authorities 116 and cooperating authorities 118, 120 to fulfill their roles within the certificate management service 104 via any secure communication channel, including, but not limited to, a message queue.

[0049] In certain implementations, the registration authority 112 (and other components of FIG. 1 ) may be connected to a database (not shown). The certificate management service 104 may utilize a collection of data stores or databases for data storage and retrieval. For example, the databases used may consist of one or more database logical or physical units, each with one or more tables, allowing for data separation as needed. As used herein, the term “database” refers to one or more databases or data stores. In certain implementations, the use of multiple databases may allow for data separation between the registration authority 112 and other components of FIG. 1 . For example, such use of multiple databases allows for data separation between the registration authority 112, the certification authorities 114, 116, and the cooperating authorities 118, 120.

[0050] In some embodiments, the database used by certificate management service 104 is a collection of one or more fast-access, low-latency databases. In some implementations, the database may be a NoSQL database or a database service, such as the DynamoDB data service offered by Amazon Web Services. In various implementations, the data stored in the database depends on the application, but may include customer-specific PSID / SSP lists, customer-specific policy data, manufacturer information, chip serial numbers, device serial numbers, previously issued certificates, various federation values, data about devices to which certificates have been issued, operator actions, etc. In some examples, the data may be stored unencrypted, encrypted, or some combination thereof.

[0051] In various implementations, the certificate management service 104 includes a registration authority 114 and an end-entity certificate authority 116 because digital certificates generated by the registration authority 112 are divided into different segments, e.g., registration digital certificates and end-entity digital certificates. The registration authority 114 is a decentralized component of the certificate management service 104 because there can be multiple instances of the registration authority 114 running simultaneously. For example, in some implementations, multiple instances of the registration authority 114 may run simultaneously. The registration authority 114 can receive requests for registration certificates from the registration authority 112. One role of the registration authority 114 is to fulfill requests from the registration authority 112 and issue registration certificates to end-user devices, such as the client device 102. In some embodiments, the registration authority 114 interacts directly with the registration authority 112 to fulfill its role within the CMS 104.

[0052] The end entity certificate authority 116 is a decentralized component of the CMS in that multiple instances of the end entity certificate authority 116 can run simultaneously. In the case of the end entity certificate authority 116, in various implementations, there can be multiple instances of the end entity certificate authority 116 running in parallel at the same time. The end entity certificate authority 116 can receive requests for end entity certificates from the registration authority 112. The role of the end entity certificate authority 116 is to fulfill requests from the registration authority 112 and issue end entity certificates to end user devices, such as the computerized device 106. In certain implementations, the end entity certificate authority 116 fulfills requests for short-term end entity certificates for V2V functionality. In some embodiments, the end entity certificate authority 116 interacts directly with the registration authority 112 to perform its functions within the CMS 104.

[0053] In various implementations, the coordination stations 118 and 120 shown in FIG. 1 link the identity of the certificate requester (i.e., the unique identifier of the certificate requester's device) to the issued end-entity certificate for revocation purposes. That is, coordination station 1 118 and coordination station 2 120 provide their respective coordination values ​​as the unique identifier of the certificate requester's device in the issued end-entity certificate. Coordination station 1 118 and coordination station 2 120 can receive requests for coordination values ​​from the registration authority 112 and provide the requested coordination values ​​to the registration authority 112. Coordination stations 118 and 120 interact directly with the registration authority 112 to fulfill requests for coordination values.

[0054] In various implementations, the computation engine of CMS 104 can include an HSM, which enables these components to perform secure computations without undue threat from hackers. In some implementations, the computation engine may be designed to perform secure computations itself without requiring an embedded HSM, and in such implementations, the computation engine embodies an HSM.

[0055] In various implementations, different HSM versions may be used in CMS 104. For example, the HSM may include an embedded HSM installed as a plug-in card within one or more compute engines. In such an example implementation, the embedded HSM may be installed within one or more compute engines as a Peripheral Component Interconnect (PCI) HSM or PCI Express (PCIe) HSM. Also, for example, the HSM within certificate management service 104 may include an external, network-attached, or network-attached HSM separate from the compute engines in its own enclosure.

[0056] Those skilled in the art will recognize that the components and implementation details shown in Figure 1 are examples presented for simplicity and clarity of description. This example is not intended to be limiting, and many variations are possible, so other components, processes, implementation details, and variations can be used without departing from the principles of the technology described herein.

[0057] 2 is a block diagram of an example system for providing provisioning information to and retrieving digital assets from a certificate management system using an application programming interface. In some embodiments, system 200 may be implemented on any suitable computing device, such as client device 102, certificate API device 108, and various computing devices of certificate management system 104 described above in connection with FIG.

[0058] In some embodiments, the client device 102 can send a registration request 202 to the certificate API device 108. The registration request can be sent using any suitable protocol, such as the POST protocol, among others. The request can be used to register a batch of computerized devices 106, such as in-vehicle units, roadside units, etc. In some examples, a request to register a batch of computerized devices 106 can include various parameters. For example, the request can include a public key associated with each chip and a group identifier corresponding to the batch of chips to be provisioned with the digital asset. The chips referred to herein can include any appropriate hardware components within the computerized device to be provisioned, such as in-vehicle units, roadside units, etc. The digital asset can include, among other things, a registration package and an end-entity certificate package. For computerized devices that cannot store / archive their own keys for future use, the digital asset can include a wrapped key for each chip. In some embodiments, the registration package can include any number of registration certificates, bootstrap information, applications, firmware, etc. In some examples, the end entity certificate package can include any number of end entity certificates that enable a computerized device to securely communicate with additional computerized devices. Registration packages and end entity certificate packages are described in more detail below in connection with Figures 3 and 4. The request can also include the name of the chip manufacturer, the chip model number, and the name of the electronic control unit owner, which are used to determine which local policy files to include in the final provisioning. The request can also include an array of roadside unit request information, including a public key and an optional wrapped key. The wrapped key can include any suitable encryption key stored in an encrypted data packet.In some embodiments, the client device 102 or computerized device 106 can decrypt the encrypted data packet and store the private encryption key from the encrypted data packet. In some embodiments, the request can include a registration private key slot number, a public registration seed key, a provider service identifier (PSID), and optional service-specific authorization (SSP) parameters, such as, but not limited to, the geographic region for which the certificate is being created and a customer profile identifier to be included in the registration and end-entity certificate. The geographic region can include a specific rectangular, circular, or named region, such as a country code, and the customer profile number can be used to manage configurable parameters for an entire group of customers. The slot number corresponds to the location of the private key present on the computerized device.

[0059] In various implementations, the PSID and SSP parameters can indicate messages that can be signed by an application. In some embodiments, the PSID is associated with an application specification that indicates how to create an interoperable instance of that application. For example, the SSP parameters can indicate state-dependent permissions for the application, which allow a specific subset of activities. In one example, the SSP parameters can grant additional permissions to a fire engine registration certificate or pseudonymous certificate, and the SSP parameters can enable “signal preemption,” which can include sending a message to a traffic light to change the displayed traffic light color. A non-emergency vehicle does not have the SSP parameters in its certificate and is not granted that permission. If an unauthorized user accesses a non-emergency vehicle and attempts to send a message to change the traffic light color, the traffic light RSU can verify that the non-emergency vehicle does not have the correct SSP parameters and deny the request.

[0060] The certificate API device 108 processes the registration request 202, and in the event of an error, the certificate API device 108 may return any appropriate error code to the client device 102 (206), such as an internal server error or a bad request. If the request operation is successful, the certificate API device 108 may send an acknowledgment to the client device 102 that the request operation was successful (206). As shown in this embodiment, the certificate API device 108 may then send the registration request 204 to the certificate management service 104, for example, for a batch of computerized devices. Also shown in this example, in response, the CMS 104 creates the requested registration certificates (and possibly other digital assets) and sends them in response 218 to the certificate API device 108, where they can be stored, at least temporarily. The certificate returned by the CMS 104 may include other central management data, such as a PSID / SSP, as required by the EE manufacturer.

[0061] In some embodiments, the certificate API device 108 can store any number of enrollment packages and end-entity certificate packages for the client device 102. Thus, the certificate API device 108 can bundle digital assets or packages sent to the client device 102. As the certificate API device 108 receives a portion of each batch of requested packages, the certificate API device 108 can be queried by the client device 102 to determine the status of certificate creation by the certificate management system 104. For example, the client device 102 can send a status request 208 for information about a single chip. The status request 208 can be processed by the certificate API device 108 to determine the programming readiness status of the enrollment certificate package retrieved for the client device 102. In some examples, the status request 208 can include a unique chip identifier (e.g., on the chip as shown in FIG. 2). The status request can return, for example, the name of the chip manufacturer, the model number of the chip, a group identifier for the batch of chips, the serial number of the electronic control unit, and the name of the electronic control unit manufacturer. In response, the certificate API device 108 may return a chip status 210 to the client device 102 indicating whether a registration certificate has been received from the CMS 104 for the computerized device or chip specified in the status request 208 to be provisioned by the client device 102. The response 210 to the status request 208 may also include the public registration seed key, the slot number of the registration seed private key, the wrapped key, the registration request or registration receipt indicator, and a timestamp corresponding to when the registration certificate was received.

[0062] In some embodiments, the client device 102 can also send a group registration status request 212. The group registration status request can query the name of a group of computerized devices or chips that are registered with the certificate API device 108. Along with each registration request 202 is a corresponding group name (e.g., a group ID as shown in FIG. 2 ) that can be requested at 212. The group name can be, for example, a tape reel identifier corresponding to a group of chips delivered to an ECU manufacturer. In some examples, the group name can be an identifier for a group of chips for determining provisioning and readiness states on a larger scale. For example, the certificate API device 108 can process the group registration status request 212 to determine whether provisioning data, such as a registration package and end-entity certificate package for a reel of chips (e.g., a group of in-vehicle units or a group of roadside units), is ready for download from the certificate API device 108. In some examples, the group registration status request 212 can be paginated and ordered by descending upload time (e.g., most recent, oldest, etc.). In some embodiments, the group enrollment status request 212 may also indicate descending or ascending order, an enrollment status indicator, and the date of the request. The enrollment status response 214 may indicate an array of names of groups that have certificates retrieved by the certificate API device 108, the current page in the list of group names, and the total number of pages available.

[0063] In some embodiments, the client device 102 can send a request 216 to retrieve a registration package for a chip (e.g., specified by chipid) or computerized device. In some examples, the request can be for any chip that has a registration package reception status, e.g., that status may have been communicated to the client 102 in a chip status message or response 210 or registration status response 214. For example, the client device 102 can request a registration package 216 if the certificate API device 108 has retrieved or acquired 218 a registration package for a group of chips or computerized devices from the CMS 104. If a wrapped key indicator, such as a wrapped signature caterpillar key (SCK) indicator or a wrapped encryption caterpillar key (ECK) indicator, was provided in the initial request, the binaries of these wrapped encryption keys can be provided instead of a slot number. A caterpillar key, as referred to herein, is a seed key used in butterfly expansion to derive many signature and / or encryption keys on a device with limited memory based on one seed signature / encryption key and a butterfly expansion value. In some examples, the butterfly expansion algorithm can use the seed key and butterfly extension value, along with an index representing the week and an index within that week of the duplicate credential. The computerized device 106 can then derive private signature and / or encryption keys from the caterpillar key and match these keys with the corresponding certificate generated by the CMS 104. Because the CMS 104 uses the same derivation algorithm and inputs to obtain the correct public key, the public key created by the CMS 104 and the private key derived at the computerized device 106 correspond to each other. In some embodiments, keys derived from the ECK are used for encryption on the device. Conversely, keys derived from the SCK are used to sign data and messages.

[0064] In some examples, detecting a wrapped encryption key indicates the presence of a master key that has encrypted the private ECK and SCK components of the key pair so that the private ECK and SCK components cannot be accessed by unauthorized users and / or devices. In various implementations, chipsets on some OBUs and RSUs may include one or more master keys in secure on-chip storage, such as flash memory, and store other encryption keys in a separate, insecure storage chip. In some embodiments, the private ECK and SCK components are stored in a “wrapped” format or encrypted by a master key. When firmware running on the chip attempts to access the private ECK or SCK key, the firmware retrieves or obtains the “wrapped” private key and unwraps (decrypts) the wrapped key into the chip's secure RAM memory; instructions executed by the chip can then access the decrypted private SCK and / or ECK key. When the chip is powered down, the decrypted private SCK and / or ECK key may be lost or deleted due to their storage in volatile memory. In some examples, the master key is kept in secure storage and the wrapped private SCK and ECK keys are kept in off-chip storage.

[0065] In some embodiments, when a binary is provided, the caller of the API can determine that the device did not have on-board memory attached when the key was created, and therefore the caller of the API (e.g., client 102) can inject the wrapped key into the appropriate "slot" or storage at load time.

[0066] When processing the application package request 224, the certificate API device 108 can retrieve the stored application certificate and one or more corresponding private reconfiguration values, as well as any necessary initial CMS bootstrap information, and send these digital assets to the client 102 in the application package response 224. The private reconfiguration values ​​can be generated with, among other things, the Elliptic Curve Quaternion (ECQV) algorithm that creates the CMS 104 certificate. In some embodiments, the computerized device 106 provides a seed key pair, and the certificate authority authenticates the seed key pair based on the generation of an implicit certificate that includes the public and private reconfiguration values. In some examples, the computerized device 106 can obtain the public and private reconfiguration values ​​and use elliptic curve mathematics to apply the values ​​to the seed key pair values ​​to derive the true, certified public and private keys. In various implementations, this is a process for generating an implicit certificate without a complete public key or signature. This can be a separate process from butterfly expansion. If the enrollment certificate has not yet been received by the certificate API device 108 from the CMS 104, the certificate API device 108 can return an error code (not shown). In some examples, the response 220 is or includes a zip file named with a chip identifier string and containing various elements. For example, the response 220 can include a hash identifier for the enrollment certificate, the enrollment certificate, an enrollment reconfiguration value, and private seed key metadata indicating the algorithm type, the length of the HSM slot number, and the HSM-specific slot number in binary. The response 220 can also include, among other things, a local policy and a local certificate chain.

[0067] In some embodiments, the client device 102 can also request retrieval of an end-entity certificate package for a computerized device, such as a chip (222). In some examples, the request 222 can be for any chip that has received the end-entity certificate package; for example, that status may have been communicated to the client 102 in a chip status message or response 210. For example, the client device 102 can request an end-entity certificate package when the certificate API device 108 retrieved an end-entity certificate package from the CMS 104 (218), for example, for a chip or group of computerized devices. If a wrappedSck and wrappedEck were provided in the initial request, binaries of these wrapped keys can be provided rather than private seed key metadata, which may include an HSM slot number. If a wrapped key is provided, it is assumed that the computerized device did not have on-board memory installed when the key was created; therefore, the client device 102 can insert the wrapped key into the appropriate “slot” at load time. In response to request 222, certificate API device 108 may retrieve a local certificate chain file, a local policy file, and an initial set of end entity certificates from CMS 104, for example, via certificate request 204 and response 218. If the end entity certificate package has not yet been downloaded or otherwise obtained from CMS 104, certificate API device 108 may return an error code.In some embodiments, the end entity certificate package response 224 is a zip file named with a chip identifier string that includes elements such as a hash identifier of the end entity certificate, a hash identifier of the provisioning request, a download time, a download uniform resource locator (URL) and port number, a sign-extended key, a binary response decryption extension key, and response decryption private seed key metadata, where the response decryption private seed key metadata includes an algorithm type, a length of the HSM slot number, a binary HSM-specific slot number, or any combination thereof. The end entity certificate package response 224 may also include signing the private key metadata with the algorithm type, the length of the HSM slot number, and the binary HSM-specific slot number. The response 224 may also include the initial provisioning of the end entity certificate on the chip and a zip file containing the encrypted certificate response from the registration authority device.

[0068] In some embodiments, the certificate API device 108 may support any suitable number of further requests. For example, the certificate API device 108 may detect a request from the client device 102 for a total number of chip (vehicle-mounted or roadside) groups and return the total number of unique groups loaded by the certificate API device 108. In some embodiments, the certificate API device 108 may also request a number of unique chips or computerized devices loaded via the API. The request may be made using a chip identifier, and in some examples, the response may indicate the total number of unique chips or computerized devices on which the registration package and / or end-entity certificate package is loaded. In some examples, the request may include a group identifier, a list of chip identifiers associated with the group, a registration status indicator, the percentage of chips registered, the time of the request date, and the time the last chip in the group was registered.

[0069] In some embodiments, when the computerized device is a roadside unit, the certificate API device 108 can support the various requests described above. The roadside unit can include any suitable sensor or Internet of Things device, which can be installed on one or more of a traffic control device, a wireless communication module, a digital billboard, and an electronic sign, among others. However, the certificate management system may not generate an application package for the roadside unit because the roadside unit is limited to the number of issued certificates that are valid at any time. For example, the number of currently valid issued certificates provided to the roadside unit can be limited to any suitable threshold, such as one, two, three, or any other value. This differs from on-board units (OBUs) and their pseudonymous certificates, which are over-created for future periods with multiple valid certificates for a given period. In some cases, the certificate API device 108 may not support a request to receive an application package for the roadside unit.

[0070] 2 is an example implementation of the techniques described herein, and it should be understood that system 200 may include fewer or additional components and devices in further implementations. For example, system 200 may include any number of client devices, multiple certificate API devices, and any number of certificate management systems. Furthermore, the certificate API devices may support any number of requests related to retrieval of digital assets, such as enrollment packages and end-entity certificate packages, from the certificate management system.

[0071] 3 is a process flow diagram of an exemplary method for asynchronously transferring an enrollment package and an end-entity certificate package to several computerized devices via a client device. Method 300 can be implemented on any suitable computing device, such as certificate API device 108 of FIGS. 1 and 2.

[0072] At block 302, the certificate API device 108 may receive an enrollment request at any number of computerized devices 106 via an application programming interface (API). In some embodiments, the certificate API device 108 may forward the enrollment request to the certificate management service (CMS) 104. In various implementations, the certificate API device 108 may send, receive, and manage data using the Representational State Transfer (REST) ​​protocol or the Simple Object Access Protocol (SOAP), among others.

[0073] In some embodiments, the registration request may instruct the certificate API device 108 to retrieve digital assets such as digital certificates, software, and / or firmware, among other things. In some examples, the digital assets enable the computerized device 106 to execute applications and real-time instructions in a secure manner.

[0074] In some implementations, the registration request may indicate that a registration package and an end-entity certificate package for any number of chips or computerized devices 106 are to be retrieved from the certificate management system 104. The registration package may include, among other things, one or more registration certificates, bootstrap data, firmware, applications to be installed, and wrapped encryption keys, as described above. In some implementations, the registration package may be used to provision the computerized device 106. However, in some examples, the computerized device 106 may not execute real-time instructions without the end-entity certificate included in the end-entity certificate package. For example, the end-entity certificate may enable an application installed on the computerized device to execute real-time instructions related to safety operations, speed correction operations, position correction operations, etc. In some examples, the computerized device 106 may execute real-time instructions without the end-entity certificate, but V2X communications with additional computerized devices may not be confirmed or functioning. In some examples, the computerized device 106 may include, among other things, an automobile electronic control unit, an on-board unit, or a roadside unit. In some embodiments, the registration request includes a computerized device identifier that corresponds to an externally accessible serial number for each computerized device 106. Computerized device identifiers are described in more detail below in connection with block 304.

[0075] At block 304, the certificate API device 108 may receive, via the API, a request for the computerized device state at the computerized device 106. The computerized device state referred to herein may refer to the state of retrieving the enrollment package and / or end-entity certificate package at the chip or computerized device 106. In some embodiments, the certificate API device 108 may also send a response to the request, the response including metadata indicating whether the enrollment package and end-entity certificate package at the computerized device 106 have been retrieved from the CMS 104. The computerized device state allows a device, such as the client device 102 or the certificate API device 108, to determine whether the enrollment package and end-entity certificate package have been received for a particular computerized device.

[0076] In some embodiments, the APIs described herein can execute requests based on an externally identifiable serial number that serves as a chip identifier in each request. In some examples, the serial number can be used in subsequent function calls or requests to retrieve state on the computerized device 106 and to retrieve enrollment and end-entity certificate packages. In some embodiments, the serial number can be an identifier that can be externally retrieved from the device after manufacture. The certificate API device 108 can store the serial number or identifier that can be used if the device is compromised or stolen. In some examples, the certificate management service 104 can then determine the enrollment certificate on the compromised computerized device based on the serial number and perform actions to revoke and blacklist the compromised computerized device. For example, the certificate management service 104 can ignore or otherwise prevent responses to subsequent requests from the compromised computerized device.

[0077] In some examples, the chip identifier can be used to uniquely identify enrollment and end-entity certificate package requests, allowing multiple enrollment requests to be initiated for different applications. If multiple enrollment packages are requested, a caller, such as a client device or a certificate API device, can formulate the chip identifier parameter using the external serial number, followed by an underscore and a postfix to indicate separate requests. For example, if a client device requests two bundles of enrollment packages or end-entity certificate packages with serial number 000-123456-EFD, the client device can make two requests using the following chip identifier parameters: (1) 000-123456-EFD_0 and (2) 000-123456-EFD_1.

[0078] At block 306, the certificate API device 108 may receive, via the API, a request for the enrollment status of the group of computerized devices 106. In some embodiments, the certificate API device 108 may also send a response to the request, the response including metadata indicating the number of end-entity certificates, e.g., enrollment certificates, pseudonymous certificates, enrollment packages, or pseudonymous packages, received for the group of computerized devices 106. In some examples, the enrollment status may indicate to the client device 102 the number or percentage of enrollment packages and end-entity certificate packages that the certificate API device 108 has received for the group of computerized devices 106. In some embodiments, the enrollment status may indicate to the client device 102 when the client device 102 can begin retrieving the enrollment packages and end-entity certificate packages from the certificate API device 108. For example, the certificate API device 108 may retrieve available enrollment packages and end-entity certificate packages for the group of computerized devices 106 and bundle the various enrollment packages and end-entity certificate packages separately before delivering the bundled enrollment packages and bundled end-entity certificate packages to the client device 102.

[0079] At block 308, the certificate API device 108 may generate a registration package for each computerized device 106 via the API. As described above in connection with block 302, the registration package may include, among other things, bootstrapping data and a registration certificate. The bootstrap data referred to herein may include any number of software and / or firmware updates that enable the computerized device 106 to install applications to be executed. The registration package may also include any number of security credentials, digital certificates, encryption keys, etc. In some embodiments, by retrieving the registration package in advance, the client device 102 or the certificate API device 108 may provision the computerized device 106 before installing the end-entity certificate that enables the execution of runtime operations related to V2X communications. In some examples, the registration package may also include a group identifier, a chip identifier, a uniform resource locator associated with the source of the registration certificate, etc.

[0080] At block 310, the certificate API device 108 may generate, via the API, an end-entity certificate package for each computerized device 106. In some embodiments, the end-entity certificate package may include one or more bundled digital certificates or end-entity certificates that enable secure execution of runtime instructions by the computerized device 106. In some examples, the end-entity certificate package may include at least one end-entity certificate that enables the computerized device 106 to execute runtime instructions in an application provided in the registration package. For example, the end-entity certificate may enable the computerized device 106 to execute applications that manage safety instructions, position instructions, velocity instructions, progress instructions, etc. In some embodiments, the end-entity certificate may enable a computerized device 106 in a V2X environment to recognize and securely execute requests by another uncompromised computerized device 106.

[0081] At block 312, the certificate API device 108 may transmit the enrollment package and the end-entity certificate package to the computerized device 106 via the client device 102. In some embodiments, the certificate API device 108 may transmit the enrollment package and the end-entity certificate package to the client device 102 or the computerized device 106 using asynchronous techniques. In some implementations, the enrollment package and the end-entity certificate package modify each computerized device 106 to execute provisioning instructions and exchange secure communications with additional computerized devices. The provisioning instructions referred to herein may include, among other things, installing applications and firmware and storing an enrollment certificate from the enrollment package. In some embodiments, the computerized device 106 that executed the provisioning instructions can exchange secure communications with additional computerized devices using the end-entity certificate from the end-entity certificate package. In various implementations, the secure communications may include requests for data related to the operating environment of the computerized device 106. For example, the secure communications may include, among other things, requests for the location, speed, or heading of the computerized device.

[0082] In some examples, the certificate API device 108 can transmit or distribute the enrollment package to a group of computerized devices 106 via the client device 102 after retrieving the enrollment package from the certificate management service 104. Similarly, the certificate API device 108 can transmit or distribute the end-entity certificate package to a group of computerized devices 106 via the client device 102 following retrieval of the end-entity certificate package from the certificate management service 104. The asynchronous retrieval and bundling of the enrollment package and end-entity certificate package may enable the certificate API device 108 to provision a group of computerized devices 106 using the client device 102 even when network connectivity to the certificate management service 104 is limited. In some examples, the certificate API device 108 may enable the client device 102 to retrieve the enrollment package and end-entity certificate package without connecting to an external network. For example, the certificate API device 108 may pre-load the enrollment package and the end-entity certificate package used to provision a group of computerized devices. After preloading the enrollment package and end-entity certificate package into the certificate API device 108, the certificate API device 108 can respond to enrollment requests without a connection to the CMS 104. In some examples, the computerized device 106 is a roadside unit (RSU), and the certificate API device 108 may enable the client device or computerized device 106 to retrieve the enrollment package without retrieving the pseudonymous package. For example, the RSU device may use an application certificate rather than a pseudonymous certificate to communicate with other devices. The CMS system may create pseudonymous certificates for OBUs with a default policy to provide any number of concurrent certificates per week, such as 20 concurrent certificates for up to 156 weeks, or any other suitable period.In some embodiments, the default policy for application certificates is a maximum of two application certificates at a time, or any other suitable number of application certificates at a time, with each application certificate being used for one week, or any other period of time. In some examples, application certificates are not linked to previous application certificates, and pseudonymous certificates are linked to caterpillar keys. Thus, for application certificates, a new key pair can be provided or obtained for each certificate. Because the application certificate initially created for an RSU device may expire by the time of delivery, and the RSU device may be associated with an unknown latitude / longitude location, the RSU device can receive a registration certificate at provisioning time and later receive an application certificate in response to the RSU device's request for an application certificate.

[0083] 3 does not indicate that the operations of method 300 should be performed in any particular order or that all of the operations of method 300 should be included in all cases. Moreover, method 300 may include any suitable number of additional operations. For example, method 300 may include retrieving the wrapped key from CMS 104 in response to detecting that computerized device 106 includes volatile memory. In some examples, method 300 may include extracting a private key from the wrapped key and transmitting the private key to computerized device 106.

[0084] 4 is a process flow diagram of an exemplary method for asynchronously receiving registration packages and end entity packages for multiple computerized devices via a client device. Method 400 can be implemented using any suitable computing device, such as client computing device 102 of FIGS. 1 and 2.

[0085] At block 402, the client device 102 may send a registration request for a plurality of computerized devices 106 to the certificate API device 108 via an application programming interface (API). In some examples, the registration request is associated with at least one registration package and at least one end-entity certificate package that enable V2X communications. In various implementations, the registration request may correspond to any number of computerized devices 106 in a group requesting a registration package and an end-entity certificate package.

[0086] At block 404, the client device 102 may send, via the API, a request for the computerized device status at the computerized device 106. As previously described, the computerized device status may indicate whether an enrollment package or an end-entity certificate package has been received from the CMS 104. In some examples, the client device 102 may send the request for the computerized device status to the certificate API device 108. In some embodiments, the client device 102 may also receive a response to the request, the response including metadata indicating whether an enrollment package or an end-entity certificate package for the computerized device 106 has been received from the CMS 104.

[0087] At block 406, the client device 102 may send, via the API, a request for the registration status of the group of computerized devices 106. As previously described in block 306 of FIG. 3 , the client device 102 may also receive a response to the request, the response including metadata indicating the number of certificates received for the plurality of computerized devices 106. For example, the response may include any number of received registration certificates, end-entity certificates, etc. In some embodiments, the metadata may also indicate whether an enrollment package has been received for the computerized device 106 and / or whether an end-entity certificate package has been received for the computerized device 106.

[0088] At block 408, the client device 102 may retrieve, via the API, a registration package for each computerized device 106. In some embodiments, the registration package may include, among other things, bootstrapping data and a bundled registration certificate. As discussed above in connection with block 308, retrieving the registration package in advance allows the client device 102 or the certificate API device 108 to provision the computerized device 106 before installing end-entity certificates that enable the performance of runtime operations related to V2X communications.

[0089] At block 410, the client device 102 may retrieve, via the API, an end-entity certificate package for each computerized device 106. In some embodiments, the end-entity certificate package may include any number of bundled digital certificates or end-entity certificates that enable execution of runtime instructions. In some embodiments, the end-entity certificates may enable computerized devices 106 in a V2X environment to recognize and securely execute requests by uncompromised computerized devices 106.

[0090] In block 412, the client device 102 can use the data from the registration package and the end-entity certificate package to modify each computerized device 106 to exchange secure transmissions with additional computerized devices. For example, the client device 102 can transmit the registration package and the end-entity certificate package to the computerized device 106. Thus, the client device 102 can install applications, firmware, registration certificates, end-entity certificates, etc. on the computerized device 106, thereby enabling the computerized device 106 to execute real-time instructions in a secure vehicle-to-vehicle or vehicle-to-infrastructure environment.

[0091] 4 does not imply that the operations of method 400 should be performed in any particular order or that all of the operations of method 400 should be included in all cases. Furthermore, method 400 may include any suitable number of additional operations.

[0092] 5 is a block diagram of an example computing environment 500 including a computing system 502 that may be used to implement systems and methods consistent with implementations of the present technology. Other components and / or arrangements may also be used. In some implementations, the computing system 502 may be used to at least partially implement various components of FIGS. 1-2 , such as the client device 102 or the certificate API device 108, among others. In some implementations, a series of computing systems similar to the computing system 500 may each be customized with dedicated hardware and / or programmed as a dedicated server for implementing one of the components of FIGS. 1-2 , which may communicate with each other via a network 504.

[0093] 5, computing system 500 includes a number of components, such as a central processing unit (CPU) 506, memory 508, input / output (I / O) devices 510, a hardware security module (HSM) 512, and a non-volatile storage device 514. System 500 may be implemented in a variety of ways. For example, an implementation as an integrated platform (e.g., a server, workstation, personal computer, laptop, etc.) may include CPU 506, memory 508, non-volatile storage 514, and I / O devices 510. In such a configuration, components 506, 508, 514, and 510 may connect and communicate via a local data bus or may access a data repository 516 (e.g., implemented as a separate database system) via an external I / O connection. The I / O component(s) 510 may connect to external devices via a direct communication link (e.g., a hardwired or local Wi-Fi connection), via a network such as a local area network (LAN) or a wide area network (WAN such as a cellular network or the Internet), and / or via other suitable connections. System 500 may be standalone or may be a subsystem of a larger system.

[0094] CPU 506 may be one or more known processors or processing devices, such as the Core® family of microprocessors manufactured by Intel® Corporation of Santa Clara, California, or the Athlon® family of microprocessors manufactured by AMD® Corporation of Sunnyvale, California. Memory 508 may be one or more storage devices configured to store instructions and information executed or used by CPU 506 to perform certain functions, methods, and processes related to implementing the present technology. Storage 514 may be a computer-readable medium, including volatile or non-volatile, magnetic, semiconductor, tape, optical, or other types of storage devices or devices intended for long-term storage, such as CDs, DVDs, and solid-state devices. In some examples, storage 514 may be any suitable non-transitory computer-readable medium. For example, the non-transitory computer-readable medium may include computer-executable instructions that direct CPU 506 to perform operations to implement the technology described herein.

[0095] In the illustrated implementation, memory 508 includes one or more programs or applications 518 loaded from storage 514 or a remote system (not shown) that, when executed by CPU 506, perform various operations, procedures, processes, or methods consistent with the present technology. Alternatively, CPU 506 may execute one or more programs located remotely from system 500. For example, system 500 may access one or more remote programs over network 504, which, when executed, perform functions and processes associated with implementing the present technology.

[0096] In one implementation, memory 508 may include programs 518 for performing the specific functions and operations described herein with respect to client device 102 and / or certificate API device 108. In some implementations, memory 508 may also include other programs or applications that implement other methods and processes that provide auxiliary functionality to the present technology.

[0097] Memory 508 may also be configured with other programs (not shown) unrelated to the present technology and / or an operating system (not shown) that, when executed by CPU 506, performs certain functions well known in the art. By way of example, this operating system may be a Microsoft Windows®, Unix®, Linux®, Apple Computer® operating system, or other operating system. The choice of operating system, and even the use of an operating system, is not critical to the present technology.

[0098] The HSM 512 may be a device with its own processor that securely generates and stores digital security assets and / or securely performs various cryptographic and sensitive calculations. The HSM 512 protects digital security assets such as encryption keys and other sensitive data from potential access by an attacker. In some implementations, the HSM may be a chip, plug-in card, or board that attaches directly to the computing system 500.

[0099] The I / O device(s) 510 may comprise one or more input / output devices that allow data to be received and / or transmitted by the system 500. For example, the I / O device(s) 510 may include one or more input devices, such as a keyboard, touch screen, mouse, etc., that allow data to be input from a user. Additionally, the I / O device(s) 510 may include one or more output devices, such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc., that allow data to be output or presented to a user. The I / O device(s) 510 may include one or more digital and / or analog communication input / output devices that allow the computing system 500 to communicate, e.g., digitally, with other machines and devices. Other configurations and / or numbers of input and / or output devices may be incorporated into the I / O device(s) 510.

[0100] In the illustrated implementation, the system 500 is connected to a network 504 (e.g., the Internet, a private network, a virtual private network, a cellular network, or other networks, or a combination thereof), which may be connected to various systems and computing machines, such as servers, personal computers, laptop computers, client devices, etc. In general, the system 500 may input data from and output data to external machines and devices via the network 504.

[0101] 5, the data repository or data source 516 is a standalone database external to the system 500. In other implementations, the data source 516 may be hosted by the system 500. In various implementations, the data source 516 may manage and store data used to implement systems and methods consistent with the present technology. For example, the data source 516 may manage and store data structures containing, for example, status and log information for each device 106 provisioned by the system 100.

[0102] Data source 516 may comprise one or more databases that store information and that are accessed and / or managed via system 500. By way of example, database 516 may be an Oracle® database, a Sybase® database, or other relational or non-relational database. However, systems and methods consistent with the present technology are not limited to different data structures or databases, nor are they limited in their use to databases or data structures.

[0103] Those skilled in the art will recognize that the components and implementation details of the system in Figure 5 are examples presented for brevity and clarity of explanation, and other components and implementation details may be used.

[0104] Although the foregoing examples use specific examples of computerized devices, such as an OBU, an ECU, and an RSU, for clarity of explanation, the technology is not limited to these specific examples. Various implementations consistent with the technology may be used with or for a wide variety of computerized devices, such as medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, and wireless communication modules (e.g., embedded universal integrated circuit cards (eUICCs)), among others.

[0105] Other implementations of the present technology will be apparent to those skilled in the art from consideration of the specification and practice of the technology disclosed herein. Various modifications of the exemplary embodiments, as well as other embodiments of the subject matter apparent to those skilled in the art to which the disclosed subject matter pertains, are deemed to be within the scope of the disclosed subject matter.

Claims

1. 1. A system for securely provisioning at least one computerized device, comprising: a certificate application programming interface (API) device communicatively connected to the at least one computerized device via a first secure communication channel and operable to receive digital assets and load the digital assets onto the at least one computerized device, the digital assets including an enrollment package and an end entity certificate package, the certificate API device also comprising: receiving a registration request at the at least one computerized device via an API, the registration request facilitating vehicle-to-vehicle or vehicle-to-infrastructure communication; generating the enrollment package on the at least one computerized device by sending, via the API, at least one enrollment certificate request to a Certificate Management Service (CMS), which generates one or more enrollment certificates in the enrollment package; generating the end entity certificate package on the at least one computerized device by sending, via the API, at least one end entity certificate request to the CMS, which generates one or more end entity certificates in the end entity certificate package; transmitting the enrollment package and the end-entity certificate package to the at least one computerized device via the API, the enrollment package and the end-entity certificate package configured to modify the at least one computerized device, thereby enabling the at least one computerized device to exchange secure communications with further computerized devices; It can operate as follows: the CMS is connected to the certificate API device via a second secure communication channel; the CMS providing the one or more enrollment certificates and the one or more end entity certificates to the certificate API device; system.

2. The certificate API device receiving, via the API, a request for a computerized device state at the at least one computerized device; sending a response to the request via the API, the response including metadata indicating whether a registration certificate was received from the CMS for the at least one computerized device; The system of claim 1 , wherein the system is operable to:

3. The certificate API device receiving, via the API, a request for a registration status of a group of computerized devices; sending a response to the request via the API, the response including metadata indicating the number of registration certificates and end entity certificates received for the group of computerized devices; 3. A system according to claim 1 or 2, operable to:

4. The system of claim 1 , wherein the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device.

5. The system of claim 1 , wherein the at least one computerized device comprises an electronic control unit of a motor vehicle.

6. 6. The system of claim 1, wherein the certificate API device is operable to receive and archive a wrapped key in a matching registration package in response to detecting that one of the at least one computerized device comprises volatile memory.

7. 7. The system of claim 6, wherein the certificate API device is operable to retrieve and transmit the wrapped key along with metadata so as to be properly associated with the one of the at least one computerized device.

8. 8. The system of claim 1, wherein the certificate API device is operable to provide the enrollment package and the end entity certificate package to the at least one computerized device without connecting to an external network.

9. 9. The system of claim 1, wherein the at least one computerized device is a roadside unit (RSU), and the certificate API device is operable to provide the registration package to the at least one computerized device without providing the end entity certificate package, but optionally with providing an application certificate.

10. The system of claim 9 , wherein the roadside unit is a street light sensor or a construction warning sensor.

11. 11. The system of claim 1, wherein the certificate API device is operable to generate the end entity certificate package by bundling the one or more end entity certificates retrieved from the CMS.

12. The system of claim 1 , wherein the certificate API device is operable to generate the enrollment package by bundling the one or more enrollment certificates retrieved from the CMS.

13. 1. A method for securely provisioning at least one computerized device using digital assets including an enrollment package and an end-entity certificate package, comprising: receiving a registration request at the at least one computerized device via an application programming interface (API), the registration request facilitating vehicle-to-vehicle or vehicle-to-infrastructure communication; generating the enrollment package on the at least one computerized device by sending, via the API, at least one enrollment certificate request to a Certificate Management Service (CMS), which generates one or more enrollment certificates in the enrollment package; generating the end entity certificate package on the at least one computerized device by sending, via the API, at least one end entity certificate request to the CMS, which generates one or more end entity certificates in the end entity certificate package; transmitting the enrollment package and the end entity certificate package to the at least one computerized device via the API, wherein the enrollment package and the end entity certificate package are configured to modify the at least one computerized device thereby enabling the at least one computerized device to exchange secure communications with additional computerized devices; A method comprising:

14. requesting a computerized device state at the at least one computerized device via the API; 14. The method of claim 13, comprising:

15. requesting, via the API, a registration status for a group of computerized devices; 15. The method of claim 13 or 14, comprising:

16. 16. The method of any one of claims 13 to 15, wherein the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device.

17. 17. The method of any one of claims 13 to 16, wherein the at least one computerized device comprises an electronic control unit of a motor vehicle.

18. Retrieving the wrapped key in response to detecting that the at least one computerized device comprises volatile memory.

18. The method of any one of claims 13 to 17, comprising:

19. transmitting the wrapped key to the at least one computerized device.

20. The method of claim 18, comprising:

20. Retrieving the enrollment package and the end entity certificate package without connecting to an external network.

20. The method of any one of claims 13 to 19, comprising:

21. One or more non-transitory computer-readable media comprising a plurality of computer-executable instructions in an application programming interface (API) that uses digital assets including an enrollment package and an end-entity certificate package, the plurality of computer-executable instructions, when executed by a processor, causing the processor to: receiving a registration request at at least one computerized device via the API, the registration request facilitating vehicle-to-vehicle or vehicle-to-infrastructure communication; generating the enrollment package on the at least one computerized device by sending, via the API, at least one enrollment certificate request to a Certificate Management Service (CMS), which generates one or more enrollment certificates in the enrollment package; generating the end entity certificate package on the at least one computerized device by sending, via the API, at least one end entity certificate request to the CMS, which generates one or more end entity certificates in the end entity certificate package; asynchronously transmitting the enrollment package and the end-entity certificate package to the at least one computerized device via the API, the enrollment package and the end-entity certificate package configured to modify the at least one computerized device, thereby enabling the at least one computerized device to exchange secure communications with additional computerized devices. One or more non-transitory computer-readable media.

22. 22. The one or more non-transitory computer-readable media of claim 21, wherein the plurality of computer-executable instructions cause the processor to provide the enrollment package and the end entity certificate package to the at least one computerized device without connecting to an external network.

23. The plurality of computer-executable instructions may be configured to cause the processor to:

23. The one or more non-transitory computer-readable media of claim 21 or 22, causing a request for a computerized device state at the at least one computerized device to be received via the API.

24. The plurality of computer-executable instructions may be configured to cause the processor to:

24. The one or more non-transitory computer-readable media of any one of claims 21 to 23, causing a request for a registration status in a group of computerized devices to be received via the API.

25. 25. The one or more non-transitory computer-readable media of any one of claims 21 to 24, wherein the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device.

26. 26. The one or more non-transitory computer-readable media of any one of claims 21 to 25, wherein the at least one computerized device comprises an electronic control unit of an automobile.

27. The plurality of computer-executable instructions may be configured to cause the processor to:

27. The one or more non-transitory computer-readable media of any one of claims 21 to 26, for obtaining a wrapped key on the at least one computerized device comprising volatile memory.

28. The plurality of computer-executable instructions may be configured to cause the processor to:

28. The one or more non-transitory computer-readable media of claim 27, causing the wrapped key to be transmitted to the at least one computerized device.

29. The plurality of computer-executable instructions may be configured to cause the processor to:

29. The one or more non-transitory computer-readable media of any one of claims 21 to 28, causing the enrollment package and the end entity certificate package to be provided without connection to an external network.

30. The plurality of computer-executable instructions may be configured to cause the processor to:

30. The one or more non-transitory computer-readable media of any one of claims 21 to 29, wherein the registration package is generated by bundling the one or more registration certificates.

31. 1. A system for securely provisioning at least one computerized device, comprising: a certificate application programming interface (API) device communicatively connected to the at least one computerized device via a first secure communication channel and operable to receive digital assets and load the digital assets onto the at least one computerized device, the certificate API device also comprising: receiving, via an API, a registration request at the at least one computerized device; generating an enrollment package on the at least one computerized device by sending at least one enrollment certificate request to a Certificate Management Service (CMS) via the API and receiving one or more enrollment certificates in the enrollment package from the CMS, the CMS being connected to the Certificate API device via a second secure communication channel; sending the registration package to the at least one computerized device via the API, the registration package being operable to modify the at least one computerized device; It can operate as follows: the registration package facilitating secure communication exchange between the at least one computerized device and a further computerized device; system.

32. The certificate API device generating, via the API, an end entity certificate package on the at least one computerized device that includes one or more end entity certificates retrieved from the CMS; sending the end entity certificate package to the at least one computerized device via the API, the end entity certificate package being operable to modify the at least one computerized device; It can operate as follows: the end entity certificate package facilitating secure communication exchange between the at least one computerized device and a further computerized device; 32. The system of claim 31.

33. 33. The system of claim 31 or 32, wherein the certificate API device is operable to provide the enrollment package and the end entity certificate package to the at least one computerized device without connecting to an external network.

34. 34. The system of any one of claims 31 to 33, wherein the certificate API device is operable to generate the end entity certificate package by bundling the one or more end entity certificates retrieved from the CMS.

35. The certificate API device receiving, via the API, a request for a computerized device state at the at least one computerized device; sending a response to the request via the API, the response including metadata indicating whether a registration certificate was received from the CMS for the at least one computerized device; 35. A system according to any one of claims 31 to 34, operable to:

36. The certificate API device receiving, via the API, a request for a registration status of a group of computerized devices; sending a response to the request via the API, the response including metadata indicating the number of registration certificates and end entity certificates received for the group of computerized devices; 36. A system according to any one of claims 31 to 35, operable to:

37. The certificate API device 37. The system of any one of claims 31 to 36, operable to send pseudonymous packages to the at least one computerized device via the API.

38. 38. The system of any one of claims 31 to 37, wherein the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device.

39. 39. The system of any one of claims 31 to 38, wherein the at least one computerized device comprises an electronic control unit of a motor vehicle.

40. 40. The system of any one of claims 31 to 39, wherein the certificate API device is operable to receive and archive a wrapped key in a matching registration package in response to detecting that one of the at least one computerized device comprises volatile memory.

41. 41. The system of claim 40, wherein the certificate API device is operable to retrieve and transmit the wrapped key along with metadata so as to be properly associated with the one of the at least one computerized device.

42. 42. The system of any one of claims 31 to 41, wherein the at least one computerized device is a roadside unit (RSU), and the certificate API device is operable to provide the registration package to the at least one computerized device.

43. 43. The system of claim 42, wherein the RSU is a street light sensor or a construction warning sensor.

44. 44. The system of any one of claims 31 to 43, wherein the certificate API device is operable to generate the enrollment package by bundling the one or more enrollment certificates retrieved from the CMS.

45. 1. A method for securely provisioning at least one computerized device using digital assets, comprising: receiving a registration request at the at least one computerized device via an application programming interface (API), the registration request facilitating communication between computerized devices; generating a registration package on the at least one computerized device via the API; sending the registration package to the at least one computerized device via the API, the registration package operable to modify the at least one computerized device, the modification of the at least one computerized device facilitating a secure communication exchange between the at least one computerized device and a further computerized device; A method comprising:

46. generating an end entity certificate package on the at least one computerized device via the API, the end entity certificate package including one or more end entity certificates retrieved via the API from a Certificate Management Service (CMS); sending the end entity certificate package to the at least one computerized device via the API, the end entity certificate package operable to modify the at least one computerized device, the modification of the at least one computerized device enabling secure communication exchange between the at least one computerized device and a further computerized device; 46. ​​The method of claim 45, further comprising:

47. Retrieving the wrapped key from the CMS when the at least one computerized device includes volatile memory.

47. The method of claim 45 or 46, comprising:

48. transmitting the wrapped key to the at least one computerized device.

48. The method of claim 47, comprising:

49. enabling the at least one computerized device to retrieve the enrollment package and the end entity certificate package without connecting to an external network; 49. The method of any one of claims 45 to 48, comprising:

50. receiving, via the API, a request for a computerized device state at the at least one computerized device; 50. The method of any one of claims 45 to 49, comprising:

51. receiving, via the API, a request for a registration status of a group of computerized devices; 51. The method of any one of claims 45 to 50, comprising:

52. 52. The method of any one of claims 45 to 51, wherein the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device.

53. 53. The method of any one of claims 45 to 52, wherein the at least one computerized device comprises an electronic control unit of a motor vehicle.

54. One or more non-transitory computer-readable media comprising a plurality of computer-executable instructions in an application programming interface (API) that uses digital assets, the plurality of computer-executable instructions, when executed by a processor, causing the processor to: receiving a registration request at at least one computerized device via the API, the registration request facilitating communication between the computerized devices; generating an enrollment package on the at least one computerized device by sending at least one enrollment certificate request to a Certificate Management Service (CMS) via the API and receiving one or more enrollment certificates in the enrollment package from the CMS; causing the registration package to be transmitted to the at least one computerized device via the API, the registration package operable to modify the at least one computerized device, and the registration package facilitating secure communication exchange between the at least one computerized device and a further computerized device; One or more non-transitory computer-readable media.

55. The plurality of computer-executable instructions, when executed by the processor, cause the processor to: generating, via the API, an end entity certificate package on the at least one computerized device, the end entity certificate package including one or more end entity certificates retrieved from the CMS via the API; causing the at least one computerized device to transmit the end-entity certificate package via the API, the end-entity certificate package operable to modify the at least one computerized device, the end-entity certificate package facilitating secure communications exchange between the at least one computerized device and a further computerized device; 55. One or more non-transitory computer-readable media as recited in claim 54.

56. 56. The one or more non-transitory computer-readable media of claim 55, wherein the plurality of computer-executable instructions cause the processor to provide the enrollment package and the end entity certificate package to the at least one computerized device without connecting to an external network.

57. The plurality of computer-executable instructions may be configured to cause the processor to:

56. The one or more non-transitory computer-readable media of claim 55, causing the enrollment package and the end entity certificate package to be provided without connection to an external network.

58. The plurality of computer-executable instructions may be configured to cause the processor to:

58. The one or more non-transitory computer-readable media of any one of claims 54 to 57, causing a request for a computerized device state at the at least one computerized device to be received via the API.

59. The plurality of computer-executable instructions may be configured to cause the processor to:

59. The one or more non-transitory computer-readable media of any one of claims 54 to 58, causing a request for a registration status in a group of computerized devices to be received via the API.

60. 60. The one or more non-transitory computer-readable media of any one of claims 54 to 59, wherein the registration request includes a computerized device identifier corresponding to an externally accessible serial number of the at least one computerized device.

61. 61. The one or more non-transitory computer-readable media of any one of claims 54 to 60, wherein the at least one computerized device comprises an electronic control unit of an automobile.

62. The plurality of computer-executable instructions may be configured to cause the processor to:

62. The one or more non-transitory computer-readable media of any one of claims 54 to 61, which causes retrieval of a wrapped key on the at least one computerized device comprising volatile memory.

63. The plurality of computer-executable instructions may be configured to cause the processor to:

63. The one or more non-transitory computer-readable media of claim 62, causing the wrapped key to be transmitted to the at least one computerized device.

64. The plurality of computer-executable instructions may be configured to cause the processor to:

64. The one or more non-transitory computer-readable media of any one of claims 54 to 63, for generating the registration package by bundling the one or more registration certificates.

65. The plurality of computer-executable instructions may be configured to cause the processor to:

65. The one or more non-transitory computer-readable media of any one of claims 54 to 64, generating the enrollment package by obtaining the enrollment package from the CMS.

Images